Dingoonity.org

I changed a bit the standard dingux kernel so now i hava my root fs on an ext2 partition on the sd. I need this to ease the development process, a read-only filesystem which needs to be rebuilt everytime I add/change a file is a no-go for me. Everything is fine except...

1) Where's the code that mounts /boot/local and launches /usr/local/sbin/main? I grepped the kernel source for every possible keyword I could think of but I can't seem to find it. And it must be in the kernel, right? This code also mounts the root as ro. Of course I can do mount -o remount,rw in the main script but this way all of this is getting uglier and uglier.

2) Anybody tried measuring performance gains with size-optimized kernel? I realize JZ4740 doesn't have much cache or at all (I didn't read the specs yet)? Or is the ingenic's compiler, uh... broken?

3) What does the SDL use for blitting? Is it pure-software? Or maybe software with hand-crafted mips assembly to speed things up?

Right now these are just experiments, but I have a few ideas, ex. I'm thinking about something like a simple package manager, so you drop a package in a folder on the sd, then just open some install menu in dingux and choose it. It would allow people to easily add/remove features like swap and stuff without editing scripts. Instead of downloading whole localpack they could just download single items...

Of course that needs a rootfs which isn't readonly, and that means more complicated dingux installation process, but I think we could wrap a simple app up for that...

And what about this static linking stuff? Isn't that a waste of memory? Gmenu itself uses SDL so it's loaded at all times, right (or does it unload itself while launching an app?)? So now every app that uses sdl and has it statically linked loads it once more to memory.

The mounting is done by the mininit program that booboo wrote, which is located in the initial ramdisk (initrd.cpio).

Thanks. That explains why grep turned nothing up - it is compressed/scrambled. And minit isn't included in Boukichi's* sources.

* Forgive me if I'm spelling this wrong

I haven't tried -Os yet; I'd be interested in hearing the results. The JZ4740 does have a cache, but it's small: 16K instruction cache, 16K data cache.

Will report on that. But first need some kind of a performance testing setup.

Blitting is indeed done in software. There is no GPU, so the only possible hardware support would be to use the DMA controller. This is not done right now.

I was thinking about speeding up ex. alpha blended blits with XBurst. Don't know much about DMA, but will investigate when I finish the "reference" implementation of the blitter.

You know, SDL is aiming to be fast but it's also aiming to be universal and cross-platform, that means that a hand-crafted solution optimized for dingoo would be surely faster. And blitting alpha-channeled surfaces in SDL is awfully slow*, even on my PC(s).

*A 800x600 32bit (say splash background) blit makes fps drop below usability level, both on my Intel Core Duo 1.8Ghz laptop and 2.2Ghz Athlon X2 box.

I prefer sticking with a read-only root file system, since it is much less likely to get damaged and is easier to upgrade. There could be more support for customization though, such as including /usr/local/bin in the default PATH.

I don't think it would be hard to upgrade with a package manager, you can always prepare one-file extract-and-go rootfs/localpack even for the rw root. If the memcard corruption bug is sorted out or maybe a journalling fs would suffice, then I don't see any obstacles.

Personally I don't like that when I download a localpack it has everything already in it. Most of the stuff I won't ever use. It would be nice if there was a single place which would provide up-to-date versions of everything (separately) though.

What do other power users have to say, what would you like?

Linux loads code on demand (on page fault), so I think static vs dynamic linking does not make a big difference in code size. Dynamic linking has the advantage though that common libs like SDL will be in the cache. Also, if a library is improved, all statically linked apps have to be relinked to take advantage of the new library, while dynamically linked apps automatically use the new library version.

But still, the best case - it doesn't do any harm but it doesn't do any good in terms of performance and memory usage either.


---

I'm a bit confused, because my knowledge is lacking in this areas. Does the current dingux kernel do virtual memory (it does swap, right?). Do we have the whole 32bit address space available or not? Is the mem allocated by malloc guaranteed to be physically continugous or not (isn't this a prerequisite for using dma transfers and the simd instructions)? Or maybe I have to write the blitter in kernel space and use kmalloc?

BouKiCHi didn't change mininit, so you can take the source from booboo's SVN.

Thanks, I'm already on that.

For alpha blending, the first thing to check is whether the reads from the framebuffer are cached. This is determined by the flags that the SLCD driver sets on the memory region. If it is not cached, reading the existing pixel values will be awfully slow.
The actual blending can be sped up using the MXU (SIMD) instructions. I wrote some documentation here.

I was rather thinking of drawing into an offscreen buffer then pushing it all at once to the framebuffer.

I would like an app store kind of package manager, where you can select single games / emulators / applications you want to install. But I'm not sure fine-grained package management where every library is a separate package is worthwhile.

I was thinking about something like that: we have the basic set of libaries on the rootfs and the packages would be rather about emulators, games or game packs, minor features, sometimes maybe exotic or specific versions of libraries. Not as fine-grained as in a pc distro.

Linux always has virtual memory, but that only means there is a mapping from virtual addresses to physical addresses, it doesn't necessarily mean you can swap.

I know, but (the other way around) being able to swap means that we must have virtual memory? This is irrelevant now, anyway.

Whether swap is available depends on the kernel configuration; booboo's kernel did not include swap, while Menelkir included it and in OpenDingux it's also included. In OpenDingux you even have the choice to swap to SD card and/or swap to zram, which is a compressed block device in main RAM.

Yep.

