Sunday, May 31, 2009

Dingoo Firmware Doom GBA vs Linux Doom Prboom

Here is a comparison between Doom running on the Dingoo GBA emulator:

vs Doom running on Joyrider’s Prboom port:

Why bother with Linux? The videos speaks for themselves!

Saturday, May 30, 2009

Where we are with Dingoo Linux: WTF is a kernel?

Someone a few posts down asked: what is a kernel? There’s nothing here that a quick Google and lots of hours spent immersed in the jargon of software architecture won’t also yield, and better, but in an attempt to save you the trouble, here I go (just don’t expect to actually learn too much!). 

A picture says a thousand words.  Our friend Wikipedia has this stuff on it:

In computing, the kernel is the central component of most computer operating systems. Its responsibilities include managing the system's resources (the communication between hardware and software components).[1] As a basic component of an operating system, a kernel provides the lowest-level abstraction layer for the resources (especially memory, processors and I/O devices) that application software must control to perform its function. It typically makes these facilities available to application processes through inter-process communication mechanisms and system calls.
So, a kernel connects the application software to the hardware of a computer:

A typical vision of a computer architecture as a series of abstraction layers: hardware, firmware, assembler, kernel, operating system and applications:

The kernel's primary purpose is to manage the computer's resources and allow other programs to run and use these resources.

Typically, the resources consist of:

  • The Central Processing Unit (CPU, the processor). This is the most central part of a computer system, responsible for running or executing programs on it. The kernel takes responsibility for deciding at any time which of the many running programs should be allocated to the processor or processors (each of which can usually run only one program at a time)
  • The computer's memory. Memory is used to store both program instructions and data. Typically, both need to be present in memory in order for a program to execute. Often multiple programs will want access to memory, frequently demanding more memory than the computer has available. The kernel is responsible for deciding which memory each process can use, and determining what to do when not enough is available.
  • Any Input/Output (I/O) devices present in the computer, such as keyboard, mouse, disk drives, printers, displays, etc. The kernel allocates requests from applications to perform I/O to an appropriate device (or subsection of a device, in the case of files on a disk or windows on a display) and provides convenient methods for using the device (typically abstracted to the point where the application does not need to know implementation details of the device).

The Linux kernel is of course very mature, can work an lots of hardware, and appears to live here. But obviously, you can’t just download it, stuff it onto your Dingoo and have it go. Booboo’s main challenges when building the Dingoo kernel (I seem to recall from previous posts) were getting the LCD screen, GPIO, and sound working. (Clarification welcome!).

What goes into getting Linux kernel working on specific hardware like the Dingoo? I’m really not sure, but one can a sense of what’s involved in rebuilding the Linux kernel – and getting it to work with specific hardware -  here.  If your appetite has been wetted and you’re keen to make Linux for your toaster or something, you might find the Linux from Scratch project interesting. Or download and read the book.

The above is nothing more than a cursory glance at the concept of a kernel. It does emphasise how fortunate the non-tech among us of the Dingoo community is that as of today, we can simply click here to get a working Dingoo Linux kernel.

Booboo posts updated Dingoo Linux Kernel

Booboo has updated his linux kernel. Get it here:

The label says this: Linux kernel, fixed 8 bit sound mode, keymap changed to mimic GP2X .

From the Spanish GP2x forums:

The problem with the audio one in 8 bits.


I finish correcting it. The code of driver of sound OSS gives miedito. It does not arrive nor at alpha. Ominous quality, shoddy work and errors by a acojonante tube….
Also I have changed the one of the keyboard. Now soon I hang in google code new a binary one of kernel (the code in repositorio svn, obvious). You could verify that the keyboard map now is correct.
Please good test the subject of the sound because it has been hung to me once. Only one, and I has not returned to happen, but you observe any rare thing, I occurred it.
Another thing: you could try what so the gain control works. It is only necessary to compile some utility that allows to modify mixer of OSS. I say it because a gain control like so does not exist, and what it becomes it is a displacement to the right of the bits of the samples.
In addition, now I decide to me, the gain control will not work in the way of 8 bits. When adjustment has it awhile.

Friday, May 29, 2009

New Prboom video – all running smoothly!

Well done joyrider!

Dingoo meets its Doom

joyrider stays up late once again (this explains why his videos are always quite dark:)), and look what he made:

Discuss it here. Props, joyrider!

BTW: What’s prboom? It’s an extremely faithful Doom emulator.  Read about it here:

Thursday, May 28, 2009

More on toolchains … from Booboo!

Booboo sent me the following; thanks Booboo:


I think I can add some clarification to the toolchain concept. Your
post is not technically wrong but is a bit misleading.
In a programming context a toolchain is the group of tools needed to
write a program. If the program is interpreted (Python for example)
the toolchain would include a simple text editor used to create the
program and the runtime environment (the Python interpreter and
libraries) for the target system. If the program is compiled (C, C++),
the toolchain usuarrly refers only to the compiler, linker, some other
auxiliary tools and a minimal set of libraries needed to build basic
programs (libc in linux).
Toolchains can be "native" or "cross". A toolchain "native" runs in
one platform and produces code for the SAME platform. This is the case
of the gcc/ld and friends found in most linux distributions. A cross
toolchain runs in one platform (PC) but produces code and executables
for a completely different platform. This is the kind of toolchain we
need for A320 programming. The programs compiled with this toolchain
cannot be run in the PC, must be transferred and executed on the A320.
That said, Ingenic provides a FULL WORKING toolchain for the JZ4740
processor which is usable for the A320. This toolchain includes the
most basic libraries (libc, for example) and some other useful
libraries. I compiled some others like the SDL which are not included
in the Ingenic toolchain but are almost mandatory if you want to
program games and emulators.
The Ingenic toolchain together with some extra libraries is all we
need right now to compile programs for the A320 (well, that and a
linux kernel supporting the hardware).
What about the uclibc toolchain?
Well... the Ingenic toolchain is based on the libc library. This is
the very foundation of each program and is VERY large because it
supports every function needed in a linux desktop or server system. As
a consequence, this is a quite large library which consumes lots of
memory. 4MB is nothing in a modern desktop but is a quite sizeable
chunk of the A320 available memory.
So, there is an alternative "base" library called uclibc. As the name
suggests, it s a libc optimized for size and resource usage, that
doesn't include advanced functions which are usually not needed in
embedded systems. We cannot just replace the libc in the Ingenic
toolchain by a compiled uclibc, because this base library (libc or
uclibc) is so tightly bound to the compile process that a compiler
will work only with a base library, but not with the other. Or better
said, a gcc-libc compiler will produce executables that will only run
in a system which has the libc, and a gcc-uclibc compiler will produce
executables that will only run in a system which has the uclibc in the
root filesystem.
That said, I must insist that getting a uclibc based toolchain is an
OPTIMIZATION, not a requirement in order to get a working linux on the
A320. As of now, coders can build and test programs for the A320, and
we could eventually just go with the libc based toolchain provided by
Ingenic. However, having and using an uclibc based toolchain would
allow us to squeeze up to the last drop of power out of the A320.

