From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rogan Dawes Date: Wed, 20 Apr 2011 12:17:16 +0200 Subject: [U-Boot] How does u-boot know where to put its start code? In-Reply-To: <4DAE9971.5040204@aribaud.net> References: <4DADFAF3.8090301@dawes.za.net> <4DAE722F.3090804@aribaud.net> <4DAE8F6D.8040807@dawes.za.net> <4DAE9971.5040204@aribaud.net> Message-ID: <4DAEB2AC.6000204@dawes.za.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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\arch\arm\cpu\arm926ejs\start.S& >>>> \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 ; instruction: 0xffff0000 6c: 52810000 addpl r0, r1, #0 70: d0040008 andle r0, r4, r8 74: d0020120 andle r0, r2, r0, lsr #2 78: ffff8080 ; instruction: 0xffff8080 7c: 0000821b andeq r8, r0, fp, lsl r2 80: fffd0000 ; 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