[U-Boot] Help Request - Command parsing, find_cmd (), possible linker script problem

[U-Boot] Help Request - Command parsing, find_cmd (), possible linker script problem

[Graeme Russ]

Hi All,

So far I have my sc520 board booting into main_loop (), DRAM configured
and serial ports working. Now I seem to be stuck on getting commands
to execute (even help). Using printf() I have traced my problem into
find_cmd (). I added the following into find_cmd() just before the for
loop:

printf ("Searching for Command '%s'\n", cmd);
printf ("Command Table Start : %08lx\n", (ulong)&__u_boot_cmd_start);
printf ("Command Table End   : %08lx\n", (ulong)&__u_boot_cmd_end);
printf ("sizeof(int)         : %x\n", sizeof(int));
printf ("sizeof(cmd_tbl_t)   : %x\n", sizeof(cmd_tbl_t));

and

printf ("Checking : %08lx\n", (ulong)cmdtp);

just inside the for loop

The output is (there are a few other printf()'s leadinf up to
find_cmd () as well):

boot > help

[RUN_COMMAND] cmd[00400ccc]="help"
[PROCESS_SEPARATORS] help
token: "help"

Processing Macros...
[PROCESS_MACROS] INPUT len 4: "help"
[PROCESS_MACROS] OUTPUT len 4: "help"
Extracting Arguments...
parse_line: "help"

parse_line: nargs=1
Looking up Command...
Searching for Command 'help'
Command Table Start : 0000053e
Command Table End   : 00000870
sizeof(int)         : 4
sizeof(cmd_tbl_t)   : 18
Checking : 0000053e
Checking : 00000556
Checking : 0000056e
.
.
.
Checking : 00000856
Checking : 0000086e
Checking : 00000886
Checking : 0000089e
Checking : 000008b6

There are a few weird things going on...

a) sizeof(cmd_tbl_t) is 18, but the loop is incrementing by 24 (I would
have thought a 4 byte alignment would push it to 20 maybe)

b) The loop never completes since cmdtp never actually equals
&__u_boot_cmd_end

c) The bootrom flash is mapped to 0x38000000. The flash is 512k with
U-Boot image being 256k puts U-Boot at 0x38040000. I have adjusted
TEXT_BASE = 0x38040000 in config.mk and adjusted u-boot.lds (see
full u-boot.lds below) (for those that don't know the AMD sc520, the
boot flash memory region can be 'mapped' to wherever you want it,
and I have confirmed the mapping be dumping the address of the
last_stage_init() function which resides at 0x38046d57 - right were
I expect it). I would, therefore, expect the command table to live
somewhere in 0x38040000 - 0x3807ffff

Can anyone point me an a rough direction to look? Any help at all
would be greatly appreciated

Regards,

Graeme

u-boot.lds:

OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)

SECTIONS
{
	. = 0x38040000;		/* Where bootcode in the flash is mapped */
	.text  : { *(.text); }

	. = ALIGN(4);
	.rodata : { *(.rodata) *(.rodata.str1.1) *(.rodata.str1.32) }

	. = 0x400000;	                    /* Ram data segment to use */
	_i386boot_romdata_dest = ABSOLUTE(.);
	.data : AT ( LOADADDR(.rodata) + SIZEOF(.rodata) ) { *(.data) }
	_i386boot_romdata_start = LOADADDR(.data);

	. = ALIGN(4);
	.got : AT ( LOADADDR(.data) + SIZEOF(.data) ) { *(.got) }
	_i386boot_romdata_size = SIZEOF(.data) + SIZEOF(.got);


	. = ALIGN(4);
	_i386boot_bss_start = ABSOLUTE(.);
	.bss (NOLOAD) : { *(.bss) }
	_i386boot_bss_size = SIZEOF(.bss);


	/* 16bit realmode trampoline code */
	.realmode 0x7c0 : AT ( LOADADDR(.got) + SIZEOF(.got) ) { *(.realmode) }

	_i386boot_realmode = LOADADDR(.realmode);
	_i386boot_realmode_size = SIZEOF(.realmode);

	/* 16bit BIOS emulation code (just enough to boot Linux) */
	.bios 0 : AT ( LOADADDR(.realmode) + SIZEOF(.realmode) ) { *(.bios) }

	_i386boot_bios = LOADADDR(.bios);
	_i386boot_bios_size = SIZEOF(.bios);


  . = .;
  __u_boot_cmd_start = .;
  .u_boot_cmd : { *(.u_boot_cmd) }
  __u_boot_cmd_end = .;


	/* The load addresses below assumes that the flash
	 * will be mapped so that 0x387f0000 == 0xffff0000
	 * at reset time
	 *
	 * The fe00 and ff00 offsets of the start32 and start16
	 * segments are arbitrary, the just have to be mapped
	 * at reset and the code have to fit.
	 * The fff0 offset of reset is important, however.
	 */

	. = 0xfffffe00;
	.start32 : AT (0x3807fe00) { *(.start32); }

	. = 0xf800;
	.start16 : AT (0x3807f800) { *(.start16); }

	. = 0xfff0;
	.reset : AT (0x3807fff0) { *(.reset); }
	_i386boot_end = (LOADADDR(.reset) + SIZEOF(.reset) );
}

