Booboo Linux update on dual boot challenges
Booboo explains about the challenges of getting Linux to dualboot below.
Hello, I am trying to obtain the dual boot.
On ccpmp.bin I know that:
1 - Load in 0x80004000.
2 - The size of data to load is in the second DWORD.
3 - Once loaded, loader 0x80004008 jumps to the position.
Ccpmp.bin complete occupies 5MB, but only a little more 2MB is occupied. The rest is free to put what we want, although will be only loaded if DWORD modifies suitably secondly. I have verified that putting 0x00500000 (=5MB) in the second DWORD everything continues working correctly.
The strategy is:
1 - To carry u-boot and to form it so that carge kernel and root filesystem of miniSD. This already is done and works perfectly if position directly this u-boot in memory I execute and it.
2 - To modify u-boot so that their direction of load is 0x80404000 (0x80004000 + 4MB).
3 - “To inlay” u-boot in offset +4M of the file, which would be equivalent to once loaded in memory to the position 0x80404000, that is so I have compiled u-boot.
4 - To patch the first instructions of ccpmp.bin in 0x80004008 with a jump to the position where u-boot will be loaded (0x80404000).
5 - In that position to put a code ASM that verifies the state of a key: if it is not they pulsadan executes the instructions that were patched and jumps again to ccpmp.bin, and so the system would have to start again. If the key is pressed, it continues executing u-boot, which mounts miniSD and loads kernel, etc.
All that already is done, but I am with a problem: u-boot works perfectly if it position directly in memory in the position 0x80404000. Nevertheless, “I inlay when it” in ccpmp.bin:
a) The normal starting of a320 works correctly: that is to say, 0x80404000 skips to the position, is verified there that the key is not pressed, execute the instructions eliminated in I patch and it skips again to ccpmp.bin. All OK.
b) The starting u-boot only works but until the load of kernel begins (or perhaps the boot of miniSD, I do not know it safe). It gives to an exception “TLB load”. I suspect that the problem is that loader of firmware original it advances enough in the configuration of the CPU (the TLB has to do with the MMU) whereas u-boot waits for “a virgin” system much more. Somebody that knows more than I of architecture MIPS can draw some conclusion from all this?
The following thing is the console capture when it is taken with puts a roof on pulsation (I am using SELECT, but it is possible to be changed easily).
NAND Booting… ECD755B6.
to loader size = 0x00051670
OK NAND Loading…
get ccpmp_config ok!
ccpmp_config.firmware_name = A320.HXF ccpmp_config.update_key = 123, ccpmp_con.
to loader normal mode…
Creating ftl device…
you go: EC D7 55 B6 78
you go: 00 00 00 00 00
you go: 00 00 00 00 00
you go: 00 00 00 00 00 OK.
usb_connect = 1
into lcd_init. to loader -- into lcd_init.
to loader -- init_lcd_gpio ok.
to loader -- to init_lcd_register ok.
to loader -- out lcd_init.
VALUE = 3.
is len 0x 500000
checksum os_len = 0x 500000. = 0x26f75489.
1 - ret = 0
2 - ret = 1
U-Boot 1.1.6 (May 12 2009 - 02:54: 16) Board: Dingoo A320 (CPU Speed 336 MHz) DRAM: 32 MB Flash: 0 kB Using default environment
Hit any key to stop autoboot: 0
MMC card found
IT CAUSES: 00800008 TLB load
ra = 81FC1D38 fp = 00000027 gp = 81FCBDD0 t9 = 81FBBED8
t8 = 00000000 00000003 FFFFFFFF s7 = s6 = s5 = 0000005C
s4 = B0010168 s3 = B0010158 s2 = 81FCE490 s1 = 81FCE490
s0 = 00000000 t7 = 00000000 t6 = 00000000 t5 = 81FCA844
t4 = 00000020 T3 = 81EAAD48 t2 = 00000004 T1 = 00000009
t0 = 81FCDFBC a3 = 00000000 a2 = 00000004 a1 = 00000000
a0 = 81FCDFBC v1 = 00000012 v0 = 00000000 AT = 00000000
= 00001CD1 HI = 00003000 ST = 10000402 EPC = 81FBBEE8
Now, I'm not an expert in either Linux or reading Google translated text, but it does seem to me that Booboo has hit a hitch. So, help him if you can.