It’s all starting to make sense!

Where we are with Dingoo Linux: WTF is a toolchain?

There have been many references to this word “toolchain” since Booboo posted his Dingoo Linux information on Google code.  But what is a toolchain? Wikipedia is your friend:

In software, a toolchain is the set of computer programs (tools) that are used to create a product (typically another computer program or system of programs). The tools may be used in a chain, so that the output of each tool becomes the input for the next, but the term is used widely to refer to any set of linked development tools.

A simple software development toolchain consists of a text editor for editing source code, a compiler and linker to transform the source code into an executable program, libraries to provide interfaces to the operating system, and a debugger. A complex product such as a video game needs tools for preparing sound effects, music, textures, 3-dimensional models, and animations, and further tools for combining these resources into the finished product.

Here’s a good representation of the toolchain concept:


To my untrained eye, it looks like we want to get to “Solvers” on the right – the diagram represents how the various programs/data interact to get us there.

Here’s another diagram illustrating the concept of a toolchain:


From the source site: “The figure depicts the complete XMLVM toolchain. Each of the boxes represent an artifact while the arrows denote the various transformations between those artifacts. The input to the XMLVM toolchain is either a Java class file or a .NET executable.  …. First, we describe how a .NET application can be translated to XMLVMJVM. Next, we discuss how XMLVMJVM can be cross-compiled to JavaScript to generate AJAX applications. Note that with the front-end it is possible to generate AJAX applications from Java or any of the .NET applications. The final use case we present here is a backend for Objective-C which effectively allows Java applications to be cross-compiled to native iPhone applications.”


From the official Linux development thread, we can understand these posts from the A320 freeforums much better. As far as I can work out:

1. the toolchain is required for developers to run on their local Linux PC, to generate new … apps/other programs? … which can actually run on Booboo Linux;

2. at the moment, while ezelkow1 has done significant work on a common mobile toolchain which everyone can reliably use, we’re still not quite there yet.

No reliable toolchain = no common and simple tool to port apps. Ainu, for instance, has had many problems attempting to compile new programs using the existing toolchains.  I find it hard enough remembering how to find “My Documents” from the C:\ drive in Windows explorer sometimes, so Ainu, I very much think I can feel your pain!

Knowing what I don’t know, I suspect that more than a toolchain is needed as well before we really get deluged with good stuff, but the point is we don’t even have this essential tool(chain) now! A journey of a thousand steps, as they say … begins with a single kernel, and then a toolchain …. and then, probably other stuff, but one thing at a time, for now, it’s we need toolchain, toolchain, toolchain.

Fortunately, it does appear that ezelkow1’s work over the past week or so has really pushed things along, and hopefully a good mobile toolchain will emerge shortly. I believe this is the link to ezelkow1’s last posted toolchain: (see ezelkow1’s comment)

Stay tuned for more!

Tuesday, May 26, 2009

joyirder3774’s Waternet running on Dingoo Linux

Look here: something else to run if you manage to go through the magic incantations, summon the Dread Dormammu, invoke the Vishanti and by the Hoary Hosts of Hoggoth, actually successfully install Dingoo Linux!

Rejoice, for joyirder3774 has irded his loins (and we are joyful), and compiled his GP2x Waternet game – looks like a Pipemania clone? - for Dingoo Linux!

Discuss it here.

Sunday, May 24, 2009

Save the planet - one Dingoo at a time

emusan has posted a proposal for a solar power charger for the Dingoo. Read about it here:

ezelkow1 posts kernel build, ucfctoolchain and rootfs

From the Official (and porn free) Linux development thread on the A320 freeforum:

Re: ** The Official Linux Development Thread **

Postby ezelkow1 on Sat May 23, 2009 11:51 pm

Ok, uploaded my kernel build to:
tested and it boots up fine
Uploaded my rootfs to:
I did have a few errors when tarring up the rootfs, but it looks fine to me, everything boots up fine. Do you have the options you used to build sdl_gfx, want to get that in so I can try to build gmenu with uclibc
I will upload the toolchain in a bit


uploaded the initial uclibc toolchain:
so with this and the previous kernel patches you should be able to do some basic development with uclibc. I have some newer versions of this and the root fs but they still have to be tested, add flac, madplay, and a few more libs.
Initially they look good, but i hate having to always tar up the root from my dingoo since I always have to edit the files in /etc to be able to get in over serial. i can upload the generated rootfs.tar file, but then you should keep many of your inittab, passwd, files to be able to still login

It is good to see booboo is not alone. I wonder how many more people are out there beavering away on Dingoo Linux? Speak up!

Saturday, May 23, 2009

Dual boot information posted on Google Code

Booboo has posted some information and thoughts on dual boot. Find it here.  The problems in the way of dual boot are stated: can anyone help to solve them?

Friday, May 22, 2009

SiENcE’s Dingoobench 0.1

Benchmark your Dingoo! Get it, discuss, and post results here:

Is this a PSPingoo?


From whence all the treasures of China hail, comes another Dingoo wannabe, or maybe a Dingoo notatall.  No reviews yet, but keep checking back … you never know – it might actually work. To while away the hours while Linux development progresses, click here if you want one.

Thursday, May 21, 2009

GPIO usage summary posted

Booboo posts a summary of GPIO usage here. opens – Discuss Booboo Linux there!