[U-Boot] Help Request - Command parsing, find_cmd (), possible linker script problem

[Jerry Van Baren]

Graeme Russ wrote:
> Hi All,
> 
> So far I have my sc520 board booting into main_loop (), DRAM configured
> and serial ports working. Now I seem to be stuck on getting commands
> to execute (even help). Using printf() I have traced my problem into
> find_cmd (). I added the following into find_cmd() just before the for
> loop:
>
> printf ("Searching for Command '%s'\n", cmd);
> printf ("Command Table Start : %08lx\n", (ulong)&__u_boot_cmd_start);
> printf ("Command Table End   : %08lx\n", (ulong)&__u_boot_cmd_end);
> printf ("sizeof(int)         : %x\n", sizeof(int));
> printf ("sizeof(cmd_tbl_t)   : %x\n", sizeof(cmd_tbl_t));

Aaargh, you printed %x, not 0x%x.  That really threw me on the printout 
of sizeof(cmd_tbl_t).

[snip]

> The output is (there are a few other printf()'s leadinf up to
> find_cmd () as well):
> 
> boot > help
> 
> [RUN_COMMAND] cmd[00400ccc]="help"
> [PROCESS_SEPARATORS] help
> token: "help"
> 
> Processing Macros...
> [PROCESS_MACROS] INPUT len 4: "help"
> [PROCESS_MACROS] OUTPUT len 4: "help"
> Extracting Arguments...
> parse_line: "help"
> 
> parse_line: nargs=1
> Looking up Command...
> Searching for Command 'help'
> Command Table Start : 0000053e
> Command Table End   : 00000870

0x870 - 0x53e = 0x332 = 818.  818 / 24 = 34 with a remainder of 2.  I 
believe this is your problem.  I bet you need to word-align the start of 
your table... the end label is getting word aligned which is padding out 
your end so your loop doesn't end.

I suspect this is the problem with not recognizing the commands as well? 
  Perhaps the processor/compiler doesn't like having the table poorly 
aligned so one of the pointers is getting messed up?

> sizeof(int)         : 4
> sizeof(cmd_tbl_t)   : 18

0x18 == 24

> Checking : 0000053e
> Checking : 00000556

0x56 - 0x3e == 0x18 == 24 (check)

> Checking : 0000056e
> .
> .
> .
> Checking : 00000856
> Checking : 0000086e

0x86e is the proper table end given 34 commands and 24 bytes per table 
entry.

> Checking : 00000886
> Checking : 0000089e
> Checking : 000008b6
> 
> There are a few weird things going on...
> 
> a) sizeof(cmd_tbl_t) is 18, but the loop is incrementing by 24 (I would
> have thought a 4 byte alignment would push it to 20 maybe)

Nope, just radix issues (see above).

> 
> b) The loop never completes since cmdtp never actually equals
> &__u_boot_cmd_end

Alignment padding problems are preventing it (see above).

[snip]

> Can anyone point me an a rough direction to look? Any help at all
> would be greatly appreciated

I think you need a 4 byte alignment before the command table in the 
linker control file (below)

> Regards,
> 
> Graeme
> 
> u-boot.lds:

[snip]

