[U-Boot-Users] Flawed ATAG passing

[U-Boot-Users] Flawed ATAG passing

[Christian Kapeller]

Hi.

While trying to get Linux (2.4.19-rmk7-pxa2 and 2.6.7-mm7) start with
a ramdisk on a xm250 board, i discovered, that uboot 1.1.1 seems to have a problem passing the ATAGs to the kernel.


Here is some debug output with linux 2.6.7-mm7 

====

u-Boot 1.1.1 (Jul 28 2004 - 17:11:18)

U-Boot code: A3F80000 -> A3F998AC  BSS: -> A3F9DBD8
RAM Configuration:
Bank #0: a0000000 64 MB
Bank #1: a4000000  0 kB
Bank #2: a8000000  0 kB
Bank #3: ac000000  0 kB
Flash: 32 MB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  3 \b\b\b 2 \b\b\b 1 \b\b\b 0 
Using MAC Address 00:40:42:01:65:AA
BOOTP broadcast 1
got BOOTP packet (src=67, dst=68, len=300 want_len=300)
Filtering pkt = 0
Bootfile: uImage
[BOOTP] Checking extension (300 bytes)...
[BOOTP] Processing extension 1... (4 bytes)
[BOOTP] Processing extension 3... (4 bytes)
[BOOTP] Processing extension 6... (4 bytes)
[BOOTP] Processing extension 15... (16 bytes)
[BOOTP] Processing extension 28... (4 bytes)
[BOOTP] Received fields: 
NetOurSubnetMask : 255.255.255.0
NetOurGatewayIP	: 192.168.0.1
Got good BOOTP
TFTP from server 192.168.0.1; our IP address is 192.168.0.3
Filename 'uImage'.
Load address: 0xa3000000
Loading: *\bT #################################################################
	 #################################################################
	 ###########################
done
Bytes transferred = 799312 (c3250 hex)
## Booting image at a3000000 ...
   Image Name:   Linux-Image
   Created:      2004-07-28  18:10:20 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    799248 Bytes = 780.5 kB
   Load Address: a0200000
   Entry Point:  a0200000
   Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 00200000 ...
   Image Name:   initrd
   Created:      2004-07-27  16:09:34 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    2517544 Bytes =  2.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Initrd at 00200040. Size 2517544## Transferring control to Linux (at address a0200000) ...
## setup_start_tag
## setup_memory_tags start a0000000 size:04000000
 ## setup_commandling_tag size:0000001c line: root=/dev/ram0 init=/linuxrc
## setup_initrd_args start:00200040, end:00466a68
## setup_end_tag

Starting kernel ...

Uncompressing Linux......................................................... done, booting the kernel.
Linux version 2.6.7-mm7 (chrkap at allesodernix) (gcc version 3.3.3) #21 Wed Jul 28 18:10:04 UTC 2004
CPU: XScale-PXA255 [69052d06] revision 6 (ARMv5TE)
CPU: D undefined 5 cache
CPU: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Machine: Intel DBPXA250 Development Platform (aka Lubbock)
parse_tags number of tags: 5
parsing tag: 0x54410001
parse_tag: tag 0x54410001 
parse_tag_core
parsing tag: 0x54410002
parse_tag: tag 0x54410002 
parse_tag_mem32 start 0xa0000000 size 0x01000000
Memory policy: ECC disabled, Data cache writeback
Memory clock: 99.53MHz (*27)
Run Mode clock: 398.13MHz (*4)
Turbo Mode clock: 398.13MHz (*1.0, inactive)
On node 0 totalpages: 4096
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 0 pages, LIFO batch:1
  HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: root=/dev/ram console=ttyS0,115200