There are simply not enough dingoo forums around, of course, so I’ve set up another one, in response to a discussion thread on the Spanish GP2x Boards, where they asked for a dedicated Booboo Linux forum site. Welcome all to !

At the moment, it’s about as busy as a one legged man at a bum kicking contest.  However, I’m hoping it won’t be too long before guys like these appear:


There is only one forum on it at the moment – but feel free to let me know how else we can help.

Wednesday, May 20, 2009

flatmush posts homebrew Star Lander Game


Get it here.

eksasol’s frame/speed test video

ekasasol has posted a great looking video on Youtube, and after you watch it, you’ll be wondering why we need Linux at all:). Let’s not forget why the Dingoo is where it is today – the original firmware, for all its flaws, does work, and pretty well.

robocop’s Metagames review

A comprehensive French review of the Dingoo can be found here (or here, for the original).  It’s so … oh, 10 May 2009 … but still makes good reading if you’re new to the scene. If you don’t like it, talk to the hand.


GP32X adds Dingoo sub-forum

Huzzah! Not long after the triumphant return of GP32X comes the addition of an A320 specific area on the forums. Everyone should thank EvilDragon for setting it up and get to posting!

Sunday, May 17, 2009

Booboo Linux clarification

Another pulse racing video!:

However, Booboo would like to clarify as follows:

"It's not going to be a "release" understood as a more or less finished
work. It's just a way of saying that I will be posting all the
information and all the work I've done.

In fact, I just haven't done it before because I was too busy and so
excited that I didn't want to lose time organizing and publishing the
info. Now that all the basics are working, I've reached a milestone
where people can actually program under dingoo linux, and it's time to
dedicate some effort to publish all the info, so others can advance in
parallel with me towards a full firmware replacement.

Once what I have now is available to anyone, I intend to:

1- Make dual boot work.
2- Complete hardware support.

Dual boot is not necessary for programmers (which can develop using
USB boot) but is for users, so it will be soon required after
programmers start releasing programs for dingoo linux.

So, I'll focus on the kernel and let others build the user space
programs: firmware menu and emulators and whatnot."
Once the material is up on Google Code however, I'd anticipate lots of activity. Just don't necessarily expect on day 1 files which can be installed and launched on the Dingoo without some level of tech savvy. Browse around Google Code and you should get the gist of what the site is about.

This, of course, should not be allowed to detract from what Booboo has singlehandedly done here!

(Also, I hope someone tells me what to do when the stuff is on Google code:).)

Dingoo file repository opens (Not near Texas, or Grassy knoll)

Check it out here:

Booboo Dingoo Linux: 2 seconds to lift off


Booboo says:

Status update:
- video + sound + keyboard working.
- SDL working, madplay working (20% CPU with a 192Kbps stereo MP3).
Have a look:

More very very soon: Booboo intends to post it all on Google code. Watch out for it!

joyrider, without irony, releases Formula 1 game!

Those of you hankering for the good old days, when hires meant better screen overlay art, will be overjoyed that joyrider has ported his “Game and Watch” Formula 1 game to the Dingoo, over at


Download here and more details are here. Thanks joyrider!

flatmush releases Minesweeper

flatmush has released Minesweeper on the Openhandheld dingoo forums:

Here is a minesweeper game that I've made for the a320.
The controls are:
- The D-Pad moves the cursor.
- A uncovers a tile.
- B marks a tile.
- Select takes a screenshot.
- Start exits.
The playable game is available here:
The source code is available here:
This is probably more use as an example of how to make applications without using the s2dsdk, it contains enough functions to get anybody started in a320 programming without all the useless bloated sdk code.
Edit: If you downloaded before 02:19 17/05/2009 GMT then re-download since the level 4 crash bug is now fixed, was due to my rand function not being random enough.

Saturday, May 16, 2009

Official Shenzen Dingoo Digital Firmware A320 update v 1.1

Amidst the growing excitement over Linux, Homebrew and whatever else, it’s easy to forget that the manufacturers also have a say in things.  A new version 1.1 firmware has been released on the official Dingoo website: grab it here (It’s the first item on the list of downloads).  Unfortunately, no Y/B button fix appears apparent from the text file which accompanied it:

This firmware version shows as V1.1, the language functions in an increase of Japanese, Korean, Russian in three languages, upgraded A320
     Built-in language is Simplified Chinese, Traditional Chinese, English, Japanese, Korean, Russian, six, to facilitate the use of players around the world.
Small fruit Digital:

A320 firmware upgrade steps:
1. Connected to the computer's USB line, the A320-extracting machine A320.HXF the root directory (can be overwritten A320.HXF old files)
2. Election security from the USB device, disconnect the USB line.
3. Shutdown.
4.十字键Hold down the down button, and then boot.
5. (If you have just copyed into the A320.HXF version than the updated version of the machine) machine will automatically begin the upgrade.
6. After the upgrade to the A320 can loom "Settings" directory in the "About This Mac" to view the corresponding firmware version. 

Although, it is positive that Dingoo is selling well enough to the Japanese, Koreans and Russians to warrant an official firmware update:)

Time for a Dingoo-Scene tart-up?

Now seems as good a time as any to start thinking about a critical question, at this stage in the life of this blog.  As you know, we are always keen to listen – and especially if you provide the html coding:) – even implement, all decent suggestions.

Consequence9 has spent a lot of effort and energy designing this logo:


I’d have to say that it’s very well done, and the work Consequence9 has put in is very obvious – but it’s not my cup of tea.  The whole graffiti aesthetic, well, it’s not me, or the Dingoo, I don’t think.

But, as this guy might say ….


… you need to ask yourself a question:

Do you like it?

Hate it?

Do you think you can do better? (And if you can, send it to me, I’ll put it here for consideration.)

Would you prefer to stick with the elegant minimalistic irony captured by the stark simplicity of the existing Dingoo-Scene banner?

Or do you think we should stop acting like little girls picking their favourite My Little Pony, and learn to do something useful like work out how to dual boot Linux? :)

Pipe up!

BTW: Consequence9’s picture makes great wallpaper, if you like the look:


When it rains, it pours … CraigX update on Atari ST and MAME

From the openhandheld forums comes another tantalizing tidbit:

