oscarboiro wrote: ↑02 Mar 2019, 15:18
My conclussion is, i think any sector more have information or any reference to detect Cyclone or Cyclone II or another difference in the PCB, but i don´t know. now i think to put a backup of a NX with rear camera and Cyclone II chip and try to Install SP3.5
I agree that there is some gap we need to look after. I told you about my faulty NX to repair. It had the well known restart loop syndrome. Powers up and after 20 seconds (arg, here they are again!) it switches off and restarts over again. I thought "an easy fix, just reflash". Of course i first backuped the Flash to have also sector 507 for later. Then i flashed one of my working NX dumps on it, and it boots up like a charm. All fine, i thought and started the regular SP5.3 Firmwareupdate. I let it run as it looks fine. After it is finished the unit restarts and goes into sleep mode. Normally it can be revoked by pressing the ON-tipper, but nothing happened. Since then i try to recover it.
So, it's similar to your problem, just with another dimension. You "only" use button control (which i never ever heard before) and i use the mainboard. It draws about 100 mA at 14V and i could access the Flash so far. Tried to erase and program different images multiple time whith no luck. Of the powerdraw it looks like the HMI had an software crash or such. Just to be safe i also replaced the RAM chips, but this does not help either.
The unit i have here to fix has part number "7S7T-18K931-BL" (Bosch 7 612 300 534). The original MAIN_VER_SW was "0843_090128" (date 28.01.2009) a very old firmware. The REG_VERSION was "DI_SWNAVI6.4C1P7.3", but i guess it's only relevant for navigation application. The software on the graphicsboard shurely fits to this somehow. After an update they are both changed, of course.
Another thing that keeps my attraction was, that it's not possible to write the first sector 0, it seems readyonly for the Segger. This may be ok, because it contains the bootloader of the system. Without it, or with an damaged one, the unit can't start anymore. But as i found out, after an update to SP5.3 it changes content. The update software seems to be able to unlock and overwrite the sector. The bootloader software is given in the PSW software version, found inside the flash.
The original flash starts with: "D3 02 00 EA 05 00 00 EA 05 00 00 EA 05 00 00 EA"
whereas after the update: "CE 07 00 EA 05 00 00 EA 05 00 00 EA 05 00 00 EA"
For now i beliefe the OMAP starts like every other CPU from address 0x0. I know it executes the software rights from the NOR flash, like a ROM. So what could this mean? I think this is simple ARM9 machine code. The repeating pattern looks like this is a vector area, where external and internal interrupts set the PC to a location and executed from there. If i put the line into
ODA i get this Assembler code:
Code: Select all
.data:00000000 d3 02 00 ea b 0x00000b54
.data:00000004 05 00 00 ea b 0x00000020
.data:00000008 05 00 00 ea b 0x00000024
.data:0000000c 05 00 00 ea b 0x00000028
and from the second one:
Code: Select all
.data:00000000 ce 07 00 ea b 0x00001f40
.data:00000004 05 00 00 ea b 0x00000020
.data:00000008 05 00 00 ea b 0x00000024
.data:0000000c 05 00 00 ea b 0x00000028
Let's just look on the first command, 'b'. The ARM Assembler Reference tells us this about it:
arm_b_bl_instruction.png
Always remember: ARM uses Little-Endian (bytes read from right to left) and 4 Bytes (32 Bits) per instruction. So if we translate the byte sequence "d3 02 00 ea" into Bit-Endian we get "ea 00 02 d3" which in Binary shown as: "1110 1010 0000 0000 0000 0010 1101 0011".
From left (Bit 31, or MSB) to right (Bit 0, or LSB) we have:
"1110" = "cond", this pattern means "AL" (always, or unconditional branch).
"101" = denotes the Mnemonic 'b' for branch (referred in other Assembler languages as jump or jmp)
"0" = "L", means to not store a return address into register R14.
"0000 0000 0000 0010 1101 0011" = "target address", which is an offset to the current program counter register PC. In hex the offset is "0x2d3".
Now, we CAREFULLY read what is written as target address calculation.
1. the value (0x2d3) is extended to 30 bit, which leaves it 0x2d3.
2. the 30 bit value is shifted the left by two bits to form a 32-bit value. So 0x2d3 gets "0000 0000 0000 0000 1011 0100 1100", which means 0xb4c.
3. PC is added to the value. PC always points to the next instruction. Because each instruction is 4 Bytes in size, the PC is 8 Bytes ahead from the offset given in the command. This has to be added. So we have 0xb4c + 8 = 0xb54
One conclusion here is, that a "b" instruction does not get an abritrary memory location, it gets and command location. This is a neat trick to avoid wrong calculated branches to illegal offsets. Think about it, even if it takes some time, you see it's totally locical. BTW: a bitshift by 2 is equal to a mulitplication with 4. So as an shortcut to read hexdumps, the first two bytes (turned around) multiplied by 4 plus 8 bytes results in the target address of the branch.
At 0xB54 on the first bootloader we find:
Code: Select all
00000b54 d3 00 a0 e3 mov r0, #211 ; 0xd3
00000b58 00 f0 21 e1 msr CPSR_c, r0
00000b5c bc 07 9f e5 ldr r0, [pc, #1980] ; 0x00001320
00000b60 00 10 90 e5 ldr r1, [r0]
00000b64 b8 27 9f e5 ldr r2, [pc, #1976] ; 0x00001324
00000b68 02 00 51 e1 cmp r1, r2
00000b6c d7 01 00 1a bne 0x000012d0
00000b70 b0 07 9f e5 ldr r0, [pc, #1968] ; 0x00001328
00000b74 01 10 a0 e3 mov r1, #1
00000b78 14 10 80 e5 str r1, [r0, #20]
00000b7c a8 27 9f e5 ldr r2, [pc, #1960] ; 0x0000132c
00000b80 00 30 92 e5 ldr r3, [r2]
00000b84 0e 28 a0 e3 mov r2, #917504 ; 0xe0000
00000b88 02 20 13 e0 ands r2, r3, r2
00000b8c 15 00 00 1a bne 0x00000be8
and on the second one at 0x1f40
Code: Select all
00001f40 d3 00 a0 e3 mov r0, #211 ; 0xd3
00001f44 00 f0 21 e1 msr CPSR_c, r0
00001f48 bc 07 9f e5 ldr r0, [pc, #1980] ; 0x0000270c
00001f4c 00 10 90 e5 ldr r1, [r0]
00001f50 b8 27 9f e5 ldr r2, [pc, #1976] ; 0x00002710
00001f54 02 00 51 e1 cmp r1, r2
00001f58 d7 01 00 1a bne 0x000026bc
00001f5c b0 07 9f e5 ldr r0, [pc, #1968] ; 0x00002714
00001f60 01 10 a0 e3 mov r1, #1
00001f64 14 10 80 e5 str r1, [r0, #20]
00001f68 a8 27 9f e5 ldr r2, [pc, #1960] ; 0x00002718
00001f6c 00 30 92 e5 ldr r3, [r2]
00001f70 0e 28 a0 e3 mov r2, #917504 ; 0xe0000
00001f74 02 20 13 e0 ands r2, r3, r2
00001f78 15 00 00 1a bne 0x00001fd4
No really a difference, just in memory location
Conclusion: The old bootloader code starts at address 0xb54, and the new bootloader code at address 0x1f40. This is not a problem at all, because the bootloader seems to be fully contained within the first sector. But if the data in the second sector (and following) is also somehow other aligned, this may cause problems.