Dingoo Tx/Rx points hacked by booboo; firmware boot sequence dumped

Hats off to booboo at the Spanish GP32x forums, for this masterful (and very neat looking!) hack to access the Tx/Rx connections under the Dingoo’s LCD screen.

booboo: The operating system is, almost with complete certainty, uCOS-II. It is a system multitask in quite basic real time. Surely the messages that are seen during the starting are almost all of bootloader, that is the code that is in charge to load in memory and to landar the operating system. The grace of this micro ones is that it has an internal ROM that allows to load what you want in the ram (cache) via USB. That is to say, you can completely be loaded all the content of the flash and the system is recoverable (first load in Ram-cache a code that initializes the SDRAM, soon load in the SDRAM another code that already serves to initialize and to record the flash). < - > Bond, to see if now it lets to me put the connections to which I have made to accede to the console: Esta imagen ha sido reducida. Pincha aquí para ampliarla. La imagen original es de 3648x2736. Esta imagen ha sido reducida. Pincha aquí para ampliarla. La imagen original es de 3648x2736. Esta imagen ha sido reducida. Pincha aquí para ampliarla. La imagen original es de 3648x2736. Esta imagen ha sido reducida. Pincha aquí para ampliarla. La imagen original es de 3648x2736. Esta imagen ha sido reducida. Pincha aquí para ampliarla. La imagen original es de 3648x2736. Esta imagen ha sido reducida. Pincha aquí para ampliarla. La imagen original es de 3064x2480.

This enabled booboo to establish the following (fans of Battlestar Galactica will notice that Dingoo creates a faster than light hyperdrive field every time you turn it on):

booboo: Good… already I have the finished invention and I have captured output of the starting of firmware that comes from factory, now to trastear with linux. I will already put connections to the photos and all that as soon as it has 10 messages (it is what must be new): NAND Booting… ECD755B6. to loader size = 0x00051670 .00000114:1. OK NAND Loading… get ccpmp_config ok! ccpmp_config.firmware_name = A320.HXF ccpmp_config.update_key = 123, ccpmp_config.lcm.width = 320, ccpmp_config.lcm.height = 240. 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 = 0 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. D31 00001550:1.00002: is 1.len 0x 500000 23a078 os_len = 0x. checksum = 0x0a232c05. 1 - ret = 0 2 - ret = 1 Run image… c_main to enter------! kseg init OK! new to loader, system config ok! intc init OK! intc lib OK! the you is start

And he explains more here:

To see if they serve these to you: Esta imagen ha sido reducida. Pincha aquí para ampliarla. La imagen original es de 3648x2736. Esta imagen ha sido reducida. Pincha aquí para ampliarla. La imagen original es de 3648x2736. Esta imagen ha sido reducida. Pincha aquí para ampliarla. La imagen original es de 3648x2736. It is happened to me that perhaps what you want to see is by where I have removed the cablecillos from behind display. I have not made photos of that because I needed hands. My display behind has THREE bands of gomaespuma sticky that you can see in the photo: it arrives, down and by the side by where it is connected. I have removed to the cables on the other side indeed because there is no band of gomaespuma. That means that they have left right by the side in opposition to where had placed the connector, reason why if you pay attention well to some of the photos that I have put it sees as the cables pass until the other side reasoning between the plate and the housing. He wanted to have removed threads by the same side by where display is connected, closely together from the edge inferior, and I have even cleared a small piece of band of gomaespuma with that aim, but in the end he is that it was almost impossible that the cables remained in their site while becomes to mount everything. Removing them by I have removed where them I have even had to use a pair of very small drops of loctite to maintain stuck them to the circuit printed behind the LCD. By the way, if you are going away to put to it, you are going to have to use VERY fine cables because there is VERY little site behind display. I was going to use cable of wrapping of 0,45mm but in the end I have used copper enameled of 0,30mm that was what had by hand. I prefer the plastic isolation to the enameling, but 0,45mm was too heavy, and 0,30mm is thus thus… < - >   Originally Written by Ruxy Very interesting the images, furthermore, and so habeis saying, we can hope that in too much time it is not possible to be made work some version of linux in the aparatito? and if one is able to make work, that podria to get itself to do with linux in this maquinita? to bring ports of other emulators. Greetings, and luck to which stays investigating with the aparatito. booboo’s answer: An operating system like uCOS-II is than sufficient more for a console of games or a PMP, that do not need all the functionalities outposts of linux. In addition uCOS-II is more compact and consumes less resources. The question is that in fact there are resources very well (as much flash as ram) and to put linux contributes a ONLY great advantage: it provides surroundings of development known for that already many emulators are written and applications whose carried he would be very simple. In the operating systems of high level for computers there is always a barrier defined between kernel of the operating system and the applications very well. Kernel has an entry point through what it provides all the services to All the applications. However in the systems “embedded” and with operating systems in real time type uCOS-II this usually is not thus. The operating system and “the main” application that runs in the apparatus form a monolithic image that is what there are been calling “firmware”, and is the manufacturer of firmware the one that decides if it provides an entry point for other applications and the API that uses. It is why although we know that the operating system is uCOS-II in fact with that we did not gain anything, since we do not know the API of firmware of chinachip. However, bookstores S2D exist that Dingoo provides for which IF that is a public API, so that at the time of programming it is necessary to fit itself UNIQUE to the API that provides these bookstores. Obvious as uCOS-II does not implement a way “protected” (I do not know clearly if it wants that it can in this CPU) any application that we do can accede directly to hardware immediately than writing in the opportune directions of memory. Nevertheless, it will be being been making of concurrent form to the operating system and therefore the results are unpredictable, as I believe that already it has verified somebody with the subject of overclocking.

Absolute respect to your fantastic work, booboo!

Update: Read a less detailed, “native” English version of this news here.