Watto asked:
Craig, any news on Mame, Atari & Amiga, coming to the Dingoo !

CraigX (13 May 2009):
You will be seeing mame and atariST later this month!

flatmush posts C99 World sample without s2dsdk

Over at the A320 freeforums, flatmush posted the following:

This sample shows you how to compile C programs which directly access the frame-buffer and controls, so that you don't have to use the s2dsdk. This gives you full control of the machine so be careful, I still have things to work out but for my first day with an a320 I think it's pretty good.
If you look at the code included with all the other samples most of it is unused bloat, from other PMP's, my code is a fraction of the size and simpler to understand.
Download the sample from:
Once you run the sample it will simply change the color of the screen dependent on what buttons you press.
Any questions?
Tomorrow I will upload my software graphics library so that we can get some proper games running, hopefully astro lander by the end of the week from me.

Good one; thanks flatmush!

Booboo Linux - keys done!

From the Spanish GP2x forums (untranslated link here), it’s clear Booboo hasn’t been idle this Friday night:

I finish implementing the keyboard and what I have done it is not to warm up the head to me and to use the mapeo of keyboard of the SNES9X:
D-DAP: you shoot with an arrow
Button A: “d”
Button B: “c”
Button X: “s”
Button and: “x”
Button left shoulder: “to”
Button right shoulder: “z”
START: to enter
SELECT: space
If somebody has some better suggestion, please it says than it.
For the subject of the volume of audio and the retroiluminación of the screen me a pair of things has been happened and also it would want to hear commentaries:
In both cases his it is to implement these functions in drivers corresponding. This is very well for a system of escritiorio but it seems to me that very it is not adapted for the Dingoo. I explain myself:
The implementation in drivers provides a standard API so that soon the programs of usuary way do what they create advisable. When one has a graphical interface X this one manages the keyboard so that when the special keys are detected to raise/to lower volume and retroiluminación are sent to an application makes specific that she is the unique one that speaks with drivers and that it makes the adjustments pertinent. So that all this works must have an organization that manages the keyboard soon and distributes inputs (x) and to make an application that is in charge to manage inputs of those special keys that X commands to him.
But in a320 we do not have manager X, and each application will read inputs directly, so to not having a “intermediary” who redirige to different applications we cannot have an application of user in background that is in charge of the volume and the retroiluminación. In any case already you know that it interests to have the minuses applications running at the same time, not to consume memory. The circumstance that in a system with as rigid hardware occurs in addition as it is a320 we know very clearly from right now how they must work the volume as much as the retroiluminación.
What I have thought is, instead of to manage those functions from drivers corresponding to directly do it from driver of keyboard GPIO. Of that form, Independent of the fact that application is running one could modify the volume and the retroiluminación using a special combination of keys.
Also in this respect I would like to hear opinions exceeds what combinations of keys would be most suitable for these intentions. I have to confess that I have not gotten myself to read nor the manual of a320 so nor how does not become in the emulators of firmware original, but it gives equal me because how does firmware not necessarily original it must be most advisable for the user (that or we know how they are the Chinese).

Friday, May 15, 2009

Dingoo Linux so close …


Here’s an excruciatingly exciting update from Booboo on Linux:

Status update:
Sound is working. Turns out that the ALSA support in the Ingenic
kernel just doesn't work. OSS does, though the implementation is a bit
buggy the sound quality is not affected as far as I know.
I just need to get the keys working and we'll have miniSD + video +
sound + keys, just enough to play emulators and other apps, as long as
one doesn't mind booting into linux just for that and resetting when
finished to get back to the original firmware. Using linux as a full
blown firmware substitute won't be possible until the rest of the
hardware is supported.
Key support is trivial and I'm sure I'll get it working this weekend.
At the moment the only way to boot linux is by using the USB boot
mode, so a host PC is required. As you know I spent quite a lot of
time trying to tap into the original firmware boot process, but got
stuck with the TLB exception issue.
I'll try to figure out an alternate way to get dual boot working.

If Linux slips out this weekend … ah well, looks like I might have to return those Eurovision Song Contest tickets.

Thursday, May 14, 2009

SiENcE’s Dingoo Video Codec Performance analysis

The amazingly … patient …. SiENcE has produced the definitive analysis of how well the Dingoo manages just about any video files you might care to throw at it here.  The Dingoo’s ability to handle video files generally without re-encoding is truly unparalleled for a device of this type.

Thank you SiENcE!

Picshow 0.3 was released a month or 2 ago

Download from here. Information:

Current version: v0.3
JPG, BMP Supported formats: JPG, BMP
7000*6000 (BMP) Maximum size: 7000 * 6000 (BMP)
5000*4000 (JPG) 5000 * 4000 (JPG)
Button Description:
Arrow keys to move the image, A zoom button, B button to narrow. X and △ key to switch images.
Combination of keys
POWER + LEFT Fit to width
POWER + RIGHT Original Size
POWER + UP for a high degree of
A + B rapid switch scaling (for the width of the original size, suitable for a high, 50%, 25%, 12.5%)
Installation Method:
PicShow.SIM documents will be copied to the small machine GAME directory, enter the small machine "Classic Game", select the image files to open depend on you.
Update Description:
v0.3 v0.3
1. In support of more than 20 million super-resolution display
2. Default zoom level to adapt to the screen changed to a high degree of
3. Dynamic display loading image
4. Shortcut keys to switch scaling
v0.2 v0.2
1. Amendments to narrow the image display tilt error
2. The amendment to reduce unnecessary screen image below shows the error
3. Amendments to the far left appears to enlarge the image shows an error
4. Information be changed to semi-transparent
5. To amend parts of JPEG image loading errors of Death
6. Join the fast-switching image features
7. Limit the scope of the image moving
8.'s Accession to the effect of sliding
the initial v0.1 release, support BMP, JPEG image viewer, support for non-class scalability.
v0.3 support for the resolution of the scope can be as high as 40 million pixels (bmp format), JPG format for the current support to 20 million pixels.
40 million pixels as BMP picture has been the need for the 160M memory space, so small in the load 7 has revealed that the picture will take a very long time, but he will certainly be able to display and can view the original ratio.
As the cpu speed, I did not use the complex scaling method, the relatively poor quality, but 100%, 50%, 25%, the proportion of 12.5% ... and so on, the picture quality is very high. You can use shortcut keys A + B switch these types of zoom mode.
As measured, 15 million pixel digital camera picture can be a normal open-megapixel .3000 of a world map (BMP format) can also be opened to normal.
At present, bmp to support greater than the jpg, I would like to look at the map with a friend, it is best to save it as a bmp format images.
have fun, program is by Landlord