malloc-ed buffers are not necessarily contiguous in physical memory, as far as I know. This is not a problem for DMA though, since you can link DMA descriptors to make one transfer read data from different locations in physical memory. For the SIMD instructions it's no problem at all, since they work on virtual addresses.

I didn't know that SIMD worked on virtual addresses, thanks for the info.

--- UPDATE ---

Strange... I checked the command line in config and there was no init= parameter. I also grepped the init executable in initrd.cpio and it appears to be unmodified BooBoo's minit. I also checked the minit's sources, and it first tries the init= kernel parameter and then it searches for standard init locations but no /usr/local/sbin/main or /boot/local/sbin/main. So what causes this kernel when compiled to search only for [/boot,/usr]/local/sbin/main ?

Hi.

Sorry for my poor English.

I'm the translator DingooWiki in French.

For answer your question about /sbin/main, it's not in the kernel. It is in the rootfs.
Read /etc/inittab in the rootfs. All the link for main process is here.

Linux kernel launch busybox init ( or linuxrc, I forget ), and after, busybox read inittab.

I already figured that out. Sorry that I dindn't to post about it, it was late night/early morning and I just went to sleep. But thanks for the help!

How are you doing for boot root system in ext2 partition ?

So first of all, you can use mininit without rewriting it, but it was written only (I suspect) to do the rootfs-romfs mounting stuff. Normally the linux kernel can do everything for you.

My final solution is:
In the kernel configuration:
1) Enable the filesystems in kernel that you need.
1a) I also enabled the DOS partition table support explicitly, but I think it is enabled by default
2) Disable the initrd completely
3) Format the sd card so the first partition is vfat and place zImage there (make sure you set the fs type to 0xB)
4) Format the second partition as ext2/ext3
4b) You can also prepare a dedicated swap partition like every normal distro does
5) Set CONFIG_CMDLINE="console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext2 rootdelay=1 rootwait=1 jz4740_udc.use_dma=0"
I think that the rootfstype paramter is not necessary (linux should guess the partition type for you).
The rootdelay or rootwait is very important! - Kernel has to wait before the devicess will be "plugged in". I'm not sure which option is crucial so I included both .
rw/ro - mount root read-write or read-only

And now you're set. I recommend using the rootfs ("unpack" it first of course, or ask for tar.gz version or something) from the latest localpack as a starting point and then crafting it to your needs - change the /etc/inittab and /etc/init.d/rcS accordingly.

BTW I'm polish so my english isn't that good too and I did understand yours without any problems!

PS I can give you my root filesystem, it's a bit modified version of that from the localpack. I changed the inittab so few mounts are done in the /etc/fstab instead of inittab and disabled some of unnecessary (for me) services like dhcpd or serial console support, etc.

Thanks !

I have disable initrd and add "rootdelay=1 rootwait=1", and now, it's work like I want !

For the moment, I have add nano and htop in my filesystem, like my old rootfs ( this weight is more 70Mo, wouch, with a lot programms  ), for more friendly view. Wow, it's very more simple to administrate Dingux like that. Thanks pinkeen.

Tomorrow, I work hard in this new Dingux, my Dingux... I know, it's useless, but I have bought my Dingoo for working in Linux Embedded, with a few of money. For my pleasure.

Good luck for your dingoo futur, Pinkeen.

Hi.

I have new question about kernel.

For the compilation of Boukichi's Kernel modified and booting on Dingux, I don't have problems. Ok, it's so cool.

But now, I want to try compile OpenDingux Kernel ( http://github.com/mthuurne/opendingux-kernel ). For the moment, I don't need modified anything in .config, only try to boot. So, I do this :
* make a320_defconfig
* make menuconfig ( For view the options, and custom only one option about the LCD )
* make vmlinuz.bin -j2 ARCH=mips CROSS_COMPILE=mipsel-dingoo-gnu-linux- ( it's my cross toolchain for mipsel who work with old kernel )

Good, no problem with compilation. Now, I have a wmlinuz.bin in arch/mips/boot/compressed/ I move this file in Dingux SD card, and rename for zImage.
But, when I want reboot on Dingux, it's freeze on first Dingux splashscreen. The console don't appear, only freeze and I need to press Reset button for backup my old custom kernel.

I don't understand why it's don't boot. Need change somethings in menuconfig ( I thinking a 320_defconfig is perfect for only test.. ) Problem with cross toolchain ? Wahou, c'est embarrassant.

While i have no knowledge about compiling and stuff, this sounds a lot like the notorious "zImage first bug", i.e. you?d need to reformat the card and first copy the zImage, then the rootfs and then the other rest you want. IF it is that bug of course...
I read it shall happen mostly on big SD cards >4gb, and i can confirm that. Had no problems like that on my old 2gb SD, but my 8gb almost always does that when i change the zImage.

Oh oh oh, unfortunately for my dignity, it's not that. The real problem is I'm stupid, and I read too quick the README. The problem isn't cross toolchain or a file .config, or anything else. It's only the vmlinuz.bin is not in arch/mips/boot/compressed/
It's in the root file, in top directory.
I had a doubt about the "fake" vmlinuz because his size was 3.5 Mo, it's so big for a little compressed kernel. The next time, I listen more closely "RTFM"....

Edit : Ooops, I forgot. OpenDingux works perfectly. Good job for all people who work on this kernel ( the one ? )

i'm not part of it, nor did i contribute anything to it, all credit goes to other people...

I haven't done and will not do anything for dingoo in a long while, i actually already gave away one of my dingoo's to a friend, since it's just gathering dust here...

I did get myselve an android based phone (htc desire) and might do some things for that although not much going on atm on that end