> 	/* 16bit BIOS emulation code (just enough to boot Linux) */
> 	.bios 0 : AT ( LOADADDR(.realmode) + SIZEOF(.realmode) ) { *(.bios) }
> 
> 	_i386boot_bios = LOADADDR(.bios);
> 	_i386boot_bios_size = SIZEOF(.bios);
> 
> 
>   . = .;


I think you need to add
. = ALIGN(2);
here

(ALIGN(4)? IIRC, the ALIGN is 2^n so ALIGN(2) is 4-byte alignment)

>   __u_boot_cmd_start = .;
>   .u_boot_cmd : { *(.u_boot_cmd) }
>   __u_boot_cmd_end = .;

[snip]

HTH,
gvb

[U-Boot] Help Request - Command parsing, find_cmd (), possible linker script problem

[Graeme Russ]

Thanks for such a quick response Jerry. Your suggestion fixed one
problem, but it still doesn't work

Jerry Van Baren wrote:
> Graeme Russ wrote:
>> Hi All,
>>

> 
> Aaargh, you printed %x, not 0x%x.  That really threw me on the printout
> of sizeof(cmd_tbl_t).
> 
> 
> 0x18 == 24

How embarrassing - I've changed it to %i

>>
>> b) The loop never completes since cmdtp never actually equals
>> &__u_boot_cmd_end
> 
> Alignment padding problems are preventing it (see above).
> 

Fixed with . = ALIGN(4) (ALIGN(2) made no difference)

I've added a few more debugs in the loop (and my startup code) with
the following results:


U-Boot 2008.10-rc2-00002-gd6aaec1-dirty (Sep 20 2008 - 14:37:52)



U-Boot code: 38040000 -> 3805158F  data: 00400000 -> 00400A57

        BSS: 00400A58 -> 00404463 stack: 00404464 -> 0040C463

DRAM Configuration:

Bank #0: 00000000 64 MB

Bank #1: 04000000 64 MB

Bank #2: 08000000  0 kB

Bank #3: 08000000  0 kB

*** Warning - bad CRC, using default environment



In:    serial

Out:   serial

Err:   serial

Serck Controls eNET


autoscript => do_autoscript()        @ 0x38040886

bdinfo     => do_bdinfo()            @ 0x380408e7


<snip>

imls       => do_imls()              @ <undefined>

<snip>

help       => do_help()              @ 0x38043713

?          => do_help()              @ 0x38043713

boot > help


[RUN_COMMAND] cmd[00400ccc]="help"

[PROCESS_SEPARATORS] help

token: "help"

Processing Macros...

[PROCESS_MACROS] INPUT len 4: "help"

[PROCESS_MACROS] OUTPUT len 4: "help"

Extracting Arguments...

parse_line: "help"

parse_line: nargs=1

Looking up Command...

Searching for Command 'help'

Command Table Start : 0x00000540

Command Table End   : 0x00000870

sizeof(int)         : 4

sizeof(cmd_tbl_t)   : 24

cmdtp             = 0x00000540

cmdtp->name       = 0xffffffff

cmdtp->maxargs    = -262145

cmdtp->repeatable = -33562625

cmdtp->cmd        = 0xf7ffffff

cmdtp->usage      = 0xffff5fff

cmdtp->help       = 0x7bffff7f


<snip>


cmdtp             = 0x00000858

cmdtp->name       = 0xfeffffff

cmdtp->maxargs    = -513

cmdtp->repeatable = -1

cmdtp->cmd        = 0xffffffff

cmdtp->usage      = 0xffffffff

cmdtp->help       = 0xffffffff

Searching complete

Unknown command 'help' - try 'help'

boot > 


The address dumps of each command are simply achieved by:

	printf("autoscript => do_autoscript()        @ 0x%08lx\n", (ulong)do_autoscript);
<snip>
/*	printf("imls       => do_imls()              @ 0x%08lx\n", (ulong)do_imls); */
	printf("imls       => do_imls()              @ <undefined>\n");

For some reason do_imls always results in an undefined reference
error reported by the linker, even though it ends up in the command
list at 0x600 as shown in u-boot.map

                0x0000000000000540                . = ALIGN (0x4)
                0x0000000000000540                __u_boot_cmd_start = .

