* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Olaf Hering @ 2006-03-03 20:40 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20060303200920.GA8177@suse.de>
On Fri, Mar 03, Olaf Hering wrote:
> So the magic word is yaboot.
sp was 0x0023e6b4 when entering zImage.
yaboot_start has 64 bytes
yaboot_main has 304 bytes
This would mean the stackpointer for yaboot was 0x0023e824.
Will check on Monday.
^ permalink raw reply
* RE: Linux on PPC
From: Steve Strublic @ 2006-03-03 20:28 UTC (permalink / raw)
To: David Hawkins, Rune Torgersen; +Cc: linuxppc-embedded
> -----Original Message-----
> From: linuxppc-embedded-bounces+sstrublic=3Dhypercom.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+sstrublic=3Dhypercom.com@ozlabs.org]
On
> Behalf Of David Hawkins
> Sent: Friday, March 03, 2006 1:07 PM
> To: Rune Torgersen
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on PPC
>=20
>=20
> >>Right, thats I made sure to say; Physical Memory Map.
> >>
> >>For example, on the Artesyn manual on their PrPMC they give a
> >>physical memory map, and in the Yosemite board, there is a
> >>physical memory map. I know many of the memory areas can be
> >>redefined in hardware to have a different memory location, but
> >>its still a physical address.
> >>
> >
> > Still not right. Even the physical memory is software settable. What
> > matters is what chip-select things are hooked up to, and then map
those
> > chip selects correctly (size, base address, access with and so on)
>=20
> Hi Rune,
>=20
> Thanks for responding.
>=20
> Thats what I meant with 'redefined in hardware'. But yes, redefined
> up to the limit of the wiring on the board of course (chip-selects
> and bus widths). That's where having the board schematic is
> invaluable.
>=20
> But ok, I'm pretty sure I get the point, and hopefully the
> original poster understands a bit more too.
>=20
> Given a board that you expect to run Linux on, I would imagine
> you would select hardware settings consistent with making
> Linux happy, i.e., defining 'in software' (the bootloader)
> the physical address map (eg. like the Embedded Planet reference
> manual for the 440EP Yosemite board), and then setup U-Boot and
> Linux to program the TLBs to translate to those same addresses.
>=20
> When looking at the Yosemite board, I booted U-Boot and compared
> device dcr settings to the recommended ones in the EP manual. Then
> when I booted Linux, I took a look and found that on the whole, Linux
> didn't touch too much of the things setup by U-Boot, i.e., the
> responsibility for setting up the Linux environment was mainly
> the job of the bootloader.
>=20
> So, if I had a board with a custom bootloader, I would be
> concerned that the bootloader might not know enough about
> Linux, to setup the hardware correctly.
The boot loader should, ideally, NOT know anything about Linux except
for knowing that since a Linux is being loaded, it requires some
information at boot time, and the format in which to provide said
information.
Steve
>=20
> Does that sound right?
>=20
> Dave
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: powerpc: set ARCH_KMALLOC_MINALIGN if CONFIG_NOT_COHERENT_CACHE=y
From: Dale Farnsworth @ 2006-03-03 21:12 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060303200928.GA29099@xyzzy.farnsworth.org>
In article <20060303200928.GA29099@xyzzy.farnsworth.org> you write:
> Ensure that buffers returned by kmalloc do not share a cache
> line with other data when doing non-cache-coherent I/O.
Eugene Surovegin points out that ARCH_KMALLOC_MINALIGN
doesn't work as avertised.
This patch doesn't work.
Thanks,
-Dale
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Olaf Hering @ 2006-03-03 23:23 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <3E10742C-61F9-417C-A191-C0C8C46A4529@kernel.crashing.org>
On Fri, Mar 03, Segher Boessenkool wrote:
> > The stackpointer came from 32bit code, which appearently has different
> > alignment rules than 64bit code. The chain was yaboot -> zImage ->
> > vmlinux
> > Force the stackpointer to be 16 byte aligned.
>
> The stack pointer is required to be 16-byte aligned when the
> client program is started, on 32-bit as well.
See http://ozlabs.org/pipermail/linuxppc-dev/2006-March/021342.html
Either yaboot and/or zImage need to force a stack alignment, or we apply
the 2 liner.
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Paul Nasrat @ 2006-03-03 23:45 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060303232334.GA9577@suse.de>
On Sat, 2006-03-04 at 00:23 +0100, Olaf Hering wrote:
> On Fri, Mar 03, Segher Boessenkool wrote:
>
> > > The stackpointer came from 32bit code, which appearently has different
> > > alignment rules than 64bit code. The chain was yaboot -> zImage ->
> > > vmlinux
> > > Force the stackpointer to be 16 byte aligned.
> >
> > The stack pointer is required to be 16-byte aligned when the
> > client program is started, on 32-bit as well.
>
> See http://ozlabs.org/pipermail/linuxppc-dev/2006-March/021342.html
>
> Either yaboot and/or zImage need to force a stack alignment, or we apply
> the 2 liner.
Happy to look at/receive patches for yaboot. I'll look on Monday.
Paul
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Segher Boessenkool @ 2006-03-04 0:09 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060303232334.GA9577@suse.de>
>> The stack pointer is required to be 16-byte aligned when the
>> client program is started, on 32-bit as well.
>
> See http://ozlabs.org/pipermail/linuxppc-dev/2006-March/021342.html
>
> Either yaboot and/or zImage need to force a stack alignment, or we
> apply
> the 2 liner.
Yaboot should do it. Of course, it won't hurt if the kernel will
do it itself, too...
Segher
^ permalink raw reply
* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-04 2:05 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <44087473.6020905@ovro.caltech.edu>
In message <44087473.6020905@ovro.caltech.edu> you wrote:
>
> > Many memory maps (especially those provides with some eval boards for
> > demonstration purpose) will NOT work with Linux. Remember that the
> > memory map is usually not cast in silicon, but implemented in
> > software, so you can change it as needed.
>
> Right, thats I made sure to say; Physical Memory Map.
That's what I mean: the physical memory map is usually set up in
software, so it can be changed to your needs.
> For example, on the Artesyn manual on their PrPMC they give a
> physical memory map, and in the Yosemite board, there is a
> physical memory map. I know many of the memory areas can be
> redefined in hardware to have a different memory location, but
> its still a physical address.
...which usually can be reprogrammed in software.
> Now, when the bootloader loads, eg. U-Boot, it sets up the
> memory management. Now this is where my understanding gets
> shakey, since I haven't looked at much of the code, so perhaps
> you can clarify. The translation unit (TLB) maps virtual addresses
> (or should that be MMU output addresses) into physical addresses,
U-Boot usually does not use the MMU.
> What are the basic requirements for a Linux memory map then?
See the FAQ.
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
It is surely a great calamity for a human being to have no ob-
sessions. - Robert Bly
^ permalink raw reply
* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-04 2:09 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <4408A1D3.8010506@ovro.caltech.edu>
In message <4408A1D3.8010506@ovro.caltech.edu> you wrote:
>
> > Still not right. Even the physical memory is software settable. What
> > matters is what chip-select things are hooked up to, and then map those
> > chip selects correctly (size, base address, access with and so on)
>
> Thats what I meant with 'redefined in hardware'. But yes, redefined
> up to the limit of the wiring on the board of course (chip-selects
> and bus widths). That's where having the board schematic is
> invaluable.
You don't get it. You can map - for example - your flash to physical
address 0x0000 or 0x04000000 or 0x40000000 or 0xFFF00000 as you like
- without any changes to the hardware, and without using the MMU.
Mind: that's all *physical* addresses.
> manual for the 440EP Yosemite board), and then setup U-Boot and
> Linux to program the TLBs to translate to those same addresses.
No. U-Boot does not use the MMU.
> when I booted Linux, I took a look and found that on the whole, Linux
> didn't touch too much of the things setup by U-Boot, i.e., the
> responsibility for setting up the Linux environment was mainly
> the job of the bootloader.
Wrong again. Linux completely re-initializes the whole memory
management.
> So, if I had a board with a custom bootloader, I would be
> concerned that the bootloader might not know enough about
> Linux, to setup the hardware correctly.
>
> Does that sound right?
No, it's wrong.
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
"Language shapes the way we think, and determines what we can think
about." - B. L. Whorf
^ permalink raw reply
* Different Page Size Support in Linux on PPC870
From: atul.sabharwal @ 2006-03-04 2:38 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
On PPC870, does the kernel only support 4K pages? To reduce the size of
page table (level & level 2), would 8M page be a better choice on a
custom=20
board? It's a no swap configuration. Memory load is critical in our
design on this project.
Comments?
Thanks,
Atul
^ permalink raw reply
* Re: Linux on PPC
From: David Hawkins @ 2006-03-04 2:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060304020938.00774352627@atlas.denx.de>
Hi Wolfgang,
> You don't get it.
Ok, I'll read-up and try to 'get it'.
Thanks
Dave
^ permalink raw reply
* Re: boot failure on lite5200b board
From: Sylvain Munaut @ 2006-03-04 9:17 UTC (permalink / raw)
To: #LI JIANGGAN#; +Cc: haidong_feng, linuxppc-embedded
In-Reply-To: <84A109BF918D934CB46ACF33BCE187C002D54D96@mail02.student.main.ntu.edu.sg>
Hi,
#LI JIANGGAN# wrote:
> Thanks John, the Kernel now boots well. However it gives a kernel panic
> while mounting the root file sysem over NFS:
>
> Looking up port of RPC 100003/2 on 10.190.3.103
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get nfsd port number from server, using default
>
> I couldn't figure out why error 101 /* Network is unreachable */ is
> given. Below is my current U-boot settings and a snapshot of the booting:
Didn't I told you to try the tree I on http://gitbits.246tnt.com ?
I don't know the tree you're using but it doesn't seem to be mine ...
(nor any of the previous version i published).
I you want to have the most "complete" stuff i publish, clone the
mainstream, pull from my ide branch and then pull from the bestcomm branch.
There is also the denx tree but I don't know it's status.
> Linux version 2.6.11.7 (root@bob) (gcc version 3.3.2) #1 Tue Sep 6
> 22:40:03 UTC 2005
^^^^^^^^^^^^^^^^^^^^^^^^^^
my tree is based on something more recent
> Real-Time Preemption Support (c) Ingo Molnar
> Built 1 zonelists
> Kernel command line: console=ttyS0,115200
^^^^^^^^^^^^^^^^^^^^
You would see nothing with the tree of gitbits.246tNt.com with that
command line. You need ttyPSC0 ...
> nfsroot=10.190.3.103:/opt/eldk-4-0/nfs root=/dev/nfs rw
> PID hash table entries: 2048 (order: 11, 32768 bytes)
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 256268k available (2336k kernel code, 896k data, 140k init, 0k
> highmem)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> BUG: scheduling while atomic: swapper/0x00000001/0
> caller is schedule+0x50/0xe8
> Call trace:
> [c0006bd8] dump_stack+0x18/0x28
> [c0242818] __sched_text_start+0x69c/0x6a0
> [c024286c] schedule+0x50/0xe8
> [c0003f00] syscall_exit_work+0x108/0x10c
> [c030c578] proc_root_init+0x144/0x150
> [c0320000] 0xc0320000
> [c02fe624] start_kernel+0x180/0x1b8
> [000035fc] 0x35fc
> spawn_desched_task(00000000)
> desched cpu_callback 3/00000000
> ksoftirqd started up.
> softirq RT prio: 24.
> desched cpu_callback 2/00000000
> desched thread 0 started up.
> NET: Registered protocol family 16
>
> PCI: Probing PCI hardware
> SCSI subsystem initialized
> usbcore: registered new driver usbfs
> usbcore: registered new driver hub
> JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
> ppdev: user-space parallel port driver
> Serial: MPC52xx PSC driver
> ttyS0 at MMIO 0xf0002000 (irq = 39) is a MPC52xx PSC
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
> loop: loaded (max 8 devices)
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ipb=132MHz, set clock period to 7
> GPIO config: 91051024
> ATA invalid: 01000000
> ATA hostcnf: 03000000
> ATA pio1 : 100a0a00
> ATA pio2 : 02040600
> XLB Arb cnf: 0000a366
> mpc52xx_ide: Setting up IDE interface ide0...
> flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x0 in
> 8-bit bank
> flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x1000000
> in 8-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> flash chip on the Lite5200/Lite5200B: CFI does not contain boot bank
> location. Assuming top.
> number of CFI chips: 2
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> Creating 7 MTD partitions on "flash chip on the Lite5200/Lite5200B":
> 0x00000000-0x01000000 : "Filesystem"
> 0x01000000-0x01040000 : "BootLOW"
> 0x01040000-0x01060000 : "EnvLOW"
> 0x01060000-0x01d00000 : "Spare"
> 0x01d00000-0x01f00000 : "Kernel"
> 0x01f00000-0x01f40000 : "BootHIGH"
> 0x01f40000-0x01f60000 : "EnvHIGH"
> ocp-ohci 02: new USB bus registered, assigned bus number 1
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> Initializing USB Mass Storage driver...
> usbcore: registered new driver usb-storage
> USB Mass Storage support registered.
> usbcore: registered new driver usbhid
> drivers/usb/input/hid-core.c: v2.0:USB HID core driver
> mice: PS/2 mouse device common for all mice
> i2c /dev entries driver
> i2c-algo-52xx.o: scanning bus Lite5200 I2C module #1 interface...
> ................................................................................................................................
> i2c-lite5200.o: I2C module #1 installed
> i2c-algo-52xx.o: scanning bus Lite5200 I2C module #2 interface...
> ................................................................................(0x50)..............................................(0x7f)
> i2c-lite5200.o: I2C module #2 installed
> Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13
> 09:39:32 2005 UTC).
> ALSA device list:
> No soundcards found.
> NET: Registered protocol family 2
> IP: routing cache hash table of 256 buckets, 16Kbytes
> TCP established hash table entries: 16384 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 16384 (order: 7, 917504 bytes)
> TCP: Hash tables configured (established 16384 bind 16384)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Looking up port of RPC 100003/2 on 10.190.3.103
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get nfsd port number from server, using default
> Looking up port of RPC 100005/1 on 10.190.3.103
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get mountd port number from server, using default
> RPC: sendmsg returned error 101
> mount: RPC call returned error 101
> Root-NFS: Server returned error -101 while mounting /opt/eldk-4-0/nfs
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "nfs" or unknown-block(2,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
> <0>Rebooting in 180 seconds..
^ permalink raw reply
* [PATCH] correct cacheflush loop in zImage
From: Olaf Hering @ 2006-03-04 12:15 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Correct the loop for cacheflush. No idea where I copied the code from,
but the original does not work correct. Maybe the flush is not needed.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/boot/crt0.S | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/boot/crt0.S
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/boot/crt0.S
+++ linux-2.6.16-rc5-olh/arch/powerpc/boot/crt0.S
@@ -45,7 +45,8 @@ _zimage_start:
bdnz 2b
/* Do a cache flush for our text, in case OF didn't */
-3: lis r9,_start@h
+3: lis r9,_start@ha
+ addi r9,r9,_start@l
add r9,r0,r9
lis r8,_etext@ha
addi r8,r8,_etext@l
@@ -53,7 +54,7 @@ _zimage_start:
4: dcbf r0,r9
icbi r0,r9
addi r9,r9,0x20
- cmplwi 0,r9,8
+ cmplw cr0,r9,r8
blt 4b
sync
isync
^ permalink raw reply
* Re: [PATCH] correct cacheflush loop in zImage
From: Olaf Hering @ 2006-03-04 12:58 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
In-Reply-To: <20060304121540.GA30106@suse.de>
On Sat, Mar 04, Olaf Hering wrote:
>
> Correct the loop for cacheflush. No idea where I copied the code from,
> but the original does not work correct. Maybe the flush is not needed.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
>
> arch/powerpc/boot/crt0.S | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.16-rc5-olh/arch/powerpc/boot/crt0.S
> ===================================================================
> --- linux-2.6.16-rc5-olh.orig/arch/powerpc/boot/crt0.S
> +++ linux-2.6.16-rc5-olh/arch/powerpc/boot/crt0.S
> @@ -45,7 +45,8 @@ _zimage_start:
> bdnz 2b
>
> /* Do a cache flush for our text, in case OF didn't */
> -3: lis r9,_start@h
> +3: lis r9,_start@ha
> + addi r9,r9,_start@l
> add r9,r0,r9
I think this part is not required. Segments must be 64k aligned, so the
lower bits will be always zero (modulo the _start offset into .text)
^ permalink raw reply
* Re: incorrect rmo_top handling in prom_init
From: Olaf Hering @ 2006-03-04 15:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1141342541.13565.6.camel@localhost.localdomain>
On Fri, Mar 03, Benjamin Herrenschmidt wrote:
> On Thu, 2006-03-02 at 19:55 +0100, Olaf Hering wrote:
> > My iBook1 has 2 memory regions in reg. Depending on how I boot it
> > (vmlinux+initrd) or zImage.initrd, it will not boot with current Linus
> > tree.
> > rmo_top should be 160MB instead of 32MB.
>
> Does that fix it ?
Yes.
^ permalink raw reply
* Re: Different Page Size Support in Linux on PPC870
From: Dan Malek @ 2006-03-04 17:11 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201C47BE3@us-bv-m23.global.tektronix.net>
On Mar 3, 2006, at 9:38 PM, <atul.sabharwal@exgate.tek.com> wrote:
> On PPC870, does the kernel only support 4K pages?
The CONFIG_PIN_TLB will get you 8M pages for the kernel
space, and likely be a good solution for you. We have experimented
with various dynamic replace methods for the past several years,
but I still haven't found a solution I like.
-- Dan
^ permalink raw reply
* [PATCH] return to OF via trap, not exit
From: Olaf Hering @ 2006-03-04 19:10 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Do not call prom exit prom_panic. It clears the screen and the exit message is lost.
On some (or all?) pmacs it causes another crash when OF tries to print the
date and time in its banner.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/prom_init.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
@@ -398,7 +398,9 @@ static void __init __attribute__((noretu
#endif
prom_print(reason);
/* ToDo: should put up an SRC here on p/iSeries */
- call_prom("exit", 0, 0);
+ /* Do not call exit because it clears the screen on pmac
+ * it also causes some sort of double-fault on early pmacs */
+ asm("trap\n");
for (;;) /* should never get here */
;
^ permalink raw reply
* cross tools for the 440gp
From: Ralph Blach @ 2006-03-05 1:32 UTC (permalink / raw)
To: linuxppc-embedded
are there any prebuild cross compilers for the 440gp processors
that would compile a 2.6 kernel?
If so, could I get some pointer to where they are?
Thanks
Chip
^ permalink raw reply
* cross tools for the 440gp
From: Ralph Blach @ 2006-03-05 1:32 UTC (permalink / raw)
To: linuxppc-embedded
are there any prebuild cross compilers for the 440gp processors
that would compile a 2.6 kernel?
If so, could I get some pointer to where they are?
Thanks
Chip
^ permalink raw reply
* Re: cross tools for the 440gp
From: David Hawkins @ 2006-03-05 4:30 UTC (permalink / raw)
To: Ralph Blach; +Cc: linuxppc-embedded
In-Reply-To: <440A3FB4.6060806@blach.dnsalias.org>
Ralph Blach wrote:
> are there any prebuild cross compilers for the 440gp processors
> that would compile a 2.6 kernel?
>
> If so, could I get some pointer to where they are?
>
Download the Denx ELDK 4.0 CD-ROM it has everything you need.
http://www.denx.de
http://www.denx.de/wiki/view/DULG/ELDKAvailability
http://www.denx.de/wiki/view/DULG/ELDKDownloadPowerPC
The install file tells you how to install the tools,
http://www.denx.de/wiki/view/DULG/ELDKInitialInstallation
for example, I use the 440EP which has an FPU, so
to install the tools (from the ELDK CD-ROM after
mounting the iso image)
./install -d /opt/eldk-4.0 ppc_4xxFP
you'll want
./install -d /opt/eldk-4.0 ppc_4xx
Read the Denx UBoot+Linux Guide (DULG), it'll help.
Regards,
Dave
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-05 14:09 UTC (permalink / raw)
To: Linus Torvalds, linuxppc-dev; +Cc: Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0602262122000.22647@g5.osdl.org>
On Sun, Feb 26, Linus Torvalds wrote:
> Have I missed anything? Holler. And please keep reminding about any
> regressions since 2.6.15.
I see random memory corruption on an early G3 ibook.
Testcase is an openSuSE 10.1 installation. 2.6.15 works ok modulo 2 bugs
to get it booted at all, and the usual udev breakage.
plain 2.6.16-rc5-git7 locks up after a few packages, no ping.
Our SuSE kernel does not lockup, but ext2 shows access beyond end of
device after > 200 packages, or the rpmdb gets corrupt, or both. With reiserfs
it gets past 100 packages, then reiserfs complains about fs corruption.
plain -rc2 shows the same reiserfs corruption.
plain -rc1 dies after a few packages, it jumps to 0x0 in softirq.
I'm trying to compile the git snapshots now, which is a real challenge..
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-05 18:59 UTC (permalink / raw)
To: Linus Torvalds, linuxppc-dev; +Cc: Linux Kernel Mailing List
In-Reply-To: <20060305140932.GA17132@suse.de>
On Sun, Mar 05, Olaf Hering wrote:
> On Sun, Feb 26, Linus Torvalds wrote:
>
> > Have I missed anything? Holler. And please keep reminding about any
> > regressions since 2.6.15.
>
> I see random memory corruption on an early G3 ibook.
> Testcase is an openSuSE 10.1 installation. 2.6.15 works ok modulo 2 bugs
> to get it booted at all, and the usual udev breakage.
>
> plain 2.6.16-rc5-git7 locks up after a few packages, no ping.
> Our SuSE kernel does not lockup, but ext2 shows access beyond end of
> device after > 200 packages, or the rpmdb gets corrupt, or both. With reiserfs
> it gets past 100 packages, then reiserfs complains about fs corruption.
> plain -rc2 shows the same reiserfs corruption.
> plain -rc1 dies after a few packages, it jumps to 0x0 in softirq.
-git5 works, -git7 showed reiserfs corruption. -git6 died, jumped from
__do_softirq to 0x0, will try once again.
git5->6 has the mutex changes, but also lots of powerpc changes. Lets
see if I can narrow it down further.
The ibook has 160mb, installation is done via modular nfs
(ro,v3,rsize=32768,wsize=32768,hard,nolock,proto=tcp,addr=1.1.1.3)
I havent seen this on a B&W G3 with 256mb, nor on other ppc32 systems.
^ permalink raw reply
* Re: kmod: /sbin/modprobe char-major-4 failed
From: Antonio Di Bacco @ 2006-03-05 19:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060303141742.21257.qmail@mx1.aruba.it>
On Friday 03 March 2006 15:17, antonio.dibacco wrote:
> Why should the kernel try to load this char-major-4? What should I
> configure in the kernel to have this module not loadable but included in
> the kernel?
>
> Bye,
> Antonio.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Simply you missed modprobe!!!!
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Linus Torvalds @ 2006-03-05 20:02 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <20060305185923.GA21519@suse.de>
On Sun, 5 Mar 2006, Olaf Hering wrote:
> On Sun, Mar 05, Olaf Hering wrote:
> >
> > plain 2.6.16-rc5-git7 locks up after a few packages, no ping.
> > Our SuSE kernel does not lockup, but ext2 shows access beyond end of
> > device after > 200 packages, or the rpmdb gets corrupt, or both. With reiserfs
> > it gets past 100 packages, then reiserfs complains about fs corruption.
> > plain -rc2 shows the same reiserfs corruption.
> > plain -rc1 dies after a few packages, it jumps to 0x0 in softirq.
>
> -git5 works, -git7 showed reiserfs corruption. -git6 died, jumped from
> __do_softirq to 0x0, will try once again.
Since there are several git users in the ppc camp, one thing that always
helps is that when you test a -git snapshot, you also say what the "git
ID" was.
I'm assuming that when you say "-git5 works", you mean 2.6.15-git5.
In this case:
2.6.15-git5: 5367f2d67c7d0bf1faae90e6e7b4e2ac3c9b5e0f
2.6.15-git6: 977127174a7dff52d17faeeb4c4949a54221881f
2.6.15-git7: 05f6ece6f37f987e9de643f6f76e8fb5d5b9e014
> git5->6 has the mutex changes, but also lots of powerpc changes. Lets
> see if I can narrow it down further.
If you can try out git, the best way to proceed is
git bisect start
git bisect good 5367f2d67c7d0bf1faae90e6e7b4e2ac3c9b5e0f
git bisect bad 977127174a7dff52d17faeeb4c4949a54221881f
which should help narrow it down pretty efficiently (I'm marking -git6 as
bad, on the logic that the bug being chased is "corruption _or_ jumping to
address 0". It's much harder if you want to chase down just one bug, when
the other bug might stand in your way).
And yes, that range contains not just powerpc updates, but also PCI layer,
mutex changes, crypto and V4L/DVB. Doing just three or four bisection
trials would help narrow it down a lot (now it's 448 commits - doing three
bisctions should narrow it down into less than 60 commits and likely which
subsystem, while doing another bisection or two would get us into a few
tens of commits).
"git bisect" really is very powerful and easy to use.
Linus
^ permalink raw reply
* double fec in denx kernel 2.4
From: Antonio Di Bacco @ 2006-03-05 20:26 UTC (permalink / raw)
To: linuxppc-embedded
I saw that denx kernel has no support for double fec of MPC875. Is this true?
Then I'm going to pick up stuff from Arabella and putting into denx kernel,
is it the best way or not?
Thank you.
^ permalink raw reply
* Re: double fec in denx kernel 2.4
From: Wolfgang Denk @ 2006-03-05 20:31 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200603052126.11407.antonio.dibacco@aruba.it>
In message <200603052126.11407.antonio.dibacco@aruba.it> you wrote:
> I saw that denx kernel has no support for double fec of MPC875. Is this true?
That's true for MPC8xx in our 2.4 kernel tree.
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
We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to
be assimilated.
^ 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