Tuesday, May 12, 2009

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



SP: 81EAAA28


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.

PIE320 0.1 Namco Pacman Emulator released – thanks Seagal

Seagal has released his PIE320 0.1 Pacman emulator!  Download and discussion here.


joyrider releases Rubido homebrew game!



joyrider has ported Rubido from the GP2x over to the Dingoo – grab it here from the A320 freeforums.



Thanks joyrider!

Wonderswan emulator updated again

Another day, another update top Jorghej’s Wonderswan emulator.  Grab it here.

Jorghej says:

I request excuses by the errors that did impossible to play in version 0.3. Corrected the majority of them already it is possible to be played the engaged games. Also the execution has been accelerated considerably deshabilitando the file of log as they recommended to me and excluding certain files in the compilation (files used in some tests).

I also asked Jorghej the following question:

Hello Jorghej, Would it be very difficult to do what you have done with the Wonderswan emulator, and produce a port of Frodo, or another C64 emulator?

His reply:

I do not think is much more complicated…

Linux or not, the future looks bright for Dingoo emulation. Jorghej, how can we get you to work on Frodo? Can we take up a collection and send you dancing girls, gold bars and small islands?

Monday, May 11, 2009

Wonderswan emulator 0.3 released

Props to Jorghej for releasing v0.3 of his Wonderswan emulator.  Grab it here!


Jorghej, good on you for not slowing down your work on this emulator.  It seems to me that after a flurry of homebrew activity 2 weeks ago, the considerable progress on Linux could have slowed things down a bit – are developers waiting for Linux before investing more time into this machine? But as Jorghej shows, there is no need to wait for Linux to be released before working on homebrew! 

Don’t forget there are links to Wonderswan birdfood here.

Saturday, May 9, 2009

Friday, May 8, 2009

ThaCobra’s Wooden “Gpeter7 debugger” Cradle

With these plans, you too can have your own Gpeter7-ish cradle.  Make it out of ancient Oak, and it’ll look good in the best boardrooms. Read more here:


Technorati Tags: ,,,,

Wonderswan emulator v0.2 file found by Bingo83!

For those of you trying to find a Wonderswan emulator, give Bingo83 a big hug at the A320 freeforums:



Our friends over on the Chinese A320 forum have found a Wonderswan emulator V0.2 that works on the Dingoo.
Just extract and put the .SIM file in the usual place and ensure your roms are labelled .WS
The emu doesnt find .WSC roms at all (yet).
I tried Loderunner which ran full screen if a touch too slow.
You can try it for yourself

There are links to Wonderswan birdfood here.

For more information about this emulator, go to Jorgehj’s site here:

Props, Jorgehj!

so9 posts beta HXF tool for firmware

From the A320freeforums:
Hi to all
the first beta of my hxftool is ready for a few tests
- integrated hex-viewer for single files inside the hxf-package
- change bootscreens
- change a few default settings
- language editor for english-texts
- some automatic patches (including the td-mod)
it's straight forward to use. simply open a hxf-file and change whatever you want. there's no need to use an unpacker. everything is done online so backup your hxf-file (just in case). i'm a little bit out of time maybe someone can write a tutorial?
if all this bricks your dingoo look here ... icker-tool

Booboo Linux Q&A update

More Booboo Q&A from the Spanish GP2x Forums (untranslated link) (all this, and he has time to code too … cheers Booboo!):


Originally Written by they chipan To see Message

Ah, then is that you had not read me XDDDDDD
As far as which you say of throwing the main surroundings/of applications; I believe that the Gmenu2x could be carried (I suppose that there will be source code available or if cannot be asked the author), is a pretty very configurable alternative and with a really small consumption of resources.


Indeed, the source code is available. It seems the best alternative.
I yesterday made a fast attempt with the sound was used that me for, of entrance, knowledge that support OSS of kernel of ingenic does not work (great petada when you accede to the device), so debate OSS (“legacy” but more compact, does not support audio simultaneous of several applications, something that in a320 is not problem) versus ALSA (default to day of today, heavier, audio simultaneous) is already trenched. Now I have to make work ALSA. I have already compiled libid3tag, libmad and madplay for a320, but I have some problem with the bookstore libasound that I suppose that I will solve quickly as soon as it has time to seat to me with a320. To see if soon I can hang a video of madplay reproducing mp3.

< - >

Originally Written by Uncanny To see Message

Thus it is pleasant (and envy, it heals, but envy xD), thanks booboo to make and instructive east so interesting thread a doubt with respect to this point del that you speak this would be thus even although you form kernel it compiles so that it like module and it loading under demand, that is to say, when the USB is connected to use it in way CDC Ethernet? I ask it because if outside thus, like module, I suppose that there would not be problem, although you say if it because there would be to work almost necessarily with kernel monolithic Linux (as I suppose that you are doing now) then if that would be problem the extra consumption of ram to compile the support of network of kernel.


In principle there is no problem in using modules in kernel. There are two options, or kernel is had minimum that takes initrd interlocked that loaded the modules necessary to accede to the support where he is rootfs mounts, it and does pivot_root, or monolithic has kernel minimum but with those compiled modules. Second he is simpler, and in addition first it does not have sense in surroundings where the starting options are practically invariant.
IT STICKS it is that to qualify the dynamic load of modules already kernel in 300K gets fat (of code, plus the necessary ram that I imagine that will not be much). To that súmale others 300K of code more enough ram for the minimum support of network.
To be loading modules in a system like a320, where hardware is invariant and “hotplug” are no events, does not have sense except for development. For that reason I am in favor to have kernel most compact and light possible. Nevertheless, that complica the development of drivers hardware and cuts the communication via Ethernet, reason why I believe that the best option is to have a starting system that allows to select to a) firmware original, b) kernel normal c) kernel development.
I am going to begin to work OR in firmware original modified so that instead of to load ccpmp directly it loaded u-boot and this one can as well send firmware original or kernel/rootfs in miniSD. I believe that ma has happened a form to make it quite simple and that would settle like anyone of firmwares “custom” which they have left already.

