SliTaz Forum
You are not logged in.
Pages: 1
Hi everyone and thanks for getting so much working!
Dillo seems to be running just fine in X now!
However, to run X, I needed to update the kernel (I'm booting from USB key so I normally don't change the first FAT32 partition except for putting in different [c]cmdline.txt[/c]. I'm doing this so I can switch distributions and test things quickly). I was using 3.6.x before and 3.10.33 now.
However, there was a noticeable speed drop just about everywhere. This isn't something Slitaz specific, of course but I was just wondering if anyone else noticed. I tried removing the frequency related lines in [c]config.txt[/c] but the speed remained the same. In the old kernel version, I didn't have any overclocking enable (that I know of). Its more or less a stock boot partition from early 2013 where I added some screen resolution parameters (I've put them in the new config as well).
Boot timer
More on topic with Slitaz, would it be possible to get the boot timer back? the one that says something like
[c]Welcome to your box: 10s[/c]
Of course it doesn't count the kernel blob but seems like it would still be useful for estimates.
3.6.x behaviour
Back in 3.6.x (I can check the exact version if this is important), everything ran more or less fine, even directfb with dfbterm. But X hangs when I start [c]slim[/c]. I do get to see the login screen with the picture of a raspberry and [c]root[/c] pre-filled in but can't do anything then.
The only error I could find in the [c]Xorg.?.log[/c] is
[c]<br />
(EE) FBDEV(0): FBIOBLANK: Operation not permitted<br />[/c]
but I get these errors now even when things <i>are</i> working.
New forum
I'm making separate topics now since we got a brand new subforum for ARM. Just tell me if I should put everything in one post instead.
Offline
So the latest build seem to be much faster. I can get to a prompt in about 10s! And not that much more even for a GUI! Although I did change a few other things in the meantime (SD card, USB key) but I didn't notice anything special about them.
But when my system accidentally broke ([c]/usr/[/c] was deleted by accident), I could boot into a console in 2-3s! And it was just an [c]initramfs[/c] (does slitaz even have an [c]initramfs[/c]? I guess we are using [c]busybox[/c] anyway). Now I'd like to be able to do this deliberately. Be able to boot with (almost) nothing, just a USB keyboard and the ability to read/write text files on the USB stick (no network, no graphics, no detecting other devices if that helps).
Offline
So of course I went ahead and played with [c]/etc/init.d/rcS[/c].
It seems that for mostly what I want, I don't need most of it at all! About the first 40 lines seems to be enough, right before it checks for [c]udevd[/c]. Timing [c]rcS[/c] alone with [c]time[/c] (after booting with a missing [c]rcS[/c]) gives [c]real 0.09s[/c] (compared to [c]real 7.79s[/c] for the default [c]rcS[/c] (base image, no X).
I think the network parts eat up a lot of that but that might depends on how fast your dhcp server boots. On the other hand, I wouldn't mind having the network services be brought up in parallel to login (I don't type that fast!).
If you want to live dangerously, you can even replace [c]getty[/c] by [c]/bin/sh[/c] in [c]/etc/inittab[/c]. This gets 5 to 7s total boot to console time depending on how it is measured (7 is from plugging it it and 5 is from first seeing the "coloured square" RPi first screen, plus the time for me to react and press a stopwatch).
I don't know if this is useful for anyone else though, but it works for me. I have a mobile use for the RPi and since it doesn't have a sleep mode, to avoid draining the battery, I just wanted to shut it off and turn it back on again, which is why startup time is so important. I still need to get audio working...
Offline
Audio should really not be the biggest issue. Someone else posted on these forums about that, and seemingly got it solved I believe. If not, I do believe it is more a matter of identifying the exact issue, and putting the correct solution to work.
Offline
This probably belongs in the audio thread
http://forum.slitaz.org/topic/audio
but there are at least two people on this forum I can think of who managed to get audio working at some point. For me, that never happened. It blocks/fails on [c]pcm_write[/c] in [c]alsa-lib[/c] which I think is basically saying that "there's space for 0 more bytes of audio" all the time.
Does audio work for you? I hope its not my setup and/or the kernel module.
Offline
Pages: 1
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.55 MiB (Peak: 1.77 MiB) ]