[U-Boot] How does u-boot know where to put its start code?
Hi folks,
I'm trying to understand a bit more about how u-boot creates the image, such that the CPU reset vector is pointing to the right piece of code when it is reset.
i.e. my DNS323 (Orion5x) has a reset vector of 0xffff0000. But for the life of me, I can't find anywhere that actually references that value to place the start code at that point.
I'm basically trying to make sure that my CONFIG_SYS_TEXT_BASE is correct (the address in the flash to which I write the whole u-boot.bin file, right?.
Thanks
Rogan
Hi,
On Wed, Apr 20, 2011 at 02:43:23, Rogan Dawes wrote:
Hi folks,
I'm trying to understand a bit more about how u-boot creates the image, such that the CPU reset vector is pointing to the right piece of code when it is reset.
i.e. my DNS323 (Orion5x) has a reset vector of 0xffff0000. But for the life of me, I can't find anywhere that actually references that value to place the start code at that point.
Placing the final boot image is left to user who flashes/burns it board. But it should be same as _TEXT_BASE (this is being removed now. Orion5x is arm based). Also look at <u-boot-src>\arch\arm\cpu\arm926ejs\start.S & <u-boot-src>\arch\arm\cpu\arm926ejs\u-boot.lds for more info on how linker is instructed to place the starting code at predefined address.
I'm basically trying to make sure that my CONFIG_SYS_TEXT_BASE is correct (the address in the flash to which I write the whole u-boot.bin file, right?.
This is passed to linker as the entry point.
Thanks
Rogan
Regards, Gururaja
Le 20/04/2011 04:23, Hebbar, Gururaja a écrit :
Hi,
On Wed, Apr 20, 2011 at 02:43:23, Rogan Dawes wrote:
Hi folks,
I'm trying to understand a bit more about how u-boot creates the image, such that the CPU reset vector is pointing to the right piece of code when it is reset.
i.e. my DNS323 (Orion5x) has a reset vector of 0xffff0000. But for the life of me, I can't find anywhere that actually references that value to place the start code at that point.
Placing the final boot image is left to user who flashes/burns it board. But it should be same as _TEXT_BASE (this is being removed now. Orion5x is arm based). Also look at<u-boot-src>\arch\arm\cpu\arm926ejs\start.S& <u-boot-src>\arch\arm\cpu\arm926ejs\u-boot.lds for more info on how linker is instructed to place the starting code at predefined address.
I'm basically trying to make sure that my CONFIG_SYS_TEXT_BASE is correct (the address in the flash to which I write the whole u-boot.bin file, right?.
This is passed to linker as the entry point.
There is another point re: orion5x based boards: often, their designers preferred generating a linear image for U-Boot, but the fact that the vector address is at FFFF0000 makes it impossible to directly the image there because it is always greater than 64K. So the designers put some "pseudo-rom boot code" at FFFF0000 that will finally jump to an address lower in FLASH; for ED Mini V2 it is FFF90000, and that's where the U-Boot image is supposed to be flashed.
Rogan, I bet in the DNS323 case, the same applies modulo your Flash size. Try tracing through the FFFF0000 code, it should not last more than a few tens of instructions before it jumps to some absolute address.
Thanks
Rogan
Amicalement,
On 2011/04/20 7:42 AM, Albert ARIBAUD wrote:
Le 20/04/2011 04:23, Hebbar, Gururaja a écrit :
Hi,
On Wed, Apr 20, 2011 at 02:43:23, Rogan Dawes wrote:
Hi folks,
I'm trying to understand a bit more about how u-boot creates the image, such that the CPU reset vector is pointing to the right piece of code when it is reset.
i.e. my DNS323 (Orion5x) has a reset vector of 0xffff0000. But for the life of me, I can't find anywhere that actually references that value to place the start code at that point.
Placing the final boot image is left to user who flashes/burns it board. But it should be same as _TEXT_BASE (this is being removed now. Orion5x is arm based). Also look at<u-boot-src>\arch\arm\cpu\arm926ejs\start.S& <u-boot-src>\arch\arm\cpu\arm926ejs\u-boot.lds for more info on how linker is instructed to place the starting code at predefined address.
I'm basically trying to make sure that my CONFIG_SYS_TEXT_BASE is correct (the address in the flash to which I write the whole u-boot.bin file, right?.
This is passed to linker as the entry point.
There is another point re: orion5x based boards: often, their designers preferred generating a linear image for U-Boot, but the fact that the vector address is at FFFF0000 makes it impossible to directly the image there because it is always greater than 64K. So the designers put some "pseudo-rom boot code" at FFFF0000 that will finally jump to an address lower in FLASH; for ED Mini V2 it is FFF90000, and that's where the U-Boot image is supposed to be flashed.
So, is that the address that you would use for CONFIG_SYS_TEXT_BASE ?
Rogan, I bet in the DNS323 case, the same applies modulo your Flash size. Try tracing through the FFFF0000 code, it should not last more than a few tens of instructions before it jumps to some absolute address.
Do you think it would be possible to figure it out from the original vendor u-boot?
Thanks
Rogan
Hi Rogan,
Le 20/04/2011 09:46, Rogan Dawes a écrit :
On 2011/04/20 7:42 AM, Albert ARIBAUD wrote:
Le 20/04/2011 04:23, Hebbar, Gururaja a écrit :
Hi,
On Wed, Apr 20, 2011 at 02:43:23, Rogan Dawes wrote:
Hi folks,
I'm trying to understand a bit more about how u-boot creates the image, such that the CPU reset vector is pointing to the right piece of code when it is reset.
i.e. my DNS323 (Orion5x) has a reset vector of 0xffff0000. But for the life of me, I can't find anywhere that actually references that value to place the start code at that point.
Placing the final boot image is left to user who flashes/burns it board. But it should be same as _TEXT_BASE (this is being removed now. Orion5x is arm based). Also look at<u-boot-src>\arch\arm\cpu\arm926ejs\start.S& <u-boot-src>\arch\arm\cpu\arm926ejs\u-boot.lds for more info on how linker is instructed to place the starting code at predefined address.
I'm basically trying to make sure that my CONFIG_SYS_TEXT_BASE is correct (the address in the flash to which I write the whole u-boot.bin file, right?.
This is passed to linker as the entry point.
There is another point re: orion5x based boards: often, their designers preferred generating a linear image for U-Boot, but the fact that the vector address is at FFFF0000 makes it impossible to directly the image there because it is always greater than 64K. So the designers put some "pseudo-rom boot code" at FFFF0000 that will finally jump to an address lower in FLASH; for ED Mini V2 it is FFF90000, and that's where the U-Boot image is supposed to be flashed.
So, is that the address that you would use for CONFIG_SYS_TEXT_BASE ?
Yes, exactly.
Rogan, I bet in the DNS323 case, the same applies modulo your Flash size. Try tracing through the FFFF0000 code, it should not last more than a few tens of instructions before it jumps to some absolute address.
Do you think it would be possible to figure it out from the original vendor u-boot?
Sort of: if you look up the vendor U-Boot source code and find nothing about 0xFFFF0000, that's a sign that it expects something else than U-Boot to kick in at that address.
You can also disassemble what lies at 0xFFFF0000 on your board, either live through JTAG or offline by running a binary extract of FFFF0000 through objdump.
Thanks
Rogan
Amicalement,
On 2011/04/20 10:29 AM, Albert ARIBAUD wrote:
Hi Rogan,
Le 20/04/2011 09:46, Rogan Dawes a écrit :
On 2011/04/20 7:42 AM, Albert ARIBAUD wrote:
Le 20/04/2011 04:23, Hebbar, Gururaja a écrit :
Hi,
On Wed, Apr 20, 2011 at 02:43:23, Rogan Dawes wrote:
Hi folks,
I'm trying to understand a bit more about how u-boot creates the image, such that the CPU reset vector is pointing to the right piece of code when it is reset.
i.e. my DNS323 (Orion5x) has a reset vector of 0xffff0000. But for the life of me, I can't find anywhere that actually references that value to place the start code at that point.
Placing the final boot image is left to user who flashes/burns it board. But it should be same as _TEXT_BASE (this is being removed now. Orion5x is arm based). Also look at<u-boot-src>\arch\arm\cpu\arm926ejs\start.S& <u-boot-src>\arch\arm\cpu\arm926ejs\u-boot.lds for more info on how linker is instructed to place the starting code at predefined address.
I'm basically trying to make sure that my CONFIG_SYS_TEXT_BASE is correct (the address in the flash to which I write the whole u-boot.bin file, right?.
This is passed to linker as the entry point.
There is another point re: orion5x based boards: often, their designers preferred generating a linear image for U-Boot, but the fact that the vector address is at FFFF0000 makes it impossible to directly the image there because it is always greater than 64K. So the designers put some "pseudo-rom boot code" at FFFF0000 that will finally jump to an address lower in FLASH; for ED Mini V2 it is FFF90000, and that's where the U-Boot image is supposed to be flashed.
So, is that the address that you would use for CONFIG_SYS_TEXT_BASE ?
Yes, exactly.
Rogan, I bet in the DNS323 case, the same applies modulo your Flash size. Try tracing through the FFFF0000 code, it should not last more than a few tens of instructions before it jumps to some absolute address.
Do you think it would be possible to figure it out from the original vendor u-boot?
Sort of: if you look up the vendor U-Boot source code and find nothing about 0xFFFF0000, that's a sign that it expects something else than U-Boot to kick in at that address.
You can also disassemble what lies at 0xFFFF0000 on your board, either live through JTAG or offline by running a binary extract of FFFF0000 through objdump.
Ok, so this is what I get at 0xffff0000:
0000000: 5c10 9fe5 0060 91e5 5810 9fe5 0160 06e0 ....`..X....`.. 0000010: 5410 9fe5 0100 56e1 0f00 001a 4c10 9fe5 T.....V.....L... 0000020: 0060 91e5 ff10 a0e3 0160 06e0 0100 56e3 .`.......`....V. 0000030: 0800 001a 3810 9fe5 0060 91e5 3410 9fe5 ....8....`..4... 0000040: 0160 06e0 3010 9fe5 0160 86e1 2010 9fe5 .`..0....`.. ... 0000050: 0060 81e5 0100 00ea 0000 00ea ffff ffea .`.............. 0000060: 18f0 9fe5 0000 04d0 0000 ffff 0000 8152 ...............R 0000070: 0800 04d0 2001 02d0 8080 ffff 1b82 0000 .... ........... 0000080: 0000 fdff ffff ffff ffff ffff ffff ffff ................
Which disassembles to:
$ arm-linux-gnueabi-objdump -m arm -b binary -D mtdblock4-3
0: e59f105c ldr r1, [pc, #92] ; 0x64 4: e5916000 ldr r6, [r1] 8: e59f1058 ldr r1, [pc, #88] ; 0x68 c: e0066001 and r6, r6, r1 10: e59f1054 ldr r1, [pc, #84] ; 0x6c 14: e1560001 cmp r6, r1 18: 1a00000f bne 0x5c 1c: e59f104c ldr r1, [pc, #76] ; 0x70 20: e5916000 ldr r6, [r1] 24: e3a010ff mov r1, #255 ; 0xff 28: e0066001 and r6, r6, r1 2c: e3560001 cmp r6, #1 30: 1a000008 bne 0x58 34: e59f1038 ldr r1, [pc, #56] ; 0x74 38: e5916000 ldr r6, [r1] 3c: e59f1034 ldr r1, [pc, #52] ; 0x78 40: e0066001 and r6, r6, r1 44: e59f1030 ldr r1, [pc, #48] ; 0x7c 48: e1866001 orr r6, r6, r1 4c: e59f1020 ldr r1, [pc, #32] ; 0x74 50: e5816000 str r6, [r1] 54: ea000001 b 0x60 58: ea000000 b 0x60 5c: eaffffff b 0x60 60: e59ff018 ldr pc, [pc, #24] ; 0x80 64: d0040000 andle r0, r4, r0 68: ffff0000 ; <UNDEFINED> instruction: 0xffff0000 6c: 52810000 addpl r0, r1, #0 70: d0040008 andle r0, r4, r8 74: d0020120 andle r0, r2, r0, lsr #2 78: ffff8080 ; <UNDEFINED> instruction: 0xffff8080 7c: 0000821b andeq r8, r0, fp, lsl r2 80: fffd0000 ; <UNDEFINED> instruction: 0xfffd0000
And of course, the image that I wrote to the flash did not have this, which explains perfectly why nothing works anymore.
Doh!
Now if I can just figure out how to write to my flash using OpenOCD, I can hopefully recover.
Regards,
Rogan
On 2011/04/20 12:17 PM, Rogan Dawes wrote:
Now if I can just figure out how to write to my flash using OpenOCD, I can hopefully recover.
Regards,
Rogan
Phew! Thanks to Albert's sloflash utility, I was finally able to get something back into my flash, and get the board booting again. What a relief! :-D
Now I need to solve the problem of placing the _start code at the address of the reset vector, since I have 3 64kB sectors to play with, but one of them is 99% empty, other than the reset vector code which just jumps to _start.
And of course, a mainline u-boot will not fit into just 128kB.
Any thoughts on how to link u-boot to place _start or any other routine that can jump to _start at 0xffff0000?
I had this suggestion on IRC:
. = .; __u_boot_cmd_start = .; .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .;
. = _start + 0x70000; .reset_vector_sect : { arch/arm/cpu/arm926ejs/start.o (.reset_vector_sect) *(.reset_vector_sect) }
#include <asm-offsets.h> #include <config.h> #include <common.h> #include <version.h>
.section ".reset_vector_sect",#alloc, #execinstr _reset_vector: b _start
Although I'm not sure how to interpret it :-)
Regards,
Rogan
Le 22/04/2011 14:45, Rogan Dawes a écrit :
On 2011/04/20 12:17 PM, Rogan Dawes wrote:
Now if I can just figure out how to write to my flash using OpenOCD, I can hopefully recover.
Regards,
Rogan
Phew! Thanks to Albert's sloflash utility, I was finally able to get something back into my flash, and get the board booting again. What a relief! :-D
Now I need to solve the problem of placing the _start code at the address of the reset vector, since I have 3 64kB sectors to play with, but one of them is 99% empty, other than the reset vector code which just jumps to _start.
And of course, a mainline u-boot will not fit into just 128kB.
Any thoughts on how to link u-boot to place _start or any other routine that can jump to _start at 0xffff0000?
I had this suggestion on IRC:
. = .; __u_boot_cmd_start = .; .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .; . = _start + 0x70000; .reset_vector_sect : { arch/arm/cpu/arm926ejs/start.o (.reset_vector_sect) *(.reset_vector_sect) } #include<asm-offsets.h> #include<config.h> #include<common.h> #include<version.h> .section ".reset_vector_sect",#alloc, #execinstr _reset_vector: b _startAlthough I'm not sure how to interpret it :-)
Basically (the excepts are only a sketch of what is really needed) it amounts to manually mapping code sections, some at FFF80000 and some (the reset vectors first) at FFFF0000. It does not fill up the last sector at FFFF0000, not in this form at least, because the last sector would only contain the reset sector sections; you'd have to select other input sections to complement the reset vector ones. Plus, the generated binary would actually span the whole flash, from FFF80000 to FFFFxxxx, which is *huge*.
Regards,
Rogan
Amicalement,
participants (3)
-
Albert ARIBAUD -
Hebbar, Gururaja -
Rogan Dawes