< - >

Originally Written by Nekete To see Message

A cochair, it has seen somebody if there is some reason of hardware by which the problem of bellboys B/Y exists?


Ah! … I verified the subject but one forgot to me to comment it this way.
It is not a hardware problem. Hardware can perfectly read and of totally independent form both bellboys. In fact there is a pin GPIO dedicated for each button of independent form.
Therefore bug is a puñetero. And in addition I dare to venture that it must be bug idiot and very easy to fix, but already you know how they are the Chinese for these things.

< - >

Originally Written by juanvvc To see Message

To only contribute my sand granite in this: in many consoles the keyboard (joypad, bellboys) is mapping not to a normal keyboard but to a device joystick permanently fitted to the console. If it beams thus it will be easier to carry the emulators of other portable consoles that already are preparations to read of joystick.
Of all ways, to change in the emulators “reading of joystick” to “keyboard reading” is not nothing difficult. If it is easier you to mapear the bellboys to a keyboard with less keys than to joystick, since those are the programmers of emulators that work


Interesting idea. It did not know it. Pelín than the one of the mapeo of keys would cost to me more because Ingenic already provides to driver for this, whereas I would have to do the one of joystick (that is simple in any case).
Nevertheless, unless there is something escapes to me, it gives me that the one of the keys is practitioner more, since absolutely All the emulators must have support for keyboard, whereas perhaps there is some does not have support of joystick. On the other hand it is happened to me that in the emulators always it will be necessary to be able to reshape the mapeos of keys to taste of the user… can be done this with the bellboys of joystick? (I have not used many emulators, and never any with joystick).

< - >

Originally Written by SinMan To see Message

Your that you know booboo, as he would be of heavy using sw_suspend and like of useful or useless?
Perhaps it is not possible, or even that it is only a fast pair of seconds but that a normal starting, I ask for that reason it.


IT MUST be possible, simply because firmware original does. Another thing is that he is complicated to explain how works the hardware or that the function of suspend well is not implemented in some of drivers of Ingenic (this is what more fear gives me). In any case all this is solventable in time and patience.
As far as its utility, firmware based on linux that REPLACES firmware original MUST implement the function suspend. Although only behind schedule 5 seconds in loading, it is an eternity compared with the instantaneous answer of suspend.

< - >

Originally Written by juanvvc To see Message

Good, in fact it thought about games and emus of the Gp2x, where as much the SDL as minilib anyone mapean the controls like joystick
In any case it is truth that from the point of view of the programmer practically gives equal a form or the other. But mapea like joystick, the programs of the Gp2x will be easier to carry


What so a simultaneous and/or configurable mapeo. It would not suggest it if the one of joystick did not seem to me, a priori, relatively simple to do.

Originally Written by SinMan To see Message

Male Joe if they touch euromillones to me, tomorrow I subsidize to you
Good, to the mess, the one of which did not have RTC I suppose that it misinterprets what I read, and they talked about to that it does not have HW to control the rest of the machine when is dull, that is to say, that you put an alarm and every day to the 8:00 A.M. the single console ignites and begins to reproduce a MP3 for example since they make many moving bodies.


Than I put in datasheet I interpret that the JZ4740 yes that has that function. The problem is auxiliary hardware. I explain myself:
I have not put to investigate thorough how module RTC of the JZ4740 works, and am not going to do it at the moment, so I will speak of the experience that I have about how they work this type of devices in many other microcontrollers:
- the RTC comprises of a separated dominion of feeding of the rest. If the turn engineer made all good, he continues working although the rest of the CPU is in halt (fed but consuming very little). In many micros it is even possible to clear the feeding to the rest of the CPU.
- the RTC has an alarm function, thanks to which it can be programmed so that it does one of these two things (or the two): to generate an interruption or to change the state of an exit pin (this I have seen last one it VERY little).
- If what can do is the interruption, then the form to resume the system to one hour given consists of putting the CPU “to sleep” and that wakes up it to the interruption. Following the “deep thing” of the dream way this desperar it can be reset or a renewal of the execution it left where it. “Evidently at the most deep” smaller consumption is the dream.
- If what can do is to change the state of a pin, then with the help of little more than external transistors can be caused that the CPU has capacity for “going out” to she herself the feeding and “to reconectar it” using this special pin to the programmed hour. Evidently “to wake up” he is always reset and the consumption while “to duer to me” he is ridiculous, in fact only what consumes own module RTC.
Since already there am saying, this I have seen last one it only in very recent micros, reason why more surely it is than he is the other. In addition it requires since already there am this external hardware and a very careful design (that, without spirit to argue, is not habitual in the Chinese). And in addition that inherent “ridiculous” consumption to have the CPU without feeding absolutely is only necessary literally in systems that they must work whole years with a battery.
So I believe that dingoo surely will work of the first form. Of ota part, I am in favor ALMOST safe that dingoo has capacity for “taking off” to itself the feeding by software (*), and that you really extinguish when it the CPU is not fed absolutely. Also I am almost safe that or the RTC does not have capacity to activate the feeding or they have not implemented it. Therefore for your application of alarm a320 would have to be ignited (although in way of low consumption).
(*) I deduce it because there is a pin GPIO that is connected to the button of on/off, and because when you leave hung the console (that has passed me much while it programmed the initialización of hardware) the sliding button of extinguished it does not work (soon the dull one it is by software).


On the one of the interface, because as I said to you I do not have nor idea of embedded devices and which is high-priority to use the minimum resources, so my question is the following one, not to put the leg again.
If cojiera I jz-crosstools and mipseltools-gcc412-glibc261 of Ingenic, it could put to me to the future compile the SDL for linux of dingoo?


