Is the CFG_MONITOR_BASE the location where the processor reads the first instruction after reset ? is that right ?
any clarification would be appreciated. thanks !
i'm working on taishan ppc440gx.
now here's what i noticed. snippet of u-boot.bin opened with a hex editor.
fffbffff : 27051956 552d426f 6f742031 2e322e30 '..VU-Boot 1.2.0 fffc000f : 20284a75 6c203232 20323030 38202d20 (Jul 22 2008 - fffc001f : 31343a31 363a3037 29000000 00000000 14:16:07)....... fffc002f : 00000000 00000000 00000000 00000000 ................ fffc003f : 00000000 00000000 00000000 00000000 ................
and my u-boot.map
.text 0xfffc0000 0x2aa9c cpu/ppc4xx/start.o(.text) .text 0xfffc0000 0x2704 cpu/ppc4xx/start.o 0xfffc01bc _start_of_vectors 0xfffc0004 version_string 0xfffc2424 dcache_enable 0xfffc24dc relocate_code 0xfffc24b4 in32 0xfffc24ac in16r 0xfffc2474 in8 0xfffc24bc in32r 0xfffc2484 out16 0xfffc24a4 in16 0xfffc23ec icache_enable 0xfffc246c wr_tcr 0xfffc2100 transfer_to_handler 0xfffc24cc ppcDcbi 0xfffc0100 _start
couple of question. 1) this line ".text 0xfffc0000 0x2aa9c" from u-boot.map which means .text starts at 0xfffc0000 and with length of 0x2aa9c. right ?
then looking at the hex dump of u-boot.bin looks like there's some data right after first word (U-Boot 1.2.0...) what am i missing ?
2) when ppc440gx reset it has 0xfffffffc in its program counter, the instr at this location is a branch instr. right ? b) this branch should go to TEXT_BASE which is 0xfffc0000 in my case. and that location contains 0x05195655. which looks like a "rlwimix" instr. (rotate left word immediate then mask insert). does this look start of monitor ?
Any insight on how the bootldr starts up would be appreciated too. thanks !
ok, looks like 0x27051956 is uboot magic number (from start.S) why is the CFG_MONITOR_BASE points to the magic number ?
--- On Tue, 7/22/08, Fundu fundu_1999@yahoo.com wrote:
From: Fundu fundu_1999@yahoo.com Subject: [U-Boot-Users] u-boot.bin To: u-boot-users@lists.sourceforge.net Date: Tuesday, July 22, 2008, 3:44 PM i'm working on taishan ppc440gx.
now here's what i noticed. snippet of u-boot.bin opened with a hex editor.
fffbffff : 27051956 552d426f 6f742031 2e322e30 '..VU-Boot 1.2.0 fffc000f : 20284a75 6c203232 20323030 38202d20 (Jul 22 2008 - fffc001f : 31343a31 363a3037 29000000 00000000 14:16:07)....... fffc002f : 00000000 00000000 00000000 00000000 ................ fffc003f : 00000000 00000000 00000000 00000000 ................
and my u-boot.map
.text 0xfffc0000 0x2aa9c cpu/ppc4xx/start.o(.text) .text 0xfffc0000 0x2704 cpu/ppc4xx/start.o 0xfffc01bc _start_of_vectors 0xfffc0004 version_string 0xfffc2424 dcache_enable 0xfffc24dc relocate_code 0xfffc24b4 in32 0xfffc24ac in16r 0xfffc2474 in8 0xfffc24bc in32r 0xfffc2484 out16 0xfffc24a4 in16 0xfffc23ec icache_enable 0xfffc246c wr_tcr 0xfffc2100 transfer_to_handler 0xfffc24cc ppcDcbi 0xfffc0100 _start
couple of question.
- this line ".text 0xfffc0000
0x2aa9c" from u-boot.map which means .text starts at 0xfffc0000 and with length of 0x2aa9c. right ?
then looking at the hex dump of u-boot.bin looks like there's some data right after first word (U-Boot 1.2.0...) what am i missing ?
- when ppc440gx reset it has 0xfffffffc in its program
counter, the instr at this location is a branch instr. right ? b) this branch should go to TEXT_BASE which is 0xfffc0000 in my case. and that location contains 0x05195655. which looks like a "rlwimix" instr. (rotate left word immediate then mask insert). does this look start of monitor ?
Any insight on how the bootldr starts up would be appreciated too. thanks !
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Fundu wrote:
ok, looks like 0x27051956 is uboot magic number (from start.S) why is the CFG_MONITOR_BASE points to the magic number ?
Because that is the definition. From the file README:
- CFG_MONITOR_BASE: Physical start address of boot monitor code (set by make config files to be same as the text base address (TEXT_BASE) used when linking) - same as CFG_FLASH_BASE when booting from flash.
--- On Tue, 7/22/08, Fundu fundu_1999@yahoo.com wrote:
From: Fundu fundu_1999@yahoo.com Subject: [U-Boot-Users] u-boot.bin To: u-boot-users@lists.sourceforge.net Date: Tuesday, July 22, 2008, 3:44 PM i'm working on taishan ppc440gx.
now here's what i noticed. snippet of u-boot.bin opened with a hex editor.
fffbffff : 27051956 552d426f 6f742031 2e322e30
This is the start, it should be (and probably is) at fffc0000. Why does your dump start at fff*bffff* (one byte before where it should)?
'..VU-Boot 1.2.0 fffc000f : 20284a75 6c203232 20323030 38202d20 (Jul 22 2008 - fffc001f : 31343a31 363a3037 29000000 00000000 14:16:07)....... fffc002f : 00000000 00000000 00000000 00000000 ................ fffc003f : 00000000 00000000 00000000 00000000 ................
and my u-boot.map
.text 0xfffc0000 0x2aa9c cpu/ppc4xx/start.o(.text) .text 0xfffc0000 0x2704 cpu/ppc4xx/start.o
Note the start address is fffc0000, not fffbffff.
[snip]
couple of question.
- this line ".text 0xfffc0000
0x2aa9c" from u-boot.map which means .text starts at 0xfffc0000 and with length of 0x2aa9c. right ?
Yes.
then looking at the hex dump of u-boot.bin looks like there's some data right after first word (U-Boot 1.2.0...) what am i missing ?
The first word is the u-boot magic number, followed by the u-boot build information (text).
- when ppc440gx reset it has 0xfffffffc in its program
counter, the instr at this location is a branch instr. right ?
Yes. See cpu/ppc4xx/start.S
b) this branch should go to TEXT_BASE which is 0xfffc0000 in my case.
No, it jumps to the start of some CPU initialization code in the last 4K page (when released from reset, only the last 4K page is mapped). That code maps the rest of memory and jumps to the traditional PPC startup code. 0xfffc0000 isn't involved.
and that location contains 0x05195655. which looks like a "rlwimix" instr. (rotate left word immediate then mask insert). does this look start of monitor ?
No, it looks like operator error.
Any insight on how the bootldr starts up would be appreciated too. thanks !
HTH, gvb
Thanks gvb! that definitely makes sense.
i see the u-boot.elf file is a lot bigger than the u-boot.bin. why is that ?
TIA ! --- On Wed, 7/23/08, Jerry Van Baren gerald.vanbaren@GE.com wrote:
From: Jerry Van Baren gerald.vanbaren@GE.com Subject: Re: [U-Boot-Users] u-boot.bin To: fundu_1999@yahoo.com Cc: u-boot-users@lists.sourceforge.net Date: Wednesday, July 23, 2008, 6:24 AM Fundu wrote:
ok, looks like 0x27051956 is uboot magic number (from
start.S)
why is the CFG_MONITOR_BASE points to the magic number
?
Because that is the definition. From the file README:
- CFG_MONITOR_BASE: Physical start address of boot monitor
code (set by make config files to be same as the text base address (TEXT_BASE) used when linking) - same as CFG_FLASH_BASE when booting from flash.
--- On Tue, 7/22/08, Fundu
fundu_1999@yahoo.com wrote:
From: Fundu fundu_1999@yahoo.com Subject: [U-Boot-Users] u-boot.bin To: u-boot-users@lists.sourceforge.net Date: Tuesday, July 22, 2008, 3:44 PM i'm working on taishan ppc440gx.
now here's what i noticed. snippet of
u-boot.bin opened
with a hex editor.
fffbffff : 27051956 552d426f 6f742031 2e322e30
This is the start, it should be (and probably is) at fffc0000. Why does your dump start at fff*bffff* (one byte before where it should)?
'..VU-Boot 1.2.0 fffc000f : 20284a75 6c203232 20323030 38202d20
(Jul 22
2008 - fffc001f : 31343a31 363a3037 29000000 00000000 14:16:07)....... fffc002f : 00000000 00000000 00000000 00000000 ................ fffc003f : 00000000 00000000 00000000 00000000 ................
and my u-boot.map
.text 0xfffc0000 0x2aa9c cpu/ppc4xx/start.o(.text) .text 0xfffc0000 0x2704
cpu/ppc4xx/start.o
Note the start address is fffc0000, not fffbffff.
[snip]
couple of question.
- this line ".text 0xfffc0000
0x2aa9c" from u-boot.map which means .text starts at 0xfffc0000 and with
length of
0x2aa9c. right ?
Yes.
then looking at the hex dump of u-boot.bin looks
like
there's some data right after first word
(U-Boot
1.2.0...) what am i missing ?
The first word is the u-boot magic number, followed by the u-boot build information (text).
- when ppc440gx reset it has 0xfffffffc in its
program
counter, the instr at this location is a branch
instr.
right ?
Yes. See cpu/ppc4xx/start.S
b) this branch should go to TEXT_BASE which is
0xfffc0000
in my case.
No, it jumps to the start of some CPU initialization code in the last 4K page (when released from reset, only the last 4K page is mapped). That code maps the rest of memory and jumps to the traditional PPC startup code. 0xfffc0000 isn't involved.
and that location contains 0x05195655. which looks
like a
"rlwimix" instr. (rotate left word
immediate then
mask insert). does this look start of monitor ?
No, it looks like operator error.
Any insight on how the bootldr starts up would be appreciated too. thanks !
HTH, gvb
Fundu wrote:
Thanks gvb! that definitely makes sense.
i see the u-boot.elf file is a lot bigger than the u-boot.bin. why is that ?
Hi Fundu,
Please bottom post.
Run "${CROSS_COMPILE}objdump -h u-boot" and you will see that there are lots of non-loaded segments (symbols, etc.) in there.
Run "${CROSS_COMPILE}strip -s u-boot -o=u-boot.strip" and you will see that u-boot.strip is approximately the same size as u-boot.bin. NOTE: I would *NOT* recommend stripping the ELF file unless you have a real need to do so.
gvb
Please bottom post.
will do.
Run "${CROSS_COMPILE}strip -s u-boot -o=u-boot.strip" and you will see that u-boot.strip is approximately the same size as u-boot.bin. NOTE: I would *NOT* recommend stripping the ELF file unless you have a real need to do so.
that make it much clear thx. is the stripped out file of any use ? it won't work with gdb ? so then under what situation would you want to strip.
TIA.
Fundu wrote:
Please bottom post.
will do.
Run "${CROSS_COMPILE}strip -s u-boot -o=u-boot.strip" and you will see that u-boot.strip is approximately the same size as u-boot.bin. NOTE: I would *NOT* recommend stripping the ELF file unless you have a real need to do so.
that make it much clear thx. is the stripped out file of any use ? it won't work with gdb ? so then under what situation would you want to strip.
TIA.
The two reasons I can think of for stripping elf files... 1) Make it smaller if you have to transport it on/over a size sensitive medium (floppy, modem). Maybe also to cram more on a limited size embedded file system.
2) Most proprietary packages strip their packages to try to prevent their "valuable intellectual property" from leaking out. (This has limited real value, but PHBs think it is a very valuable thing to do.)
To reiterate, there is almost no reason to strip elf files.
Best regards, gvb
In message 420794.71173.qm@web63409.mail.re1.yahoo.com you wrote:
Is the CFG_MONITOR_BASE the location where the processor reads the first instruction after reset ? is that right ?
No. The processor starts the execution at the reset entry point. This may be 0x100 or 0xFFF00100 on some PowerPC processors or 0xFFFFFFFC on some others, or 0x00000000 on ARM, or ...
CFG_MONITOR_BASE is the start address of the U-Boot image in flash.
Best regards,
Wolfgang Denk
participants (3)
-
Fundu -
Jerry Van Baren -
Wolfgang Denk