All of lore.kernel.org
 help / color / mirror / Atom feed
From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Help Request - Command parsing, find_cmd (), possible linker script problem
Date: Sat, 20 Sep 2008 16:56:30 +1000	[thread overview]
Message-ID: <48D49E9E.6000405@gmail.com> (raw)

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) );
}

             reply	other threads:[~2008-09-20  6:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-20  6:56 Graeme Russ [this message]
2008-09-20 13:57 ` [U-Boot] Help Request - Command parsing, find_cmd (), possible linker script problem Jerry Van Baren
2008-09-20 23:27   ` Graeme Russ
2008-09-21  2:22     ` Graeme Russ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48D49E9E.6000405@gmail.com \
    --to=graeme.russ@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.