Yes. “Curro” would be mainly in:
- To suitably form the SDL so that it has only supported to framebuffer and alsa/oss (not yet which of both I will use in kernel… I believe that already I spoke of the subject in another message).
- To make the compiled cruzado: normally if what you are going to compile well it is done (and the SDL it is it) already gives some option you to specify the cross compiler that there is to use (specific the area code, that in this case would be “mipsel-linux-”. If no, you must trastear with the system of build. As I say, I do not believe that it is the case of the SDL, but cannot assure it.

it could also compile any application that used to framebuffer? or is better to take one directly debian-mipsel and to throw with binary precompiled?


Then I cannot affirm it surely, because until now everything what I have run in a320 I have compiled it I myself (busybox), but am almost safe (reference: linux for the VXnosqeué wave) of which any binary debian-mipsel will work. Another thing is that reason why it is interests to compile with special options binary at issue one (I am thinking about mplayer, in which it would include solely the support of framebuffer to thin it much, since it supports burrada of types of exit of video).

Originally Written by SinMan To see Message

As Stallman goes this way cuts the Webs to you, kernel but all the set of applications is called GNU/Linux, pásate by barrapunto and looks for flames on the matter


I know it I know, it… I have not wanted to sharpen so much.


I am afraid that he does not have RTC, reason why law the SOC does not have it integrated and you abriendo have not seen it any auxiliary chip for it, furthermore would be rare that having they had not made it an miser-application of clock


In page 6 of datasheet of the JZ4740:
RTC (Real Time Clock)
32-bit second to counter
1Hz from 32768hz
Alarm interrupt
Independent to power
To 32-bits scratch to register used to indicate to whether to power down happens for RTC to power
In addition in the configuration to kernel of Ingenic it appears clearly option RTC for the plate TURKEY (design of reference for PMP).
On the other hand, you can here clearly see the main crystal of the system (12 MHz) that serves as entrance to the PLL that generates all the other clocks (CPU, peripheral, USB, etc) and to part typical “latita” round of the crystals of 32768Hz which usually they are used for the RTC (in the photo I have put by error 32768KHz, must put Hertz or have put one comma between the 2 and the 7).


I have already seen that in the FTP of Ingenic to part of the GTK for X with Tiny X, they have a GTK-framebuffer.


You do not forget that only there is 32MB of ram, and that kernel of linux occupies enough (already I will try to thin clearing it all the nonnecessary one, but at least they will be 3 or 4 MB). Any application that we put will occupy more memory, and there is no swap (it would be possible to be had, but it does not have sense). To put a manager of windows and all the set of widgets of GTK does not have sense because they are thought to be used in a system with screen leader (mouse) and in dingoo obvious it does not have.
I believe that what touches is, once kernel good starting and has supported all the hardware, to develop “a main” application similar to which shows firmware original, and for that with the SDL on framebuffer surplus. In addition to have loaded in memory the SDL consumes resources but they would be resources that in any case would consume in any case the applications that sent (emulators, players, etc).


Originally Written by A600 To see Message

[A dual boot option] that would be, simply, cojonudo


By all means. But it will be necessary to wait for because before it comes all the others.
It had thought to look for the form “to from within send” kernel like one more an application of firmware original, but that can give thousand problems, since although it is not a good practice, often drivers initialize the devices doing certain presumptions with respect to the initial state of the same (that is to say, assuming that are as they remain after reset). In addition, it is the problem of how “to sobrewrite” in form memory “ordinate” firmware old by the new one, the configuration of the MMU (mapeo of physical memory to virtual) that I do not control and that does not desire anything to me to have to learn, the cache, etc. a mess, we go.
On the other hand, to take bootloader of ingenic and “to patch it”, although would be necessary to do it in assembler, are very very simple because it is only necessary to read a registry to know how the state of a then button and to change the name of the file that it loads (ccpmp.bin) and possibly the load direction, although as ccpmp.bin load in 0x80004000 and vmlinux (“the flat” image of kernel) in 0x80010000 would be enough with adding padding of 0x80010000 - 0x80004000 nops at the beginning of the image of kernel.
Fíjate that we are speaking simply to read a memory position, to examine a bit, and if the bit has a certain value of changing “ccpmp.bin” by “vmlinux” or any other name.
By all means it would be necessary to add to the file vmlinux in firmware, but that already we know that it is easy with at the moment existing tools (and that have allowed to remove firmwares altered).
The unique thing that does not like me of this approach is to have to alter bootloader in the flash, more than nothing because I believe that he is “contracted” in ccpmp.bin and therefore when updating firmware would be sobrewritten and been necessary to repeat the modification. I explain myself: I believe that the process of update of firmware makes something VERY similar to which I do loading kernel of linux: first load one or several small binary ones that initializes hardware since it would do bootloader, and soon load directly in SDRAM ccpmp.bin passing a parameter to him that says to him instead of to be loaded directly of the NAND by bootloader it has been loaded via USB and that must realise an update of firmware. Then what does already is to erase the flash, to put bootloader, putting to itself, etc. Something thus must be.

Originally Written by they chipan To see Message

Molan these so curradas answers, therefore I am soaked of knowledge thank you very much to leave it everything so clearly.
According to I have been able to read, to avoid kernel panic of the photo is something trivial… nevertheless to make work absolutely all the hardware can be a mammoth task


Mammoth it would be if besides not having the manual of the micro ones (we have datasheet, that does not explain how the peripheral ones work) we did not have software examples either. But we have kernel linux theoretically functional that only there is to form or to patch with the particularitities of a320.
He is complicated but perfectly feasible. In addition, an incomplete support of hardware in linux can be acceptable if it is possible to be had along with firmware original (to see messages on dual boot): for example it imagines that the radio FM and the exit TV do not work, but you have the SNES9X that works in linux: you start in linux and you play with one the best emulators of SNES than it has (or that has said to me), with the unique limitation of which you cannot hear the radio at the same time (I do not believe that nobody wanted to do it) and of which you cannot do it in the TV (what one is going away to him to do).

Thursday, May 7, 2009

Linux boot video – Text

Booboo says:

The video is taken from the dingoo booting a kernel configured with
framebuffer support and console on framebuffer.
The boot log text below is the dingoo booting a kernel configured without
framebuffer support and console on SERIAL port.

That said, the output in both cases is ALMOST identical. Differences:
1- In the framebuffer boot video you can see (or could see if it
wasn't that fast) the ingenic framebuffer driver initialization output
which is disabled in the serial console boot.
2- The framebuffer boot video ends at the login prompt (since there is
no keyboard as of yet, I still have to figure out how to connect it).
3- The serial console boot log goes a bit further and you can see how
I login, mount the miniSD and list the contents.


Uncompressing Linux… Ok, booting the kernel. 

Linux version - a320 (booboo@inspiron) 

(GCC version 4.1.2) #69 PREEMPT Thu May 7 03:27: 19 CEST 2009
CPU revision is: 0ad0024f (Ingenic JZRISC)
CPU clock: 336MHz, System clock: 84MHz, Peripheral clock: 84MHz, Memory clock: 84MHz
JZ4740 TURKEY board setup
Physical Determined ram map:
memory: 04000000 @ 00000000 (
Physical User-defined ram map:
memory: 02000000 @ 00000000 (
Initrd not found or empty - disabling initrd
Zone PFN ranges:
Normal 0 - > 8192
For Movable zone start PFN each node
early_node_map [1] activates PFN ranges
0: 0 - > 8192
Built 1 zonelists in Zone to order, mobility grouping off. Total pages: 8128
Kernel command line: mem=32M console=ttyS0,57600n8
Primary instruction breaks 16kB, VIPT, 4-way, linesize 32 bytes.
Primary data breaks 16kB, 4-way, VIPT, you would not ally, linesize 32 bytes
Synthesized to clear page to handler (25 instructions).
Synthesized Copy page to handler (44 instructions).
Synthesized TLB refill to handler (20 instructions).
Synthesized TLB load to handler fastpath (32 instructions).
Synthesized TLB store to handler fastpath (32 instructions).
Synthesized TLB modify to handler fastpath (31 instructions).
PID hash table entries: 128 (to order: 7, 512 bytes)
Console: colour dummy device 80x25
console [ttyS0] enabled
Dentry breaks hash table entries: 4096 (to order: 2, 16384 bytes)
table Inode-breaks hash entries: 2048 (to order: 1, 8192 bytes)
Memory: 28552k/32768k available (1987k kernel code, 4216k reserved, 476k dates, 1172k init, 0k highmem)
table Mount-breaks hash entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
Time: jz_clocksource clocksource you have been installed.
Total 4MB memory AT 0x400000 was reserved for IPU
yaffs May 7 2009 02:22: 41 Installing.
io to scheduler noop registered
io to scheduler deadline registered (default)
Serial: 8250/16550 to driver $Revision: 1.5 $ 2 ports, IRQ sharing disabled
7 • É¥ … ±á250: ttyS0 AT MMIO 0x0 (irq = 9) is to 16550A
serial8250: ttyS1 AT MMIO 0x0 (irq = 8) is to 16550A
loop: it modulates loaded
Nand DMA request channel 0.
NAND device: Manufacturer YOU GO: 0xec, Chip YOU GO: 0xd7 (Samsung NAND 4GiB 3,3V 8-bit) planenum: 4
Nand using two-plane mode, and resized to writesize: 8192 oobsize: 256 blocksize: 0x100000
For Scanning device bad blocks
Bad eraseblock 5 AT 0x0002ff000

Bad eraseblock 4240 AT 0x08487f000
Bad eraseblock 4267 AT 0x0855ff000
Creating 6 MTD partitions on “NAND 4GiB 3,3V 8-bit”:
0x000000000-0x000400000: “NAND BOOT partition”
0x000400000-0x000800000: “NAND KERNEL partition”
0x000800000-0x008000000: “NAND ROOTFS partition”
0x008000000-0x010000000: “NAND DATA1 partition”
0x010000000-0x020000000: “NAND DATA2 partition”
0x020000000-0x040000000: “NAND VFAT partition”
JZ SD/MMC card to driver registered
mmc0: new high speed SD card AT address b368
Freeing unused kernel memory: 1172k freed
mmcblk0: mmc0: b368 1948672KiB
mmcblk0: p1
Algorithmics/MIPS FPU Emulator v1.5
init started: BusyBox v1.13.4 (2009-05-06 23:51: 16 CEST)
starting pid 108, tty '': “/etc/init.d/rcS”
========== Mounting /proc and /sys filesystems
========== Initializing device infrastructure
kernel.hotplug = /sbin/mdev
========== Loading you modulate
========== Populating /dev/shm
========== Mounting to other Core filesystems
========== Setting up system parameters
sysctl: /etc/sysctl.
(none) login: root
login [129]: root login on “ttyS0”
~ # ls - /dev/mmc *
brw-rw---- 1 root root 179, 0 Jan 1 /dev/mmcblk0 00:00
brw-rw---- 1 root root 179, 1 Jan 1 /dev/mmcblk0p1 00:00
~ # to mkdir /mnt/flash
~ # mount /dev/mmcblk0p1 /mnt/flash
~ # ls - /mnt/flash/
drwxr-xr-x 14 root root 4096 Jan 1 00:00.
drwxr-xr-x 7 root root 0 Jan 1 00:00.
- rwxr-xr-x 1 root root 735819776 Jan 22 2009 akira.avi
drwxr-xr-x 5 root root 4096 Apr 27 2009 audiob~1
drwxr-xr-x 3 root root 4096 Jan 14 2009 dates
drwxr-xr-x 4 root root 4096 Apr 27 2009 images
drwxr-xr-x 3 root root 4096 Jan 14 2009 lifeblog
drwxr-xr-x 6 root root 4096 Apr 27 2009 music
drwxr-xr-x 2 root root 4096 Feb 10 2009 others
Dr-xr-xr-x 2 root root 4096 Jan 14 2009 pb
drwxr-xr-x 2 root root 4096 Jan 14 2009 playli~1
drwxr-xr-x 4 root root 4096 Jan 14 2009 private
- rwxr-xr-x 1 root root 213872 May 3 2009
drwxr-xr-x 4 root root 4096 Feb 10 2009 sounds
drwxr-xr-x 4 root root 4096 Jan 14 2009 system
- rwxr-xr-x 1 root root 212624 Jan 1 1980
drwxr-xr-x 3 root root 4096 Apr 27 2009 videos

To those who aren’t keen on the long front page posts, sorry about this one …. I’m working on a better solution. Thanks to Chip for the solution!!