* Re: [U-Boot-Users] Help required to bring up kernel from U-Boot
From: batsayan.das @ 2005-12-16 10:49 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20051216101101.7B82B353416@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]
1. Doing the changes in Linux tree suggested in
http://www.denx.de/wiki/view/DULG/LinuxHangsAfterUncompressingKernel
yields the same result. We already did those changes.
2. Here is the procedure how I got the o/p of printk even if I do not get
anything at console.
Run u-boot from Trace32
bootm <addr> // Now in our case Linux hangs after giving the o/p "##
Transferring control to Linux (at address 00000000) ..."
stop u-boot //Do not hard reset the target
Again run U-Boot from Trace32
md <addrss of log_buf> // search for "log_buf" in System.map in Linux
tree. You will get this address.
Batsayan Das
Tata Consultancy Services Limited
Mailto: batsayan.das@tcs.com
Website: http://www.tcs.com
Wolfgang Denk <wd@denx.de>
Sent by: wd@denx.de
12/16/2005 03:41 PM
To
batsayan.das@tcs.com
cc
u-boot-users@lists.sourceforge.net, linuxppc-embedded@ozlabs.org
Subject
Re: [U-Boot-Users] Help required to bring up kernel from U-Boot
In message
<OFB8CF31AB.E132BC0B-ON652570D9.001789DD-652570D9.001A8A99@tcs.com> you
wrote:
>
> I copied uImage to location 0x04000000 and the Load Address=0x00000000
> and Entry point=0x00000000. The bootm 0x04000000 gives the o/p
> "Transferring Control to Linux" and then nothing comes. Where is the
> wrong?
This is a FAQ. Please see http://www.denx.de/wiki/DULG/Faq
> 1. What are the minimum information Linux needs from U-Boot to come up
> properly? In the Linux source tree we have put some printk statement
and
> found that base address of SDRAM, size, etc are passed correctly to
Linux
> by U-Boot.
Be careful with printk() at inappropieate places (i.e. too early).
But tell me - how where you able to see anthing with printk if
"nothing comes" as you write above ???
> 2. Is the info passed from U-Boot is sufficient enough to make the
kernel
> up?
Yes, of course. It works on thousands of systems.
> 3. If not, where should I concentrate in Linux tree?
On your changes.
And please keep this off the U-Boot list. It is off topic here.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
CONSUMER NOTICE: Because of the "Uncertainty Principle," It Is
Impossible for the Consumer to Find Out at the Same Time Both
Precisely Where This Product Is and How Fast It Is Moving.
ForwardSourceID:NT000081B2
Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 4580 bytes --]
^ permalink raw reply
* [PATCH] MPC85xx: CPM2 interrupt handler failure after 100, 000 interrupts
From: Marcelo Tosatti @ 2005-12-16 13:46 UTC (permalink / raw)
To: Kumar Gala, linux-ppc-embedded; +Cc: Daniel Belz, Edson Seabra
Hi Kumar,
Please apply.
From: Edson Seabra <Edson.Seabra@cyclades.com>
The CPM2 interrupt handler does not return success to the IRQ subsystem, which
causes it to kill the IRQ line after 100,000 interrupts.
[root@KVM ~]# create_cf --doformat --factory_default
...
Copying Linux kernel to /dev/hda1
Initialization of /dev/hda1 done.
Copying RO file system to /dev/hda5
Packing dev done.
Creating directories...
Creating etc... done.
Creating home... done.
Creating root... done.
Creating mnt... done.
Creating var... done.
Creating dev... done.
Creating tmp... done.
Creating proc... done.
Copying directories/files...
Copying bin... done.
Copying sbin... done.
Copying lib... done.
Copying libexec... done.
Copying new_web... done.
Copying opt... done.
Copying usr... done.
Copying COPYRIGHTS...
Error in command: 'cp -a /COPYRIGHTS /mnt/hdPart'
[ 1133.542580] Disabling IRQ #94
May 23 16:59:53 s_kernel@KVM [ 1133.542222] irq 94: nobody cared (try
booting with the "irqpoll" option)
May 23 16:59:53 s_kernel@KVM [ 1133.542546] handlers:
May 23 16:59:53 s_kernel@KVM [ 1133.542554] [<c0013ba4>]
(cpm2_cascade+0x0/0x48)
The following patch fixes the problem.
Signed-off-by: Edson Seabra <Edson.Seabra@cyclades.com>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
RCS file: /usr/cvsroot/oobi_projects/sources/lsp/linux-2.6.14
/arch/ppc/platforms/85xx/mpc85xx_cds_common.c,v
retrieving revision 1.1
retrieving revision 1.4
diff -u -r1.1 -r1.4
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 6 Dec 2005 02:56:21 -0000 1.1
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 14 Dec 2005 19:32:57 -0000 1.4
@@ -145,10 +154,11 @@
}
#ifdef CONFIG_CPM2
-static void cpm2_cascade(int irq, void *dev_id, struct pt_regs *regs)
+static int cpm2_cascade(int irq, void *dev_id, struct pt_regs *regs)
{
while((irq = cpm2_get_irq(regs)) >= 0)
__do_IRQ(irq, regs);
+ return(IRQ_HANDLED);
}
static struct irqaction cpm2_irqaction = {
^ permalink raw reply
* [PATCH] powerpc: CPM2 interrupt handler failure after 100,000 interrupts
From: Kumar Gala @ 2005-12-16 14:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Daniel.Belz, Edson.Seabra, linuxppc-embedded
The CPM2 interrupt handler does not return success to the IRQ subsystem, which
causes it to kill the IRQ line after 100,000 interrupts.
Signed-off-by: Edson Seabra <Edson.Seabra@cyclades.com>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Paul: We should put this in the merge tree for linus to pick up for
2.6.15.
commit 5f5a24140939b8f908a3cd131edaed6b6cf22174
tree 88efa1b2c4331abcda8858c64b5b971fabe9fc4f
parent b7d20dabe1f83f44d24d06121e10210b2a7e3ef8
author Kumar Gala <galak@kernel.crashing.org> Fri, 16 Dec 2005 08:47:28 -0600
committer Kumar Gala <galak@kernel.crashing.org> Fri, 16 Dec 2005 08:47:28 -0600
arch/ppc/platforms/85xx/mpc85xx_cds_common.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
index d8991b8..5bfe688 100644
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
@@ -130,10 +130,11 @@ mpc85xx_cds_show_cpuinfo(struct seq_file
}
#ifdef CONFIG_CPM2
-static void cpm2_cascade(int irq, void *dev_id, struct pt_regs *regs)
+static int cpm2_cascade(int irq, void *dev_id, struct pt_regs *regs)
{
while((irq = cpm2_get_irq(regs)) >= 0)
__do_IRQ(irq, regs);
+ return IRQ_HANDLED;
}
static struct irqaction cpm2_irqaction = {
^ permalink raw reply related
* Re: MPC5200 ppc_md.set_rtc_time
From: bennett78 @ 2005-12-16 15:33 UTC (permalink / raw)
To: Andrey Volkov; +Cc: ML linuxppc-embedded
In-Reply-To: <43A29A21.8080102@varma-el.com>
[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]
Andrey Volkov wrote:
>Hello Frank,
>
>bennett78 wrote:
>
>
>>Hi:
>> How / when does "ppc_md.set_rtc_time" get filled
>>in for Lite5200?
>>
>>Config for support /dev/rtc enables CONFIG_PPC_RTC
>>which enable driver/char/rtc.c which mentions CMOS_WRITE
>>panics the kernel!
>>
>>I trying to use driver/char/genrtc.c. I can set date
>>but not hwclock.
>>
>>
>>
>>>hwclock --set --date="9/22/96 16:45:05"
>>>
>>>
>>gen_set_rtc_irq_bit:exit
>>gen_rtc_ioctl RTC_SET_TIME 00000060
>>RTC_SET_TIME: Invalid argument
>>ioctl() to /dev/rtc to set the time failed.
>>
>>bash-2.05b# cat /proc/driver/rtc
>>rtc_time : 00:50339648:36914
>>rtc_date : -1072186980-497--1073718072
>>rtc_epoch : 1900
>>alarm : 00:00:00
>>DST_enable : no
>>BCD : yes
>>24hr : yes
>>square_wave : no
>>alarm_IRQ : no
>>update_IRQ : no <----- how can I hook one?
>>periodic_IRQ : no
>>periodic_freq : 0
>>batt_status : okay
>>
>>
>>thanks,
>>
>>*/Frank Bennett
>>/*
>>
>>
>For 2.6 kernel, check arch/ppc/syslib/lite5200.c, especially
>platform_init() (at the end of file).
>
>
Andrey:
Thanks, sorry I forgot to mention I'm on DENX linuxppc_2_4_devel.
Where is the linuxppc 2.6.x distribution?
Is anyone maintaining a checklist of working features for imbedded 2.6?
Is this mail list searchable? (other than a month at a time?)
Merry Christmas
Frank Bennett
>--
>Regards
>Andrey Volkov
>
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
[-- Attachment #2: Type: text/html, Size: 2441 bytes --]
^ permalink raw reply
* Re: MPC5200 ppc_md.set_rtc_time
From: bennett78 @ 2005-12-16 15:42 UTC (permalink / raw)
To: Frank Bennett; +Cc: ML linuxppc-embedded
In-Reply-To: <43A2DE2C.6010708@digis.net>
[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]
bennett78 wrote:
> Andrey Volkov wrote:
>
>>Hello Frank,
>>
>>bennett78 wrote:
>>
>>
>>>Hi:
>>> How / when does "ppc_md.set_rtc_time" get filled
>>>in for Lite5200?
>>>
>>>Config for support /dev/rtc enables CONFIG_PPC_RTC
>>>which enable driver/char/rtc.c which mentions CMOS_WRITE
>>>panics the kernel!
>>>
>>>I trying to use driver/char/genrtc.c. I can set date
>>>but not hwclock.
>>>
>>>
>>>
>>>>hwclock --set --date="9/22/96 16:45:05"
>>>>
>>>>
>>>gen_set_rtc_irq_bit:exit
>>>gen_rtc_ioctl RTC_SET_TIME 00000060
>>>RTC_SET_TIME: Invalid argument
>>>ioctl() to /dev/rtc to set the time failed.
>>>
>>>bash-2.05b# cat /proc/driver/rtc
>>>rtc_time : 00:50339648:36914
>>>rtc_date : -1072186980-497--1073718072
>>>rtc_epoch : 1900
>>>alarm : 00:00:00
>>>DST_enable : no
>>>BCD : yes
>>>24hr : yes
>>>square_wave : no
>>>alarm_IRQ : no
>>>update_IRQ : no <----- how can I hook one?
>>>periodic_IRQ : no
>>>periodic_freq : 0
>>>batt_status : okay
>>>
>>>
>>>thanks,
>>>
>>>*/Frank Bennett
>>>/*
>>>
>>>
>>For 2.6 kernel, check arch/ppc/syslib/lite5200.c, especially
>>platform_init() (at the end of file).
>>
>>
is this your point?
linux-2.6.12/arch/ppc/platforms/lite5200.c
/* No time keeper on the LITE5200 */
ppc_md.time_init = NULL;
ppc_md.get_rtc_time = NULL;
ppc_md.set_rtc_time = NULL;
I don't see any arch/ppc/syslib/lite5200.c
>>
>>
> Andrey:
> Thanks, sorry I forgot to mention I'm on DENX linuxppc_2_4_devel.
> Where is the linuxppc 2.6.x distribution?
> Is anyone maintaining a checklist of working features for imbedded 2.6?
> Is this mail list searchable? (other than a month at a time?)
>
> Merry Christmas
> Frank Bennett
>
>>--
>>Regards
>>Andrey Volkov
>>
>>
>>
>>
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 3648 bytes --]
^ permalink raw reply
* kernel 2.6.15-rc5-latest doesn't work anymore on mpc8540ads
From: Clemens Koller @ 2005-12-16 15:47 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am just about to update my kernel from 2.6.13-rc7 which is working
fine to linus' 2.6.15-rc5-latest git on my mpc8540ads flavored board.
However, the kernel hangs pretty early after
openpic: exit
any ideas or a hint what's wrong there... before I start to
debug deeper into the code?
Thanks,
Clemens
-----8<-----
U-Boot 1.1.3 (Jun 23 2005 - 10:40:01)
CPU: 8540, Version: 2.0, (0x80300020)
Core: E500, Version: 2.0, (0x80200020)
Clocks Configuration:
CPU: 825 MHz, CCB: 330 MHz,
DDR: 165 MHz, LBC: 82 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: MicroSys PM854
PCI1: 32 bit, 66 MHz (compiled)
I2C: ready
DRAM: Initializing
DDR: 256 MB
FLASH: 32 MB
L2: 256 kB enabled
In: serial
Out: serial
Err: serial
Net: ENET0: PHY is Marvell 88E1111S (1410cc2)
ENET1: PHY is Marvell 88E1111S (1410cc2)
ENET2: PHY is LXT971 (1378e2)
ENET0, ENET1, ENET2
Hit any key to stop autoboot: 0
## Booting image at fe300000 ...
Image Name: Linux-2.6.15-rc5-g7116317d
Created: 2005-12-16 15:30:40 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1394968 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
mpc8540ads_init(): exit
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
mpc8540ads_setup_arch()
arch: exit
openpic: enter
openpic: timer
openpic: external
openpic: spurious
openpic: exit
-----8<----
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: MPC5200 ppc_md.set_rtc_time
From: Andrey Volkov @ 2005-12-16 16:13 UTC (permalink / raw)
To: Frank Bennett; +Cc: ML linuxppc-embedded
In-Reply-To: <43A2E054.6090506@digis.net>
bennett78 wrote:
> bennett78 wrote:
>
>> Andrey Volkov wrote:
>>
>>>Hello Frank,
>>>
>>>bennett78 wrote:
>>>
>>>
>>>>Hi:
>>>> How / when does "ppc_md.set_rtc_time" get filled
>>>>in for Lite5200?
>>>>
>>>>Config for support /dev/rtc enables CONFIG_PPC_RTC
>>>>which enable driver/char/rtc.c which mentions CMOS_WRITE
>>>>panics the kernel!
>>>>
>>>>I trying to use driver/char/genrtc.c. I can set date
>>>>but not hwclock.
>>>>
>>>>
>>>>
>>>>>hwclock --set --date="9/22/96 16:45:05"
>>>>>
>>>>>
>>>>gen_set_rtc_irq_bit:exit
>>>>gen_rtc_ioctl RTC_SET_TIME 00000060
>>>>RTC_SET_TIME: Invalid argument
>>>>ioctl() to /dev/rtc to set the time failed.
>>>>
>>>>bash-2.05b# cat /proc/driver/rtc
>>>>rtc_time : 00:50339648:36914
>>>>rtc_date : -1072186980-497--1073718072
>>>>rtc_epoch : 1900
>>>>alarm : 00:00:00
>>>>DST_enable : no
>>>>BCD : yes
>>>>24hr : yes
>>>>square_wave : no
>>>>alarm_IRQ : no
>>>>update_IRQ : no <----- how can I hook one?
>>>>periodic_IRQ : no
>>>>periodic_freq : 0
>>>>batt_status : okay
>>>>
>>>>
>>>>thanks,
>>>>
>>>>*/Frank Bennett
>>>>/*
>>>>
>>>>
>>>For 2.6 kernel, check arch/ppc/syslib/lite5200.c, especially
>>>platform_init() (at the end of file).
>>>
>>>
> is this your point?
> linux-2.6.12/arch/ppc/platforms/lite5200.c
> /* No time keeper on the LITE5200 */
> ppc_md.time_init = NULL;
> ppc_md.get_rtc_time = NULL;
> ppc_md.set_rtc_time = NULL;
>
Yes.
> I don't see any arch/ppc/syslib/lite5200.c
But, sorry, from which file are you quotating prev code ;)?
>
>>>
>>>
>> Andrey:
>> Thanks, sorry I forgot to mention I'm on DENX linuxppc_2_4_devel.
>> Where is the linuxppc 2.6.x distribution?
Check here http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git
>> Is anyone maintaining a checklist of working features for imbedded 2.6?
>> Is this mail list searchable? (other than a month at a time?)
>>
AFAIK - no. By very simple reason - all drivers in vanilla kernel MUST
be work, if some code not in Linus git, then it (usually) unstable or in
the pending stage.
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Horst von Brand @ 2005-12-16 17:29 UTC (permalink / raw)
To: Olof Johansson
Cc: dtor_core, kernel-stuff, linux-kernel, linuxppc-dev, linux-input
In-Reply-To: <20051215195017.GA7195@pb15.lixom.net>
Olof Johansson <olof@lixom.net> wrote:
Just saw this.
> On Thu, Dec 15, 2005 at 12:31:08AM +0100, Michael Hanselmann wrote:
> > diff -rup linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c b/drivers/usb/input/appletouch.c
> > --- linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c 2005-12-13 22:44:24.000000000 +0100
> > +++ b/drivers/usb/input/appletouch.c 2005-12-15 00:25:09.000000000 +0100
[...]
> > +#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
> > +#include <linux/relayfs_fs.h>
> > +#endif
Why can't this be included regardless? If it does something that only makes
sense if relayfs is in use, better have that decision inside the header
file (least somebody just includes it and...).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Unable to open an initial console
From: Addison Baldwin @ 2005-12-16 20:01 UTC (permalink / raw)
To: linuxppc-embedded
I was sucessful to port U-Boot to our 8272 board. Now I'm experiencing
a problem:
Our Kernel hangs with the message that says it was trasnferring
control to linux. A post morten analyzes indicated that it stopped at
"Unable to open an initial console" in the memory sapce where console
output should be out (in the sdram, like I had found somewhere in this
list, how to do it).
I have checked the bootargs values, it is ok:
bootargs root=3D/dev/ram console=3DttyS0,115200
We also checked our "/dev" and there was a link to console, pointing
ttyS0. Also, ttyS0 was there too.
Does anyone have any idea how to fix it?
^ permalink raw reply
* Re: Unable to open an initial console
From: Vitaly Bordug @ 2005-12-16 20:09 UTC (permalink / raw)
To: Addison Baldwin; +Cc: linuxppc-embedded
In-Reply-To: <af313df20512161201u39280d30kdf1ace1c4569d50a@mail.gmail.com>
Addison Baldwin wrote:
> I was sucessful to port U-Boot to our 8272 board. Now I'm experiencing
> a problem:
>
> Our Kernel hangs with the message that says it was trasnferring
> control to linux. A post morten analyzes indicated that it stopped at
> "Unable to open an initial console" in the memory sapce where console
> output should be out (in the sdram, like I had found somewhere in this
> list, how to do it).
>
> I have checked the bootargs values, it is ok:
> bootargs root=/dev/ram console=ttyS0,115200
>
Only for 2.4, 2.6 is different for this.
console=ttyCPM0 should be there, and that device does have different major/minor comparing to ttyS0.
Note that the UART has to be enabled explicitly in kernel config, for more info, search this list archives.
> We also checked our "/dev" and there was a link to console, pointing
> ttyS0. Also, ttyS0 was there too.
>
> Does anyone have any idea how to fix it?
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] G4+ oprofile support
From: Andy Fleming @ 2005-12-16 21:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <E9EFF872-D403-437F-9B73-595D10BD71AF@kernel.crashing.org>
On Dec 15, 2005, at 21:42, Kumar Gala wrote:
>
> Why hard code this, num_ctrs is passed in?
It's passed in, true, but only because that's the common interface.
There is no 7450 derivative with less than or greater than 6
counters. I made it a constant to avoid the use (in the other
models) of a global variable. If you look at the next function down,
it doesn't get num_ctrs passed in, but needs to loop, anyway. And
there's another function which needs it, too.
>
> Does, classic include ppc64? if so you should be more explicit in
> the comment.
ppc64 and ppc32. All non-Freescale-book-e parts. Would:
Classic PPC parts (both 64 and 32 bit) don't support per-counter user/
kernel selection
be better?
>
>> + /* Classic doesn't support per-counter user/kernel selection */
>> unsigned long kernel;
>> -#ifdef __powerpc64__
>> - /* We dont support per counter user/kernel selection */
>> -#endif
>> unsigned long user;
>> unsigned long unit_mask;
>> };
>>
>
> Are these ifdef's really worth it?
I don't really like them, but the alternative is to define SPRN_PMC
[7,8] for PPC 32, which would be bogus, since PPC 32 doesn't have
them. If both architectures used the same SPR numbers, that wouldn't
be an issue, but they don't, so I would have to make up the SPR numbers.
>
>> +
>> +/* No PPC32 chip has more than 6 so far */
>> +#ifdef CONFIG_PPC64
>> case 6:
>> return mfspr(SPRN_PMC7);
>> case 7:
>> return mfspr(SPRN_PMC8);
>> +#endif
>> default:
>> return 0;
>> }
>> @@ -108,16 +117,20 @@ static inline void ctr_write(unsigned in
>> case 5:
>> mtspr(SPRN_PMC6, val);
>> break;
>> +
>> +/* No PPC32 chip has more than 6, yet */
>> +#ifdef CONFIG_PPC64
>> case 6:
>> mtspr(SPRN_PMC7, val);
>> break;
>> case 7:
>> mtspr(SPRN_PMC8, val);
>> break;
>> +#endif
>> default:
>> break;
>> }
>> }
>> -#endif /* __powerpc64__ */
>> +#endif /* !CONFIG_FSL_BOOKE */
>
> Why not move all MMCR0_ defines up ?
>
There are two reasons:
1) All of these registers have different SPR numbers on 32 and 64 bit
classic architectures, so the SPRN definitions would have to be
separate anyway
2) A number of the bit fields are different, too. There's overlap,
but it seemed more readable to group the bitfield definitions with
the SPRNs, rather than split the #defines into three groups. I could
do that, if the current solution is unacceptable, but my personal
opinion is that it's cleaner this way.
>> /* Bit definitions for MMCR0 and PMC1 / PMC2. */
>> #define MMCR0_PMC1_CYCLES (1 << 7)
>> @@ -458,7 +481,6 @@
>> #define MMCR0_PMC2_CYCLES 0x1
>> #define MMCR0_PMC2_ITLB 0x7
>> #define MMCR0_PMC2_LOADMISSTIME 0x5
>> -#define MMCR0_PMXE (1 << 26)
>> #endif
Andy
^ permalink raw reply
* SMP on MV64460
From: Lance Ware @ 2005-12-16 22:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
Hello group,
I am currently working on a board which has MV64460 linked between two 7447a processors. I wanted to know if someone has been able to get the Linux 2.6 kernel working with any MV64xxx bridge.
Thanks,
Lance
[-- Attachment #2: Type: text/html, Size: 820 bytes --]
^ permalink raw reply
* Re: SMP on MV64460
From: Mark A. Greer @ 2005-12-16 22:26 UTC (permalink / raw)
To: Lance Ware; +Cc: linuxppc-embedded
In-Reply-To: <000601c6028c$85eaea80$2d01a8c0@jalexander>
Hi Lance,
On Fri, Dec 16, 2005 at 05:03:14PM -0500, Lance Ware wrote:
>
> Hello group,
>
> I am currently working on a board which has MV64460 linked between
> two 7447a processors. I wanted to know if someone has been able to get
> the Linux 2.6 kernel working with any MV64xxx bridge.
I think there are people out there that have made this work. However, I
haven't b/c I do not have access to any SMP hardware that has all of the
necessary h/w errata implemented.
Perhaps others that have hardware will speak up?
Mark
^ permalink raw reply
* [PATCH] ppc: ppc4xx_dma DMA_MODE_{READ,WRITE} fix
From: Al Viro @ 2005-12-16 22:35 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
DMA_MODE_{READ,WRITE} are declared in asm-powerpc/dma.h and their
declarations there match the definitions. Old declarations in
ppc4xx_dma.h are not right anymore (wrong type, to start with).
Killed them, added include of asm/dma.h where needed.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
arch/ppc/syslib/ppc4xx_dma.c | 1 +
include/asm-ppc/ppc4xx_dma.h | 3 ---
2 files changed, 1 insertions(+), 3 deletions(-)
fc830a6f62230c04590f711798ea8de44e567439
diff --git a/arch/ppc/syslib/ppc4xx_dma.c b/arch/ppc/syslib/ppc4xx_dma.c
index f15e642..05ccd59 100644
--- a/arch/ppc/syslib/ppc4xx_dma.c
+++ b/arch/ppc/syslib/ppc4xx_dma.c
@@ -30,6 +30,7 @@
#include <asm/system.h>
#include <asm/io.h>
+#include <asm/dma.h>
#include <asm/ppc4xx_dma.h>
ppc_dma_ch_t dma_channels[MAX_PPC4xx_DMA_CHANNELS];
diff --git a/include/asm-ppc/ppc4xx_dma.h b/include/asm-ppc/ppc4xx_dma.h
index a415001..46a086f 100644
--- a/include/asm-ppc/ppc4xx_dma.h
+++ b/include/asm-ppc/ppc4xx_dma.h
@@ -33,9 +33,6 @@
#define MAX_PPC4xx_DMA_CHANNELS 4
-/* in arch/ppc/kernel/setup.c -- Cort */
-extern unsigned long DMA_MODE_WRITE, DMA_MODE_READ;
-
/*
* Function return status codes
* These values are used to indicate whether or not the function
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH] ppc: booke_wdt compile fix
From: Al Viro @ 2005-12-16 22:35 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
booke_wdt.c had been missed in cpu_specs[] removal sweep
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
drivers/char/watchdog/booke_wdt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
c845a90e7ff367deb10a66dbf37c3709b8d76325
diff --git a/drivers/char/watchdog/booke_wdt.c b/drivers/char/watchdog/booke_wdt.c
index c800cce..b664060 100644
--- a/drivers/char/watchdog/booke_wdt.c
+++ b/drivers/char/watchdog/booke_wdt.c
@@ -173,7 +173,7 @@ static int __init booke_wdt_init(void)
int ret = 0;
printk (KERN_INFO "PowerPC Book-E Watchdog Timer Loaded\n");
- ident.firmware_version = cpu_specs[0].pvr_value;
+ ident.firmware_version = cur_cpu_spec->pvr_value;
ret = misc_register(&booke_wdt_miscdev);
if (ret) {
--
0.99.9.GIT
^ permalink raw reply related
* POSIX High Resolution Timers in LinuxPPC 2.4
From: Martin, Tim @ 2005-12-16 22:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 531 bytes --]
Could someone give me a brief history lesson on POSIX high resolution timers
(e.g. timer_create() function) implemented in the Linux kernel on the
PowerPC 405 architecture? Specifically:
Confirm they are in the mainline 2.6 kernel now (e.g. kernel.org)?
Were they ever a part of the "mainline" 2.4 linuxppc kernel (e.g
ppc.bkbits.net)?
If no, were they ever available as a patch? The stuff at
sourceforge.net/projects/high-res-timers stops at 2.4.20 and looks like it
was only ever working for i386, not ppc.
Tim
[-- Attachment #2: Type: text/html, Size: 2665 bytes --]
^ permalink raw reply
* Re: Required functions for relocating not part of relocate section
From: Tom Rini @ 2005-12-16 23:04 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <20051104180605.GA3271@logos.cnet>
On Fri, Nov 04, 2005 at 04:06:05PM -0200, Marcelo Tosatti wrote:
> Hi Paul,
>
> Recent 2.6-git (from Wednesday) tree fails to boot on 8xx due to:
>
> BDI>i
> Target state : debug mode
> Debug entry cause : trace
> Current PC : 0x005ba8e8
> BDI>md 0x005ba8e8
> 005ba8e8 : 00000000 00000000 00000000 00000000 ................
> 005ba8f8 : 00000000 00000000 00000000 00000000 ................
> 005ba908 : 00000000 00000000 00000000 00000000 ................
> 005ba918 : 00000000 00000000 00000000 00000000 ................
> 005ba928 : 00000000 00000000 00000000 00000000 ................
> ...
> BDI>go
> - TARGET: stopped
> BDI>i
> Target state : debug mode
> Debug entry cause : software emulation exception
> Current PC : 0x005ba8e8
>
> Problem is that flush_instruction_cache (and flush_data_cache)
> from boot/common/util.S are not being copied to the relocate section,
> even though the file contains the proper entry:
So while I don't know why, someone else noted this problem to me
recently, as hit on I believe the Walnut (405GP Eval), saying that
flush_instruction_cache worked prior to relocation, but failed
afterwards. And if the function was put into the .data section, all was
well (_GLOBAL changed meaning 'recently' which changed this behavior).
No solution, but hopefully more hints..
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Typo in arch/ppc/kernel/head.S?
From: Benjamin Herrenschmidt @ 2005-12-17 0:43 UTC (permalink / raw)
To: Andrei Warkentin; +Cc: linuxppc-dev
In-Reply-To: <61AB94A8-8912-4699-A32A-70AC1155BA34@dataarmor.net>
On Fri, 2005-12-16 at 01:35 -0600, Andrei Warkentin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hello,
>
> I was looking at head.S under arch/ppc/kernel and it seems the
> comment above ".globl __start" is slightly off. Under
> the PMAC section it mentions that .text/.data/.bss are loaded @ 0x0,
> while they could be pretty much loaded anywhere but 0x0, with OF
> exception vectors being there. Am I understanding this correctly?
The comment is pre-historical :) The zImage used to put the kernel at 0
and BootX puts it there too, but the former has been changed. The kernel
can indeed be loaded pretty much anywhere.
Ben.
^ permalink raw reply
* Re: Powermac real-mode? setting?
From: Benjamin Herrenschmidt @ 2005-12-17 0:45 UTC (permalink / raw)
To: Andrei Warkentin; +Cc: linuxppc-dev
In-Reply-To: <E6B18F88-0CD3-4832-8BB6-232580280009@gmail.com>
On Fri, 2005-12-16 at 02:53 -0600, Andrei Warkentin wrote:
> Hello,
>
> As far as I understand, linux expects to be started in virt-mode,
> with MMU on.
No, Linux doesn't care. All it expects is that if MMU is on, it will be
started with a 1:1 mapping. In fact, pSeries (and CHRP) generally boot
in real mode, as does BootX.
> Does anyone know if setting real-mode? to true will work correctly? I'm
> trying to get something in the way of a home-brew
> kernel going on an G4 OF 3.0-based machine, and was wondering if it
> was possible to start out with the MMU off.
I doubt Apple's OF 3.0 will boot at all in real mode :) It's not a
kernel problem per-se, it's Apple's OF who tend to really only work in
virtual mode nowadays.
There should be no problem however switching MMU off from within your
"home brew" kernel. Look at how the linux kernel does in head.S
> Thank you very much and have a nice day.
>
> Andrei Warkentin
> andrey.warkentin@gmail.com
> Cell: (+1) (847) 321-15-55
> Office: (+1) (312) 756-15-00 x614
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 2.6 2/2] usb/input: Add Geyser 2 support to appletouch driver
From: Michael Hanselmann @ 2005-12-17 1:19 UTC (permalink / raw)
To: linux-kernel; +Cc: kernel-stuff, linuxppc-dev, linux-input
In-Reply-To: <20051213224019.GC20017@hansmi.ch>
This patch adds support for the Geyser 2 touchpads used on post Oct 2005
Apple PowerBooks to the appletouch driver.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Acked-by: Rene Nussbaumer <linux-kernel@killerfox.forkbomb.ch>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Stelian Pop <stelian@popies.net>
---
Rediffed without relayfs and made loops out of the manually unrolled
assignment code.
diff -rup linux-2.6.15-rc5.orig/Documentation/input/appletouch.txt b/Documentation/input/appletouch.txt
--- linux-2.6.15-rc5.orig/Documentation/input/appletouch.txt 2005-12-13 00:09:24.000000000 +0100
+++ b/Documentation/input/appletouch.txt 2005-12-17 02:06:27.000000000 +0100
@@ -3,7 +3,7 @@ Apple Touchpad Driver (appletouch)
Copyright (C) 2005 Stelian Pop <stelian@popies.net>
appletouch is a Linux kernel driver for the USB touchpad found on post
-February 2005 Apple Alu Powerbooks.
+February 2005 and October 2005 Apple Aluminium Powerbooks.
This driver is derived from Johannes Berg's appletrackpad driver[1], but it has
been improved in some areas:
@@ -13,7 +13,8 @@ been improved in some areas:
Credits go to Johannes Berg for reverse-engineering the touchpad protocol,
Frank Arnold for further improvements, and Alex Harper for some additional
-information about the inner workings of the touchpad sensors.
+information about the inner workings of the touchpad sensors. Michael
+Hanselmann added support for the October 2005 models.
Usage:
------
diff -rup linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c b/drivers/usb/input/appletouch.c
--- linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c 2005-12-13 22:44:24.000000000 +0100
+++ b/drivers/usb/input/appletouch.c 2005-12-17 02:13:02.000000000 +0100
@@ -6,6 +6,7 @@
* Copyright (C) 2005 Stelian Pop (stelian@popies.net)
* Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
* Copyright (C) 2005 Peter Osterlund (petero2@telia.com)
+ * Copyright (C) 2005 Michael Hanselmann (linux-kernel@hansmi.ch)
*
* Thanks to Alex Harper <basilisk@foobox.net> for his inputs.
*
@@ -38,6 +39,11 @@
/* Apple has powerbooks which have the keyboard with different Product IDs */
#define APPLE_VENDOR_ID 0x05AC
+/* These names come from Info.plist in AppleUSBTrackpad.kext */
+#define GEYSER_ANSI_PRODUCT_ID 0x0214
+#define GEYSER_ISO_PRODUCT_ID 0x0215
+#define GEYSER_JIS_PRODUCT_ID 0x0216
+
#define ATP_DEVICE(prod) \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
USB_DEVICE_ID_MATCH_INT_CLASS | \
@@ -53,13 +59,17 @@ static struct usb_device_id atp_table []
{ ATP_DEVICE(0x020F) },
{ ATP_DEVICE(0x030A) },
{ ATP_DEVICE(0x030B) },
- { } /* Terminating entry */
+
+ /* PowerBooks Oct 2005 */
+ { ATP_DEVICE(GEYSER_ANSI_PRODUCT_ID) },
+ { ATP_DEVICE(GEYSER_ISO_PRODUCT_ID) },
+ { ATP_DEVICE(GEYSER_JIS_PRODUCT_ID) },
+
+ /* Terminating entry */
+ { }
};
MODULE_DEVICE_TABLE (usb, atp_table);
-/* size of a USB urb transfer */
-#define ATP_DATASIZE 81
-
/*
* number of sensors. Note that only 16 instead of 26 X (horizontal)
* sensors exist on 12" and 15" PowerBooks. All models have 16 Y
@@ -108,6 +118,8 @@ struct atp {
signed char xy_old[ATP_XSENSORS + ATP_YSENSORS];
/* accumulated sensors */
int xy_acc[ATP_XSENSORS + ATP_YSENSORS];
+ int overflowwarn; /* overflow warning printed? */
+ int datalen; /* size of an USB urb transfer */
};
#define dbg_dump(msg, tab) \
@@ -124,7 +136,7 @@ struct atp {
if (debug) printk(format, ##a); \
} while (0)
-MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold");
+MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold, Michael Hanselmann");
MODULE_DESCRIPTION("Apple PowerBooks USB touchpad driver");
MODULE_LICENSE("GPL");
@@ -132,6 +144,16 @@ static int debug = 1;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Activate debugging output");
+/* Checks if the device a Geyser 2 (ANSI, ISO, JIS) */
+static inline int atp_is_geyser_2(struct atp *dev)
+{
+ int16_t productId = le16_to_cpu(dev->udev->descriptor.idProduct);
+
+ return (productId == GEYSER_ANSI_PRODUCT_ID) ||
+ (productId == GEYSER_ISO_PRODUCT_ID) ||
+ (productId == GEYSER_JIS_PRODUCT_ID);
+}
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -168,13 +190,20 @@ static inline void atp_report_fingers(st
static void atp_complete(struct urb* urb, struct pt_regs* regs)
{
int x, y, x_z, y_z, x_f, y_f;
- int retval, i;
+ int retval, i, j;
struct atp *dev = urb->context;
switch (urb->status) {
case 0:
/* success */
break;
+ case -EOVERFLOW:
+ if(!dev->overflowwarn) {
+ printk("appletouch: OVERFLOW with data "
+ "length %d, actual length is %d\n",
+ dev->datalen, dev->urb->actual_length);
+ dev->overflowwarn = 1;
+ }
case -ECONNRESET:
case -ENOENT:
case -ESHUTDOWN:
@@ -189,23 +218,45 @@ static void atp_complete(struct urb* urb
}
/* drop incomplete datasets */
- if (dev->urb->actual_length != ATP_DATASIZE) {
+ if (dev->urb->actual_length != dev->datalen) {
dprintk("appletouch: incomplete data package.\n");
goto exit;
}
/* reorder the sensors values */
- for (i = 0; i < 8; i++) {
- /* X values */
- dev->xy_cur[i ] = dev->data[5 * i + 2];
- dev->xy_cur[i + 8] = dev->data[5 * i + 4];
- dev->xy_cur[i + 16] = dev->data[5 * i + 42];
- if (i < 2)
- dev->xy_cur[i + 24] = dev->data[5 * i + 44];
-
- /* Y values */
- dev->xy_cur[i + 26] = dev->data[5 * i + 1];
- dev->xy_cur[i + 34] = dev->data[5 * i + 3];
+ if (atp_is_geyser_2(dev)) {
+ memset(dev->xy_cur, 0, sizeof(dev->xy_cur));
+
+ /*
+ * The values are laid out like this:
+ * Y1, Y2, -, Y3, Y4, -, ..., X1, X2, -, X3, X4, -, ...
+ * '-' is an unused value.
+ */
+
+ /* read X values */
+ for (i = 0, j = 19; i < 20; i += 2, j += 3) {
+ dev->xy_cur[i] = dev->data[j];
+ dev->xy_cur[i + 1] = dev->data[j + 1];
+ }
+
+ /* read Y values */
+ for (i = 0, j = 1; i < 9; i += 2, j += 3) {
+ dev->xy_cur[ATP_XSENSORS + i] = dev->data[j];
+ dev->xy_cur[ATP_XSENSORS + i + 1] = dev->data[j + 1];
+ }
+ } else {
+ for (i = 0; i < 8; i++) {
+ /* X values */
+ dev->xy_cur[i ] = dev->data[5 * i + 2];
+ dev->xy_cur[i + 8] = dev->data[5 * i + 4];
+ dev->xy_cur[i + 16] = dev->data[5 * i + 42];
+ if (i < 2)
+ dev->xy_cur[i + 24] = dev->data[5 * i + 44];
+
+ /* Y values */
+ dev->xy_cur[i + 26] = dev->data[5 * i + 1];
+ dev->xy_cur[i + 34] = dev->data[5 * i + 3];
+ }
}
dbg_dump("sample", dev->xy_cur);
@@ -216,16 +267,24 @@ static void atp_complete(struct urb* urb
dev->x_old = dev->y_old = -1;
memcpy(dev->xy_old, dev->xy_cur, sizeof(dev->xy_old));
- /* 17" Powerbooks have 10 extra X sensors */
- for (i = 16; i < ATP_XSENSORS; i++)
- if (dev->xy_cur[i]) {
- printk("appletouch: 17\" model detected.\n");
+ /* 17" Powerbooks have extra X sensors */
+ for (i = (atp_is_geyser_2(dev)?15:16); i < ATP_XSENSORS; i++) {
+ if (!dev->xy_cur[i]) continue;
+
+ printk("appletouch: 17\" model detected.\n");
+ if(atp_is_geyser_2(dev))
+ input_set_abs_params(dev->input, ABS_X, 0,
+ (20 - 1) *
+ ATP_XFACT - 1,
+ ATP_FUZZ, 0);
+ else
input_set_abs_params(dev->input, ABS_X, 0,
(ATP_XSENSORS - 1) *
ATP_XFACT - 1,
ATP_FUZZ, 0);
- break;
- }
+
+ break;
+ }
goto exit;
}
@@ -282,7 +341,8 @@ static void atp_complete(struct urb* urb
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
- input_report_key(dev->input, BTN_LEFT, !!dev->data[80]);
+ input_report_key(dev->input, BTN_LEFT,
+ !!dev->data[dev->datalen - 1]);
input_sync(dev->input);
@@ -353,6 +413,8 @@ static int atp_probe(struct usb_interfac
dev->udev = udev;
dev->input = input_dev;
+ dev->overflowwarn = 0;
+ dev->datalen = (atp_is_geyser_2(dev)?64:81);
dev->urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->urb) {
@@ -360,7 +422,7 @@ static int atp_probe(struct usb_interfac
goto err_free_devs;
}
- dev->data = usb_buffer_alloc(dev->udev, ATP_DATASIZE, GFP_KERNEL,
+ dev->data = usb_buffer_alloc(dev->udev, dev->datalen, GFP_KERNEL,
&dev->urb->transfer_dma);
if (!dev->data) {
retval = -ENOMEM;
@@ -369,7 +431,7 @@ static int atp_probe(struct usb_interfac
usb_fill_int_urb(dev->urb, udev,
usb_rcvintpipe(udev, int_in_endpointAddr),
- dev->data, ATP_DATASIZE, atp_complete, dev, 1);
+ dev->data, dev->datalen, atp_complete, dev, 1);
usb_make_path(udev, dev->phys, sizeof(dev->phys));
strlcat(dev->phys, "/input0", sizeof(dev->phys));
@@ -385,14 +447,25 @@ static int atp_probe(struct usb_interfac
set_bit(EV_ABS, input_dev->evbit);
- /*
- * 12" and 15" Powerbooks only have 16 x sensors,
- * 17" models are detected later.
- */
- input_set_abs_params(input_dev, ABS_X, 0,
- (16 - 1) * ATP_XFACT - 1, ATP_FUZZ, 0);
- input_set_abs_params(input_dev, ABS_Y, 0,
- (ATP_YSENSORS - 1) * ATP_YFACT - 1, ATP_FUZZ, 0);
+ if (atp_is_geyser_2(dev)) {
+ /*
+ * Oct 2005 15" PowerBooks have 15 X sensors, 17" are detected
+ * later.
+ */
+ input_set_abs_params(input_dev, ABS_X, 0,
+ ((15 - 1) * ATP_XFACT) - 1, ATP_FUZZ, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0,
+ ((9 - 1) * ATP_YFACT) - 1, ATP_FUZZ, 0);
+ } else {
+ /*
+ * 12" and 15" Powerbooks only have 16 x sensors,
+ * 17" models are detected later.
+ */
+ input_set_abs_params(input_dev, ABS_X, 0,
+ (16 - 1) * ATP_XFACT - 1, ATP_FUZZ, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0,
+ (ATP_YSENSORS - 1) * ATP_YFACT - 1, ATP_FUZZ, 0);
+ }
input_set_abs_params(input_dev, ABS_PRESSURE, 0, ATP_PRESSURE, 0, 0);
set_bit(EV_KEY, input_dev->evbit);
@@ -427,7 +500,7 @@ static void atp_disconnect(struct usb_in
usb_kill_urb(dev->urb);
input_unregister_device(dev->input);
usb_free_urb(dev->urb);
- usb_buffer_free(dev->udev, ATP_DATASIZE,
+ usb_buffer_free(dev->udev, dev->datalen,
dev->data, dev->urb->transfer_dma);
kfree(dev);
}
^ permalink raw reply
* Re: Unable to open an initial console
From: Nigel Cunningham @ 2005-12-17 5:23 UTC (permalink / raw)
To: Addison Baldwin; +Cc: linuxppc-embedded
In-Reply-To: <af313df20512161201u39280d30kdf1ace1c4569d50a@mail.gmail.com>
Hi.
On Sat, 2005-12-17 at 06:01, Addison Baldwin wrote:
> I was sucessful to port U-Boot to our 8272 board. Now I'm experiencing
> a problem:
>
> Our Kernel hangs with the message that says it was trasnferring
> control to linux. A post morten analyzes indicated that it stopped at
> "Unable to open an initial console" in the memory sapce where console
> output should be out (in the sdram, like I had found somewhere in this
> list, how to do it).
>
> I have checked the bootargs values, it is ok:
> bootargs root=/dev/ram console=ttyS0,115200
>
> We also checked our "/dev" and there was a link to console, pointing
> ttyS0. Also, ttyS0 was there too.
Are you using an initrd or initramfs? If so, the device node needs to
exist on that filesystem. This message will only occur if the kernel is
unable to open /dev/console for rw access.
Hope this helps.
Nigel
^ permalink raw reply
* Building a Root Filesystem
From: Michael Boutte @ 2005-12-17 8:17 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I seem to be stuck at one point in my first embedded Linux project. I
built a custom MPC875 board and have figured out how to get U-Boot to
compile and run. Then I learned to compile an initial Linux 2.4.25 using
the ELDK with a basic root filesystem via the "SELF" included in the
ELDK (thank you WD and others). Now I want to build a new root
filesystem with the modules included. So then I have used the "make
modules" and "make ... modules_install" commands plus used the procedure
in the DULG section 9.6 to unpack the ramdisk image and mount it in the
/mnt/tmp/ directory.
That is point where I do not know what to do next. It would seem that I
need to merge the modules and other items I may want to add (for example
appWeb) with the simple root filesystem and re-compress it for use just
like the original ramdisk image. I just do not seem to find any
information on this process either in the DULG or anywhere else on the web.
Any help would be greatly appreciated.
Mike Boutte
^ permalink raw reply
* Re: Building a Root Filesystem
From: bennett78 @ 2005-12-17 18:32 UTC (permalink / raw)
To: Michael Boutte; +Cc: linuxppc-embedded
In-Reply-To: <43A3C9B2.6040401@pacbell.net>
Michael Boutte wrote:
> Hi,
> I seem to be stuck at one point in my first embedded Linux project. I
> built a custom MPC875 board and have figured out how to get U-Boot to
> compile and run. Then I learned to compile an initial Linux 2.4.25
> using the ELDK with a basic root filesystem via the "SELF" included in
> the ELDK (thank you WD and others). Now I want to build a new root
> filesystem with the modules included. So then I have used the "make
> modules" and "make ... modules_install" commands plus used the
> procedure in the DULG section 9.6 to unpack the ramdisk image and
> mount it in the /mnt/tmp/ directory.
> That is point where I do not know what to do next. It would seem that
> I need to merge the modules and other items I may want to add (for
> example appWeb) with the simple root filesystem and re-compress it for
> use just like the original ramdisk image. I just do not seem to find
> any information on this process either in the DULG or anywhere else on
> the web.
> Any help would be greatly appreciated.
I'm also using Linux 2.4.25 using the ELDK and I would recommend
getting a NFS root file system going first discussed in the following
paper, although written for a MPC5200 is an excellent guideline:
http://emsys.denayer.wenk.be/emcam/Linux_on_MPC5200_(UK).pdf
Worry about a compressed system later. There is also a script for
building a
small root file system (mkrootfsdenx) from a working reference one and
MTD is the way to go to manage your flash for F/W updates and NVdata store.
happy ELDKing,
Frank Bennett
>
> Mike Boutte
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Benjamin Herrenschmidt @ 2005-12-17 21:59 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <200512062048.56131.arnd@arndb.de>
> - Do we need a way to identify the type of soc bus? There are different
> standards for this, e.g. PLB4 on PPC440 or the EIB on the Cell BE.
> My initial idea was to have different device-type properties for these,
> but I now think that device_type = "soc" makes sense for all of them.
> Maybe we could add a model or compatible property for them.
That would be a good idea.
Also, it might be useful to ass a "clock-frequency" to it for processors
where it makes sense. One of the things we are passing from uboot
currently is the list of clock frequencies for PLB/OPB/PCI/... we need
to replace this with appropriate nodes and their respective
"clock-frequency" properties
> - It does not really belong into this document, but is related anyway:
> how do you want to represent this in Linux? Currently, most of these
> would be of_platform_device, but I think it would be good to have
> a new bus_type for it. The advantage would be that you can see the
> devices in /sys/devices/soc@xxx/ even if the driver is not loaded
> and the driver can even be autoloaded by udev.
> Also, which properties should show up in sysfs? All of them or just
> those specified in this document or a subset of them?
If we go that way, we also need to have the SOC type take optionally
part in the matching. That is, the driver matching infos should be based
on model & compatible like OF does, thus we could recommend something
like:
- Define a unique SOC name per SOC bus type/family, for example,
ppc4xxPLB, etc... This goes into /soc/model.
- Optionally, use compatible for similar busses. For example, if you
have a new rev of that PLB that is similar but has extensions called
PLB2, you can have model be ppc4xxPLB2 and compatible containing
ppc4xxPLB.
- Define that the "model" property of a device under /soc is of the
form "socname,devicename"... For example, EMAC would be ppc4xxPLB,emac",
Same rule applies with compatible (this one could be compatible, among
others, with "ppc4xxPLB,emac" and model "ppc4xxPLB2,emac".
> - What do we do with pci root devices? They are often physically connected
> to the internal CPU bus, so it would make sense to represent them
> this way in the device tree. Should we add them to the specification
> here? Would it even work the expected way in Linux?
They are generally below the root of the tree, they don't have to
though. Linux shouldn't care as there is no generic code to instanciate
them, it's platform specific. I may change that in the future though but
this isn't the case yet. The only rule is their name should be "pci"
> - For some devices, you mandate a model property, for others you don't.
> Is this intentional? It might be easier to find the right device
> driver if the match string always contains a model name.
>
> - How would I represent nested interrupt controllers? E.g. suppose I
> have a Cell internal interrupt controller on one SOC bus and
> and an external interrupt controller on another SOC bus but have
> that deliver interrupts to the first one.
Read OF interrupt binding :) Typically, nodes contain either an
interrupt-parent or a parent device with interrupt routing info (like a
PCI bridge) which points to their actual parent controller. If it's a
nested controller, it will itself have an interrupt parent and
"interrupts" property to link it to its parent controller.
> - Should it mention nested SOC buses, e.g. a PLB4 bus connected to a
> PLB5 bus?
>
Do we have many of these horrors in real life ?
> - The title says 'without Open Firmware', but it should also be allowed
> to use the same SOC bus layout when using SLOF or some other OF
> implementation, right?
Yes, in fact, this document does cover open firmware as well. It defines
the flattened tree format, but doesn't exclude open firmware, and then
defines the subset of OF required by the kernel.
> - Also not new in this version, but still: Should there be support for
> specifying CPUs with multiple SMT threads?
We need to think about this...
Ben.
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Segher Boessenkool @ 2005-12-18 6:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Arnd Bergmann, linuxppc64-dev
In-Reply-To: <1134856762.6102.54.camel@gaston>
>> - Do we need a way to identify the type of soc bus? There are
>> different
>> standards for this, e.g. PLB4 on PPC440 or the EIB on the Cell BE.
>> My initial idea was to have different device-type properties for
>> these,
>> but I now think that device_type = "soc" makes sense for all of
>> them.
>> Maybe we could add a model or compatible property for them.
>
> That would be a good idea.
"device_type" is what defines the (OF) programming interface. As not
all SoC busses are identical for this, they should not have the same
device_type.
If you do want all of those semi-transparent SoC busses to be found
by one wildcard, you can add it to the "compatible" property.
> Also, it might be useful to ass a "clock-frequency" to it for
> processors
> where it makes sense.
Certainly.
> One of the things we are passing from uboot
> currently is the list of clock frequencies for PLB/OPB/PCI/... we need
> to replace this with appropriate nodes and their respective
> "clock-frequency" properties
>
>> - It does not really belong into this document, but is related anyway:
>> how do you want to represent this in Linux? Currently, most of these
>> would be of_platform_device, but I think it would be good to have
>> a new bus_type for it. The advantage would be that you can see the
>> devices in /sys/devices/soc@xxx/ even if the driver is not loaded
>> and the driver can even be autoloaded by udev.
>> Also, which properties should show up in sysfs? All of them or just
>> those specified in this document or a subset of them?
All that make sense.
> If we go that way, we also need to have the SOC type take optionally
> part in the matching. That is, the driver matching infos should be
> based
> on model & compatible like OF does, thus we could recommend something
> like:
>
> - Define a unique SOC name per SOC bus type/family, for example,
> ppc4xxPLB, etc... This goes into /soc/model.
"model" should be a string that is the "official" vendor name for
the device.
> - Optionally, use compatible for similar busses. For example, if you
> have a new rev of that PLB that is similar but has extensions called
> PLB2, you can have model be ppc4xxPLB2 and compatible containing
> ppc4xxPLB.
"compatible" does not contain alternatives for "model"; it contains
alternatives for "name".
> - Define that the "model" property of a device under /soc is of the
> form "socname,devicename"... For example, EMAC would be
> ppc4xxPLB,emac",
> Same rule applies with compatible (this one could be compatible, among
> others, with "ppc4xxPLB,emac" and model "ppc4xxPLB2,emac".
>
>> - What do we do with pci root devices? They are often physically
>> connected
>> to the internal CPU bus, so it would make sense to represent them
>> this way in the device tree. Should we add them to the specification
>> here? Would it even work the expected way in Linux?
>
> They are generally below the root of the tree, they don't have to
> though. Linux shouldn't care as there is no generic code to instanciate
> them, it's platform specific. I may change that in the future though
> but
> this isn't the case yet. The only rule is their name should be "pci"
No. Their name can be whatever is required. The "device_type" should
be "pci", for conventional PCI busses; and it should be whatever is
defined by the appropriate OF binding for newer, mostly PCI-comnpatible,
busses (like HT, PCIe, PCI-X, etc.)
>> - For some devices, you mandate a model property, for others you
>> don't.
>> Is this intentional? It might be easier to find the right device
>> driver if the match string always contains a model name.
It is up to a device's parent bus to find the correct driver; for
the parent bus, device_type and/or compatible are normally enough
to do the matching. "model" is useful to disambiguate sometimes,
but it normally is _too_ exact to do useful driver matching.
>> - How would I represent nested interrupt controllers? E.g. suppose I
>> have a Cell internal interrupt controller on one SOC bus and
>> and an external interrupt controller on another SOC bus but have
>> that deliver interrupts to the first one.
>
> Read OF interrupt binding :) Typically, nodes contain either an
> interrupt-parent or a parent device with interrupt routing info (like a
> PCI bridge) which points to their actual parent controller. If it's a
> nested controller, it will itself have an interrupt parent and
> "interrupts" property to link it to its parent controller.
Interrupts are evil evil evil as always ;-)
>> - Should it mention nested SOC buses, e.g. a PLB4 bus connected to a
>> PLB5 bus?
>>
> Do we have many of these horrors in real life ?
Yes, almost every SoC has at least two busses; e.g., you often see
a high-speed coherent "system" bus, and a lower-speed non-coherent
I/O bus connected to it. But there are lots of variations to this
theme.
>> - The title says 'without Open Firmware', but it should also be
>> allowed
>> to use the same SOC bus layout when using SLOF or some other OF
>> implementation, right?
>
> Yes, in fact, this document does cover open firmware as well. It
> defines
> the flattened tree format, but doesn't exclude open firmware, and then
> defines the subset of OF required by the kernel.
>
>> - Also not new in this version, but still: Should there be support for
>> specifying CPUs with multiple SMT threads?
>
> We need to think about this...
SMT threads should not be represented as separate CPUs. But some
CPU resources that are described in a CPU node are non-shared between
SMT threads; we need to find a way to describe those.
The biggest problem is interrupts (as always); the unit-id for a
"cpu" node in OF is the IPI number of that CPU, but on SMT, IPIs
are per thread.
Segher
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox