An interview with Booboo

This is a pivotal time for the Dingoo and Linux. Booboo was kind enough to spare some time and answer some questions for the community.

 

> Hi Booboo! Hi Larry! > The release of the your Linux kernel has created a lot of buzz. How does this make you feel? Great!. Really great. I'm not the love-lots-of-attention kind of person, but it's extremely rewarding to receive acknowledgement for your effort and encouragement to go on. > So, are things at this stage, going as you hoped with Linux? Yes. As soon as a working kernel/rootfs became available a bunch of coders started playing around with it. > Now, some people have compiled apps. ezelkow1 is working on the toolchain. Do you know of anything else going on in development world which you are excited about? Not really. That's pretty much everything we need for the final user: kernel working, an efficient toolchain/rootfs, and dual boot working. That's the immediate priority: the final user must be able to run linuxs emus and apps on his A320, no matter if he has to reboot each time. We can then take our time to implement full hardware support in the kernel and develop a set of applications that replace the original firmware. > At the moment, Linux can only be launched from a PC, and the Dingoo must stay connected to the PC at all times.  Of course, being able to launch and run Linux without being tethered to the PC is the key to usable Linux for all. What specific work needs to be done to achieve this - either with or without dual boot? I've successfully installed and booted linux from the internal flash, but I feel that is of little use until full hardware support is achieved in the kernel and a set of base user space applications is developed (audio player, video player, and such). So, for the time being (and don't hold your breath), we must keep the original firmware available and that means we need dual boot. Dual boot is hard to get working because you must be nice to the original firmware. That means you can use only certain areas of the internal flash and tap into the original firmware boot process in a way that goes unnoticed to it. Not that the original firmware is actively working to prevent tapping, it's just that it is code designed for working in a very specific runtime environment and circumstances and thus it is not designed to handle errors that happen if that environment changes. I first tried to tap very late in the boot process (when the ccpmp.bin file gets executed). That had the advantage of not using any "special" tool (final users would just need to use the standard firmware upgrade process), but failed. It turns out that as peripherals and memory management unit is already initialized, you first have to do a "cleanup" before the linux kernel starts, since the startup process expects a very specific system state (ring a bell?), which is as it comes out of reset. That first approach is still very attractive due to installation simplicity for final users, but at this time I've discarded it: I'm not knowledgeable on the MIPS architecture, but most important, it can be achieved only via a trial-and-error process which is impractically slow (the firmware upgrade takes ages). So I'm working in a solution that taps into the boot process right at the beginning. The difficulty here is that the original firmware first stage is also very picky and doesn't work even after minimal hardware initialization, so I need to replace it by a code that checks the boot selection and chainloads the original firmware first stage, all without even initializing the SDRAM (which means you're running on the instruction cache, which is only 16KB). > Is it possible this might never be achieved? I don't think so. I'm almost 100% sure dual boot can be achieved in the very short term. It is just a matter of time, because as I said earlier, the only way to debug and get it working is via a painful (but fortunately quick) trial and error process. > Is this issue a priority for you? It is #1 priority, though as you know I've spent some time working on the sound driver and other things. It's just that sometimes when you just can't get something working, it's better to switch to another task for a while. > How many man hours of work do you think might be involved to achieve this? It's hard to say because when you do reverse engineering by definition you're getting into unexplored territory and you don't know what you'll face. That said, I've spent already a lot of time studying the original firmware boot process and would say that I'd only need a couple of days (say 16 man-hours). However, as you can imagine, I can't work full time on this (have a job and a family) and it might take one or two weeks actually. But again, don't hold your breath. I insist that I cannot know what roadblocks I'm yet to face. > What specifically could Shenzen Dingoo Digital do to assist? (Pretend for a moment that they were willing to help.) Provide the schematic of the A320, or better yet (and less unlikely to happen), provide info on the GPIO usage. I asked them and they kindly answered that this info is not and will not be available. Note that most likely Dingoo has purchased a closed design from a hardware manufacturer, and I bet they don't have the schematics themselves. The firmware is also very likely to have been purchased from ChinaChip, which have access to the schematics or at least to the GPIO information. > You are also working on ALSA, fixing up Linux on the newer A320s (and succeeding!), as well as considering Linux on the Gemei 760.  Anything else you're working on? Have a look at the google code issue tracker. As soon as things get working, I'll go on working on hardware support  until we have at least the same functionality than the original firmware, and thus can replace it. > There's only 1 Booboo! Are you being stretched too far? Well... just a bit. I was in between two jobs when I started working on this project and was able to dedicate some serious hours. Now it's tougher but I feel VERY encouraged by all the support I've been receiving. It's very rewarding. I know I can't do everything. I wish but I'm realistic and I know I can't. But I was pretty sure I could at least jumpstart it by providing a practical way for others to join, and I guess I've succeeded so far. > Despite the lack of 3d hardware, would playable PS1 or N64 emulators ever  be possible, if Linux for Dingoo was optimised enough? I'm not an emulator writer myself, but I think the A320 is far from having enough power to emulate PS1 or N64. > You have a day job, and I imagine, a full life (you are 37, after all:)). What drives you to toil away at Dingoo Linux? I enjoy electronics, programming, challenges, and learning. That's it. In addition, I knew about the A320 when I was in between jobs, so I had time I could use and though it could be fun and jumpstart a scene. Now, though one could say I've become now an independent contractor, I cannot dedicate so much time, but lack of time is partially being compensated by motivation coming from all the encouragement and support I've received. Thanks!. > PS: we are the same age.  What a coincidence! Yes! > Booboo, thank you for taking the time to answer these questions. The Dingoo community is behind you every step of the way. Thank you.