Re: [U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)
"Patrick .." oc3an@gmx.net schreibt:
On another note, is there any reason you chose a master clock divisor of 4 instead of 3 for the CSB637?
Hi,
like I already said: "I got the clock values from linux 2.6.12 board-csb637.c" I didn't choose them myself.
I have looked over the data sheets for all relevant devices (SDRAM, StrataFlash) and they definitely support at least 60Mhz (what divider 3 gives).
Feel free to change it, then (but please make sure to update arch/arm/mach-at91rm9200/board-csb637.c accordingly, otherwise at least the serial interfaces will not work).
Cheers Anders
P.S.: PLEASE keep the list CC'ed.
"Patrick .." oc3an@gmx.net schreibt:
On another note, is there any reason you chose a master clock divisor of
4
instead of 3 for the CSB637?
Hi,
like I already said: "I got the clock values from linux 2.6.12 board-csb637.c" I didn't choose them myself.
I have looked over the data sheets for all relevant devices (SDRAM, StrataFlash) and they definitely support at least 60Mhz (what divider 3 gives).
Feel free to change it, then (but please make sure to update arch/arm/mach-at91rm9200/board-csb637.c accordingly, otherwise at least the serial interfaces will not work).
Cheers Anders
P.S.: PLEASE keep the list CC'ed.
No proglems, list is CC'd!! :)
Linux still appears to boot fine right up until it says.
RAMDISK: Couldn't find valid RAM disk image starting at 0. Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
which is expected.
You are correct, the /arch/arm/mach-at91rm9200/board-csb637.c file had to be edited in order to work with the new master clock. I believe there is a way of detecting clock speeds which i will look up later. This would be better than them being hard-coded.
This is probably a bit off topic for this list, but does anyone know a way of making ram disk images that doesn't require root access (which i don't have on the box i am working on)
I am aware of the following method:
dd if=/dev/zero of=rootfs.img bs=1k count=400 mkfs.ext2 -c rootfs.img mount -o loop rootfs.img /mntpoint cp -av rootfs/* /mntpoint umount /mntpoint gzip -v9 -c rootfs.img >rootfs.gz
However mount requires root access :(
-Patrick
This is probably a bit off topic for this list, but does anyone know a
way
of making ram disk images that doesn't require root access (which i
don't
have on the box i am working on)
genext2fs ?
-- Steven
Thanks, i'll check it out of cvs and have a look.
Aside from this I made an empty ram disk simply to see if the kernel would mount it.
My configuration is this: bootargs=mem=32M console=ttyS0,38400 Flash Address 10100000 contains linux kernel image Flash Address 10200000 contains compressed ram disk
Unfortunately i ran into this error after executing bootm 10100000 10200000:
Linux version 2.6.13-rc2-csb (patrick@gt-server) (gcc version 3.4.4) #1 Wed Aug 24 20:29:20 EST 2005 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) Machine: Cogent CSB637 initrd (0x10200040 - 0x1020059c) extends beyond physical memory - disabling initrd
which looks like the ram disk isn't being decompressed into ram from flash.
Is there a simple solution to this problem? does the ram disk need to be maually decompressed first?
Thanks,
-Patrick
"Patrick .." oc3an@gmx.net schreibt:
My configuration is this: bootargs=mem=32M console=ttyS0,38400
You don't have to use the MEM=32M option - U-Boot will pass the actual memory configuration to the kernel anyway.
Linux version 2.6.13-rc2-csb (patrick@gt-server) (gcc version 3.4.4) #1 Wed initrd (0x10200040 - 0x1020059c) extends beyond physical memory - disabling initrd
Is there a simple solution to this problem? does the ram disk need to be maually decompressed first?
Unfortunately yes - the 2.6 kernel is unable to handle an initrd in flash (this is a FAQ, by the way).
Cheers Anders
Anders,
Is there a simple solution to this problem? does the ram disk need to be maually decompressed first?
Unfortunately yes - the 2.6 kernel is unable to handle an initrd in flash (this is a FAQ, by the way).
So where is the FGA(*) then?
-- Steven
(*) FGA: Frequently Given Answer
Is there a simple solution to this problem? does the ram disk need to be maually decompressed first?
Unfortunately yes - the 2.6 kernel is unable to handle an initrd in flash (this is a FAQ, by the way).
So where is the FGA(*) then?
(*) FGA: Frequently Given Answer
A question on the tips of my fingers but Steve beat me to it..
-Patrick
Is there a simple solution to this problem? does the ram disk need to
be
maually decompressed first?
Unfortunately yes - the 2.6 kernel is unable to handle an initrd in flash (this is a FAQ, by the way).
So where is the FGA(*) then?
(*) FGA: Frequently Given Answer
I have done some more searching and it appears a patch was posted to CVS for the 2.6 kernel to support initrd's stored in flash.
I have searched CVS etc. and am unable to find it :(
-Patrick
In message 15305.1124895017@www46.gmx.net you wrote:
I have done some more searching and it appears a patch was posted to CVS for the 2.6 kernel to support initrd's stored in flash.
The patch was against a 2.4 kernel.
And note that all this discussion is off topic on this list.
Best regards,
Wolfgang Denk
I have done some more searching and it appears a patch was posted to CVS
for
the 2.6 kernel to support initrd's stored in flash.
The patch was against a 2.4 kernel.
And note that all this discussion is off topic on this list.
I apologise for the OT discussion.
Will continue searching other sources for a solution to correctly booting a 2.6 kernel with U-Boot.
-Patrick
participants (4)
-
Anders Larsen -
Patrick .. -
Steven Scholz -
Wolfgang Denk