PID hash table entries: 128 (order 7: 1024 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 16MB = 16MB total
Memory: 14376KB available (1366K code, 346K data, 76K init)
Calibrating delay loop... 397.31 BogoMIPS
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
NetWinder Floating Point Emulator V0.97 (double precision)
ttyS0 at MMIO 0x40100000 (irq = 15) is a FFUART
ttyS1 at MMIO 0x40200000 (irq = 14) is a BTUART
ttyS2 at MMIO 0x40700000 (irq = 13) is a STUART
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Using anticipatory io scheduler
physmap flash device: 4000000 at 0
cfi_cmdset_0001: Erase suspend on write enabled
Using buffer write method
cmdlinepart partition parsing not available
RedBoot partition parsing not available
pxa2xx_udc: version 14-Dec-2003
usb0: Ethernet Gadget, version: St Patrick's Day 2004
usb0: using pxa2xx_udc, OUT ep2out-bulk IN ep1in-bulk
usb0: MAC 1a:60:19:07:1a:f0
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
NET: Registered protocol family 1
Kernel panic: VFS: Unable to mount root fs on unknown-block(1,0)
====

It seems that the kernel recieves all tags u-boot provided, but not 
all are parsed. Which seems strange, since none of the parse_tag_* 
functions in arch/arm/kernel/setup.c which are called by parse_tags(),
can return something other than 0 which means that parse_tags() should
read the next tag wich it doesn't. 

Has anybody experienced something simmilar, is this a known issue?

[U-Boot-Users] Flawed ATAG passing

[Wolfgang Denk]

Dear Christian,

in message <20040728164601.GA19459@stud4.tuwien.ac.at> you wrote:
> 
> While trying to get Linux (2.4.19-rmk7-pxa2 and 2.6.7-mm7) start with
> a ramdisk on a xm250 board, i discovered, that uboot 1.1.1 seems to have a
> problem passing the ATAGs to the kernel.
...
> It seems that the kernel recieves all tags u-boot provided, but not 
> all are parsed. Which seems strange, since none of the parse_tag_* 

Why do you think that U-Boot has problems when the  Linux  kernel  is
actually receiving all ATAGs?

> functions in arch/arm/kernel/setup.c which are called by parse_tags(),
> can return something other than 0 which means that parse_tags() should
> read the next tag wich it doesn't. 
> 
> Has anybody experienced something simmilar, is this a known issue?

It works fine (at least for  2.4.x  kernels)  on  several  boards;  I
didn't test 2.6.x so far.

How about adding a bit more debugging code to your Linux kerenl?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Hi there! This is just a note from me, to you, to tell you, the  per-
son  reading this note, that I can't think up any more famous quotes,
jokes, nor bizarre stories, so you may as well go home.

[U-Boot-Users] Flawed ATAG passing

[Ralph Siemsen]

Christian Kapeller wrote:

> Machine: Intel DBPXA250 Development Platform (aka Lubbock)
> parse_tags number of tags: 5
> parsing tag: 0x54410001
> parse_tag: tag 0x54410001 
> parse_tag_core
> parsing tag: 0x54410002
> parse_tag: tag 0x54410002 
> parse_tag_mem32 start 0xa0000000 size 0x01000000

So your bootloader is passing fine the tags to kernel.

> Kernel command line: root=/dev/ram console=ttyS0,115200

Here you are telling it to boot from ramdisk (maj 1, minor 0)

> Kernel panic: VFS: Unable to mount root fs on unknown-block(1,0)

Your kernel fails to mount the ramdisk, since you have RAMDISK driver 
etc, then the next most likely reason is you are missing the filesystem 
support in your kernel.  For exampel if your ramdisk in in ext2 format 
then make sure your kernel has ext2 support compiled in (not as a module).

-R

[U-Boot-Users] Flawed ATAG passing

[Wolfgang Denk]

In message <4107F1C1.8090308@rossvideo.com> you wrote:
> 
> > Kernel command line: root=/dev/ram console=ttyS0,115200
> 
> Here you are telling it to boot from ramdisk (maj 1, minor 0)
> 
> > Kernel panic: VFS: Unable to mount root fs on unknown-block(1,0)
> 
> Your kernel fails to mount the ramdisk, since you have RAMDISK driver 
> etc, then the next most likely reason is you are missing the filesystem 
> support in your kernel.  For exampel if your ramdisk in in ext2 format 
> then make sure your kernel has ext2 support compiled in (not as a module).

...or his kernel does not know how to deal with a ramdisk in flash
memory (this has been discussed many times before; the next time it
comes up I'll add it as a FAQ -- for now please see
http://sourceforge.net/mailarchive/message.php?msg_id=6839224)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
All I ask is a chance to prove that money can't make me happy.