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.
into init_lcd_gpio.
out init_lcd_gpio.
to loader -- init_lcd_gpio ok.
into Init_LCM_MOUDLE_ILI9325!
out Init_LCM_MOUDLE_ILI9325!
to loader -- to init_lcd_register ok.
to loader -- out lcd_init.
Start decode…
OK 153602.
out lcd_init.
get_lcd_brightness --
VALUE = 3.
is len 0x 500000
checksum os_len = 0x 500000. = 0x26f75489.
1 - ret = 0
2 - ret = 1
Run image…
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
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
MMC card found
=============================================================
Exception:
SP: 81EAAA28
EPC: 81FBBEE8
IT CAUSES: 00800008 TLB load
Reg dump:
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.
Would be nice if booboo could join some english speaking forum, either http://forum.openhandhelds.org/index.php or http://a320.freeforums.org/
ReplyDeleteAs for this error - I'd say turning MMU off could help (but I don't know how this is done for MIPS). At least for ARM architecture linux kernel expects MMU and CPU cache off. Maybe uboot could do it?
ANd BTW from the exception message "IT CAUSES: 00800008 TLB load " I'd say it faults back to initial chinese boot code, It doesn't look like uboot or linux kernel message to me.
ReplyDeleteI'll kindly ask in the spanish forums whether they mind if I write in english. I think they all understand it. Or perhaps I should put some time in using the wiki that Larry kindly set up for me.
ReplyDeleteI think it is possible that turning off the MMU will solve the problem, however, I don't know how to do it and it was way too late in the night as to start reading dense MIPS documents.
About the exception message, yes, I do know for sure that the message is printed by the exception handler which is in the original loader (in fact, the exception is triggered by my u-boot code, not by the linux kernel which is not yet loaded by u-boot).
BTW, I also tried to embed the linux kernel into the ccpmp.bin (instead of u-boot). It defeats the purpose because won't let you experiment with different kernels in the miniSD, but was an experiment to see what happens, actually to see if the kernel would be able to deal with the already initialized MMU better than u-boot.
It turns out that the kernel hangs too. No exception message this time, though.
I think I'll focus on getting the sound working and publishing all the information. That way, you would be only able to boot linux by using a PC: setting the A320 in USB boot mode (reset+B) and then uploading the u-boot code, which I have preconfigured to load the kernel from miniSD.
Hi booboo, there in no problem in you writing in spanish, google translate works fine. The problem is that non-spanish people like me cannot join the discussion on spanish forum.
ReplyDeleteAs for publishing your uboot and linux kernel work, please do. I guess there are more people waiting for your kernel and uboot source patches (and maybe some binaries for quick start too) so they can join the hacking.
I hope uboot supports usb serial console (and linux kernel has usb serial gadget too) so I don't need to open my dingoo to get to console prompt of both uboot and linux.
Many thanks for your work on porting linux to A320 :-)
BooBoo take your time and get it right. There are many, many people hoping you succeed in your efforts to get Linux running.
ReplyDeleteWe appreciate everything your doing :)
So what happens after Linux is fully functional?
ReplyDelete@ ryan- once linux is functional we should be seeing a massive influx of ports of all kinds of programs. Basically every issue there currently is with the dingoo can be fixed pretty easily, and porting programs becomes a much much easier process.
ReplyDeleteTo name a few things we could do: port vlc (thus fixing video qualms, adding subtitles & probably increasing quality as well), a better mp3-player (with id3, album art & a real visualizer), possibly implement on-demand processor management & advanced power management (thus boosting the already stupendous battery life), most emus can be ported nearly effortlessly (only minor modifications & a recompile should be needed), open-source games & interpreters can be ported (Doom, Quake, etc.), and that's just the tip of the iceberg. I'm sure some very useful apps will be available too (here's hoping for a powerpoint displayer & pdf viewer, that'd make presentations ridiculously simple with the tv out =D).
Soooo yah... Things are really looking forward for our little guy. I have a feeling that because of the price point the scene will explode once we've got linux at our fingertips. I'm already buffing up on coding & compiling in preparation so that I might be of some use.
@ booboo- Your work is very much appreciated, and I must say I am really amazed by the speed at which you have been developing. I'd like to personally extend my gratitude to you by saying Good luck, Good code & Godspeed my friend! =D
so...since i know very little about this sort of thing, does it look like it will be almost certainly possible to get linux running on the a320? or is there a chance it won't work?
ReplyDeleteregardless, your work is greatly appreciated, booboo! godspeed.
Booboo, Ill try to post this on the gp32spain board as well since Im not sure if your monitoring this. I checked the ingenic ftp today and it looks like they have updated the patches for both uboot and the linux kernel. The updates have dates of may 3 and 6th and they seem different from the original ones that were posted at various sources.
ReplyDeleteI'm really bored with my Dingoo now. There's not much I can do with just GBA and NES games, and the arcade games are boring.
ReplyDelete@Ryan
ReplyDeleteWell isn't that an interesting fact. Thank you for sharing with all of us. Random information about other peoples boredom is what I live for.
Also if you didn't like GBA or NES or arcade games what exactly did you purchase the dingoo for.
I'm bored with my dingoo because I can't use it as a jet ski or open a bar tab with it.
Thanks for the heads up on the Ingenic FTP update. I've updated my local mirror and examined the differences. No major changes so far.
ReplyDeleteSomeone asked about USB serial gadget:
1- u-boot USB serial gadget does not work (it seems to be implemented only for OMAP1510).
2- kernel USB serial gadget WORKs fine.
u-boot USB serial gadget not working is not a problem at all. These are two of the many possible schemes I'm using to boot linux right now:
Scheme A: loading a kernel image into RAM vía USB:
1- Enter USB boot mode.
2- Upload the hardware initialization code.
3- Upload the zImage to 0x80600000 and execute it.
Scheme B: loading u-boot into RAM vía USB:
1- Enter USB boot mode.
2- Upload the hardware initialiaztion code.
3- Upload u-boot to 0x80100000 and execute it.
4- u-boot loads zImage from first partition of MMC card.
Notes:
- The kernel image has an embedded default parameter so there's no need for u-boot to pass them. The root is in the SECOND partition of the miniSD (ext3).
- The u-boot image has an embedded default boot command line that will initialize the miniSD and load zImage from the first partition (which MUST be FAT).
To summarize: I'm using a two partition miniSD. First partition is FAT and contains only zImage. Second partition is ext3 and contains the root filesystem. I load the hardware initialization code using usbtool (from the onda vx747 folks) and then my custom u-boot image, which continues boot from miniSD.
For those whom prefer not to open their dingoos, the only drawback is that you can't see anything of the boot process. You just get a login vía the host PC /dev/ttyACM0 device.
That is fine for general programming and maybe even for some kernel module hacking, but the true serial console is necessary for the early initialization stuff.
Forgot to mention that you don't even need to unplug the miniSD card to update the zImage or the root filesystem. Just boot into the original firmware and since it exports the whole block device, the two partitions (FAT and EXT3) will be visible and writable from the host PC (linux, of course). Just modify the files and the reset the dingoo in USB boot mode, load the HW initialization, load the u-boot, etc...
ReplyDelete