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!
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). 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:
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 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 has updated his linux kernel. Get it here: http://code.google.com/p/dingoo-linux/downloads/detail?name=zImage-200905030&can=2&q=
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….
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: http://prboom.sourceforge.net/about.html
Booboo sent me the following; thanks Booboo:
I think I can add some clarification to the toolchain concept. Your
It’s all starting to make sense!
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 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:
http://dl.openhandhelds.org/cgi-bin/dingoo.cgi (see ezelkow1’s comment)
Stay tuned for more!
Looks like it won’t be long before Guybrush Threepwood graces our Dingoos!
Discuss it here: http://a320.freeforums.org/scummvm-on-dingoo-linux-t461.html
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.
From the Official (and porn free) Linux development thread on the A320 freeforum:
by ezelkow1 on Sat May 23, 2009 11:51 pm
Ok, uploaded my kernel build to:
uploaded the initial uclibc toolchain:
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!
Benchmark your Dingoo! Get it, discuss, and post results here: http://a320.freeforums.org/dingoobench-v0-1-by-sience-t406.html
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.
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 forum.dingoo-scene.com !
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.
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.
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 finishedOnce 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.
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."
Check it out here: http://dl.openhandhelds.org/cgi-bin/dingoo.cgi
- 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!
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 Dingoo-Digital.com.
flatmush has released Minesweeper on the Openhandheld dingoo forums:
Here is a minesweeper game that I've made for the a320.
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
A320 firmware upgrade steps:
Although, it is positive that Dingoo is selling well enough to the Japanese, Koreans and Russians to warrant an official firmware update:)
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?
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? :)
BTW: Consequence9’s picture makes great wallpaper, if you like the look:
From the openhandheld forums comes another tantalizing tidbit:
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.
Good one; thanks flatmush!
Here’s an excruciatingly exciting update from Booboo on Linux:
If Linux slips out this weekend … ah well, looks like I might have to return those Eurovision Song Contest tickets.
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!
Download from here. Information:
Current version: v0.3
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.
Seagal has released his PIE320 0.1 Pacman emulator! Download and discussion here.
Another day, another update top Jorghej’s Wonderswan emulator. Grab it here.
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).
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?
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?
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.
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: http://a320.freeforums.org/my-pattern-for-a-wooden-dingoo-cradle-t283.html
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 HERE
There are links to Wonderswan birdfood here.
For more information about this emulator, go to Jorgehj’s site here: http://188.8.131.52/babelfish/translate_url_content?.intl=us&lp=es_en&trurl=http%3a%2f%2fblog.tipesoft.com%2f
Originally Written by they chipan
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
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
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 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
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
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
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
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
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
[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
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).
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 184.108.40.206 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 (U.S.able)
Physical User-defined ram map:
memory: 02000000 @ 00000000 (U.S.able)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
Normal 0 - > 8192
For Movable zone start PFN each node
early_node_map  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
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
(none) login: root
login : 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 reg.app
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 target.app
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!!