.u_boot_cmd     0x0000000000000540      0x330 load address 0x000000003805268e
 *(.u_boot_cmd)
 .u_boot_cmd    0x0000000000000540       0x18 common/libcommon.a(cmd_autoscript.o)
                0x0000000000000540                __u_boot_cmd_autoscr
 .u_boot_cmd    0x0000000000000558       0x18 common/libcommon.a(cmd_bdinfo.o)
                0x0000000000000558                __u_boot_cmd_bdinfo
 .u_boot_cmd    0x0000000000000570       0x30 common/libcommon.a(cmd_boot.o)
                0x0000000000000588                __u_boot_cmd_reset
                0x0000000000000570                __u_boot_cmd_go
 .u_boot_cmd    0x00000000000005a0       0x78 common/libcommon.a(cmd_bootm.o)
                0x00000000000005a0                __u_boot_cmd_bootm
                0x00000000000005e8                __u_boot_cmd_iminfo
                0x00000000000005d0                __u_boot_cmd_bootd
                0x00000000000005b8                __u_boot_cmd_boot
                0x0000000000000600                __u_boot_cmd_imls
 .u_boot_cmd    0x0000000000000618       0x18 common/libcommon.a(cmd_console.o)


So now it is terminating the loop correctly, but it looks like the
command table contains nothing garbage

I thought the load address 0x000000003805268e might be a hint, so I
did a dump of u-boot.bin:

0x3805268e - 0x3804000 = 0x1268E = 75406

graeme at devel:~/Source/U-Boot/v2008.10-rc2$ xxd -s 75406 -l 160 u-boot.bin 
001268e: 90e0 0438 0200 0000 0000 0000 8608 0438  ...8...........8
001269e: 98e0 0438 bae0 0438 a4e1 0438 0100 0000  ...8...8...8....
00126ae: 0100 0000 e708 0438 abe1 0438 0000 0000  .......8...8....
00126be: 2be2 0438 1000 0000 0100 0000 c509 0438  +..8...........8
00126ce: 2ee2 0438 5de2 0438 b8e2 0438 0100 0000  ...8]..8...8....
00126de: 0000 0000 63c9 0438 bee2 0438 0000 0000  ....c..8...8....
00126ee: 7ee6 0438 1000 0000 0100 0000 5a0c 0438  ~..8........Z..8
00126fe: 84e6 0438 b2e6 0438 c301 0538 0100 0000  ...8...8...8....
001270e: 0100 0000 3a0c 0438 5ae7 0438 0000 0000  ....:..8Z..8....
001271e: 87e7 0438 0100 0000 0100 0000 3a0c 0438  ...8........:..8

Doesn't seem to match (maybe I'm barking up the wrong tree)

Any ideas?

Regards,

Graeme

[U-Boot] Help Request - Command parsing, find_cmd (), possible linker script problem

[Graeme Russ]

OK, I've had a closer look at u-boot.map and u-boot.bin...

The command table starts at offset 0x001268e into u-boot.bin and each
entry is 24 bytes. The first entry is:

001268e: 90 e0 04 38 02 00 00 00 00 00 00 00 86 08 04 38 98 e0 04 38 ba e0 04 38

Which decodes down to:

90 e0 04 38 => cmd_tbl_t->name
ASCII string at offset 0xe090 in u-boot.bin
"autoscr"

02 00 00 00 => cmd_tbl_t->maxargs
2

00 00 00 00 = cmd_tbl_t->repeatable
0

86 08 04 38 => cmd_tbl_t->cmd
u-boot.map => do_autoscript ()

98 e0 04 38 => cmd_tbl_t->usage
ASCII string at offset 0xe098 in u-boot.bin
"autoscr - run script from memory"

ba e0 04 38 => cmd_tbl_t->help
ASCII string at offset 0xe0ba in u-boot.bin
"[addr] - run script starting at addr - A valid autoscr header must be present"

So the table and all the references in it are valid and u-boot.map
suggest it should be located at 0x540, but what is this relative to,
and how does it end up there? I feel I'm getting closer, but missing
one tiny, but critical, bit of info.

Sorry if this all seems obvious, but this is the first time I've
dealt with data at such a low level

Regards,

Graeme