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
Hebbar
Hi,
Quoted 6 lines · Rogan Dawes
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.
Quoted 2 lines
I'm basically trying to make sure that my
CONFIG_SYS_TEXT_BASEis 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.
Quoted 3 lines
Thanks
Rogan
Regards,
Gururaja
Le 20/04/2011 04:23, Hebbar, Gururaja a ?crit :
Quoted 7 lines
Hi,
Quoted 4 lines · Rogan Dawes
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.
Quoted 8 lines
Quoted 2 lines
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.Quoted 2 lines
I'm basically trying to make sure that my
CONFIG_SYS_TEXT_BASEis 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.
Quoted 3 lines
Quoted 3 lines
Thanks
Rogan
Amicalement,
Signature · 1 line
Albert.
Quoted 28 lines · Albert ARIBAUD
Le 20/04/2011 04:23, Hebbar, Gururaja a ?crit :
Quoted 21 lines
Hi,
Quoted 10 lines · Rogan Dawes
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.Quoted 5 lines
Quoted 4 lines
I'm basically trying to make sure that my
CONFIG_SYS_TEXT_BASEis 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.
Quoted 7 lines
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 ?
Quoted 3 lines
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 :
Quoted 37 lines · Albert ARIBAUD
Quoted 28 lines
Le 20/04/2011 04:23, Hebbar, Gururaja a ?crit :
Quoted 21 lines
Hi,
Quoted 10 lines · Rogan Dawes
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.Quoted 5 lines
Quoted 4 lines
I'm basically trying to make sure that my
CONFIG_SYS_TEXT_BASEis 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.
Quoted 7 lines
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.
Quoted 1 line
So, is that the address that you would use for
CONFIG_SYS_TEXT_BASE?
Yes, exactly.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 3 lines
Thanks
Rogan
Amicalement,
Signature · 1 line
Albert.
Quoted 52 lines · Albert ARIBAUD
Hi Rogan,
Le 20/04/2011 09:46, Rogan Dawes a ?crit :
Quoted 37 lines · Albert ARIBAUD
Quoted 28 lines
Le 20/04/2011 04:23, Hebbar, Gururaja a ?crit :
Quoted 21 lines
Hi,
Quoted 10 lines · Rogan Dawes
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.Quoted 5 lines
Quoted 4 lines
I'm basically trying to make sure that my
CONFIG_SYS_TEXT_BASEis 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.
Quoted 7 lines
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.
Quoted 1 line
So, is that the address that you would use for
CONFIG_SYS_TEXT_BASE?Yes, exactly.
Quoted 7 lines
Quoted 4 lines
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?
Quoted 7 lines
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
0xFFFF0000on 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
Quoted 6 lines · Rogan Dawes
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 :-)
Regards,
Rogan
Le 22/04/2011 14:45, Rogan Dawes a ?crit :
Quoted 48 lines · Rogan Dawes
Quoted 6 lines
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
_startcode 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
_startor any other routine that can jump to_startat0xffff0000?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
Quoted 1 line
Although 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*.
Quoted 3 lines
Regards,
Rogan
Amicalement,
Signature · 1 line
Albert.