<AneoX>
I'm trying to reduce the boot time of my board by skipping u-boot and trying to load a compressed kernel directly from the u-boot SPL. Is there a way to do such thing? If so how? I am using sunxi-kernel + script.bin. Thx
<AneoX>
Board with A20
<KotCzarny>
you can just change uboot config (disable network, usb, delays, etc)
<KotCzarny>
easier and more configurable
<MoeIcenowy>
Oh my A33 tablet scores only 18 in glmark2-es2
<MoeIcenowy>
unbelievably low score
<KotCzarny>
MoeIcenowy: retry with software rendering? :>
<MoeIcenowy>
retrying
<MoeIcenowy>
seems to be lower (I use LLVMpipe)
<apritzel>
AneoX: as KotCzarny said: don't go there, there be dragons
<AneoX>
(disable network, usb, delays, etc) done, but it spends about 2 sec
<KotCzarny>
what does it do during those 2s?
<KotCzarny>
keep in mind loading kernel takes some time
<KotCzarny>
this os either way
<KotCzarny>
*or
<MoeIcenowy>
KotCzarny: Seems that compare LLVMpipe and GPU with glmark2-es2 is not a good idea
<MoeIcenowy>
for some simple scenes LLVMpipe can work
<MoeIcenowy>
but for difficult scenes LLVMpipe is a disaster
<KotCzarny>
MoeIcenowy: unless cpu is more free with gpu offload, then it could be a win
<AneoX>
spl boots uboot, then kernel. My kernel boots 2.5sec. and app about 2, totaly >6. if remove u-boot, it will be ok, 4 sec
<MoeIcenowy>
AneoX: nope
<MoeIcenowy>
the 2 sec will go into SPL rather than U-Boot.
<KotCzarny>
and into loading files
<MoeIcenowy>
LLVMpipe got a 12.
<MoeIcenowy>
AneoX: for these kind of serious scenes, try to reduce your kernel
<AneoX>
1,6mb, removed all unnecesary
<KotCzarny>
add li-ion backup and suspend to ram?
<AneoX>
board already in production, no battery
<KotCzarny>
make v2 or ++ version
<KotCzarny>
;)
<AneoX>
i think, its possible to reduce u-boot time at least to 1 sec, because loading files is fast 43068 bytes read in 87 ms (483.4 KiB/s) script and kernel 1620832 bytes read in 247 ms (6.3 MiB/s)
<apritzel>
does anyone know where to read the SoC ID from?
<KotCzarny>
uncompressing kernel? using lzo?
<apritzel>
(not the SID)
<apritzel>
sunxi-fel seems to get it from some special FEL command
<MoeIcenowy>
AneoX: but SPL MMC driver is weaker than U-Boot MMC driver
<AneoX>
KotCzarny: not sure, i moced to sunxi-uboot, its faster than mainline
<apritzel>
jumping from a plane without a parachute is faster than having one ;-)
<KotCzarny>
AneoX: you might also pursue some cold hibernation predefined state?
<KotCzarny>
instead of booting every time?
<AneoX>
please advise how to try it
<KotCzarny>
i dont know if swsusp has an option not to delete hibernation state after resuming, in tux-on-in has such option, but it might be not compatible with sunxi
<KotCzarny>
*tux-on-ice
<apritzel>
I doubt that suspend brings anything here, especially with this slow I/O on sunxi SoCs
<KotCzarny>
apritzel: booting takes time and same slow i/o too
<apritzel>
but how is suspend/resume supposed to help if U-Boot is the time hog?
<KotCzarny>
im thinking about post-uboot load time
<apritzel>
didn't he say 2 seconds?
<KotCzarny>
he just meant spl+uboot phase, im sidetracking possible os optimizations (i dont know what os he uses though)
<apritzel>
now how long does it take the read the 512MB or so from MMC storage into DRAM?
<KotCzarny>
apritzel: compression + not loading empty pages makes it a lot less
<AneoX>
no os, simple busybox
<KotCzarny>
ah, then nvm
<MoeIcenowy>
is mali blob from NextThingCo redistributable?
<miasma>
AneoX: did you try different kernel compression options
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
\\Mr_C\\ has joined #linux-sunxi
<AneoX>
miasma: No
<miasma>
AneoX: if the read speed is 6.3 MB/s, try lz4 for kernel & initramfs. it might be the fastest on a20
<AneoX>
Ok, i will try, thx. Do you think it really increase time with 1.5mb kernel?
<miasma>
lz4 is fastest to decompress unless you previously used an uncompressed kernel
<miasma>
but it might not make a huge difference
<KotCzarny>
but might if he used default gzip
<KotCzarny>
are kernel compression algos multicore?
<miasma>
i tested these on x86 and they basically didn't make any difference, but on arm if the uboot is slow at reading kernels from sd/network, you might want to use xz, because it reduces the kernel's size. otherwise a fast algo
<miasma>
e.g. on my rpi the read speed is something ridiculous like 200 kB/s
<AneoX>
sunxi kernel not lz4 option, gzip, lzma, xz, lzo
<KotCzarny>
try them all
<KotCzarny>
it's 5-10 minutes of work
<miasma>
iirc, lzo is the second best
<AneoX>
seems sunxi u-boot not workings with lzo
apritzel has quit [Ping timeout: 256 seconds]
jernej has quit [Ping timeout: 250 seconds]
gianMOD has quit [Remote host closed the connection]
<MoeIcenowy>
you can reduce drivers to suit it for arm
<mdsrv>
yeah, and the question is
avph has joined #linux-sunxi
<mdsrv>
how to make it to be silent on libdrm_intel stuff
<MoeIcenowy>
just do not build i9.5 drivers
<mdsrv>
i dont build anything, just run configure
<mdsrv>
tell me how not to build these drivers
diego71 has quit [Remote host closed the connection]
netchip has joined #linux-sunxi
<mripard>
MoeIcenowy: qschulz already has these patches obviously
<mripard>
so, yeah, you can talk to him, or push them
<mripard>
they're going to be pushed either way
<mripard>
for you warning, it happens when you do what?
<mripard>
nothing?
<MoeIcenowy>
mripard: you mean ccu patches?
<MoeIcenowy>
I think his opps too radical and dangerous :-(
<mripard>
this is not a oops, but a warning
bananapi-debian has joined #linux-sunxi
<mripard>
and again, when does that happen?
<MoeIcenowy>
mripard: the screen cannot display anything
<MoeIcenowy>
and if at that time there's Mali program running, the program will fail
kaspter has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<bananapi-debian>
Hi! Anybody have an idea why my keyboard doesn't work on a newly debootstrapped Debian Jessie installation? I can see the login prompt on the screen (tty1), but the keyboard doesn't seem to do anything. My guess is it has something to do with systemd, but I just can't figure it out. U-Boot is 2016.7 and Kernel is 4.4.30. The keyboard works in U-Boot.
<bananapi-debian>
And the same kernel, u-boot and kernel commandline (console=tty1) work on an older debootstrapped Debian Wheezy system which still uses inittab.
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<mripard>
MoeIcenowy: you still haven't said what triggers that warning, when you start X? When you load a module?
<KotCzarny>
systemd is evil and should be removed
<mripard>
usually, when it comes up is when you don't have a valid mode, but that should way earlier
<bananapi-debian>
Btw. I can ssh into the system and the logs say "systemd[1]: Started Getty on tty1." The screen output is there, but keyboard input seems to be ignored.
<KotCzarny>
check with lsusb if kb is detected
<KotCzarny>
or with dmesg
bugzc has joined #linux-sunxi
<bananapi-debian>
KotCzarny: The keyboard seems to be recognized, I see the usb events when I plug it out an in, and it also loads "usbhid: USB HID core driver" after recognizing the usb device on boot
<KotCzarny>
then just remove systemd (correctly) and be done
<KotCzarny>
it's still possible to do in jessie
<bananapi-debian>
KotCzarny: Is there another way to verify the usb device is actually set up as a HID device?
<KotCzarny>
ls /dev/input/ ?
<KotCzarny>
or cat /proc/bus/input/devices
<KotCzarny>
kb should have kbd in handlers line
<bananapi-debian>
KotCzarny: I know it's possible. But I also know it's possible to get it working someway. I have another board upgraded from Wheezy to Jessie (incl. systemd). And there the keyboard works, but it also took over the old inittab from Wheezy. I might just copy that, but I thought there must be another way if that's not used by default anymore.
<KotCzarny>
trust me. systemd IS evil
<KotCzarny>
trying to make it work is just inflicting more future pain
<MoeIcenowy>
mripard: when I stopped X
<MoeIcenowy>
or have X running for some minutes
<MoeIcenowy>
and I misread your sentences
<MoeIcenowy>
sorry :-(
<TheLinuxBug>
<KotCzarny> trust me. systemd IS evil - Preach on my borther, preach on! ;)
<TheLinuxBug>
SysV 4 life
<KotCzarny>
sanity4life!
<KotCzarny>
systemd is insane/braindamaged by design AND implementation
gianMOD has joined #linux-sunxi
<TheLinuxBug>
indeed!
<bananapi-debian>
KotCzarny: Well, I don't engage in philosophical debates over init systems. Honestly, I don't care much. On a couple of systems, I use Debian's default choice of systemd without any issues. And frankly, while sticking to sysvinit works well for the time being, you never know what dependencies they add in the next release. So the question to me really is, how to configure the console properly and I'm sure some sunxi folks h
<KotCzarny>
bananapi-debian: its not philosophical. CODE is bad, buggy and broken
<bananapi-debian>
That being said, while I assume it's a systemd related issue, I'm not sure. It might be something different that I'm missing
<mripard>
MoeIcenowy: then, this warning happens when the vblank interrupt doesn't report the event
<mripard>
MoeIcenowy: so there's probably something wrong in our CRTC disable code path
<MoeIcenowy>
mripard: is it because I'm not use the very precise clock?
<KotCzarny>
you can cat /dev/input/eventX device and type something on the kb
<MoeIcenowy>
(I cherry-pick the patch from wens
<mripard>
KotCzarny: because init scripts are so much better from that aspect.
<KotCzarny>
if it outputs anything then system/device works, just gets broken in the software
<KotCzarny>
mrpipard: because i can trim/modularize/modify my os to my liking. which is being locked in with systemd
<KotCzarny>
systematically and progressively
<MoeIcenowy>
KotCzarny: why do you say "locked" ?
valkyr1e has quit [Ping timeout: 256 seconds]
<mripard>
MoeIcenowy: probably not, if it was that you would see it very early on
gianMOD has quit [Ping timeout: 260 seconds]
<mripard>
but without the rest of the logs it's hard to tell
<bananapi-debian>
KotCzarny: I don't have a /dev/input* .... I'll check if I see that on another machine
<MoeIcenowy>
mripard: The panel clock issue used to prevent me from using sun4i-drm until I used wens's patch
<mripard>
KotCzarny: that's BS. You can tweak any unit files with systemd
<mripard>
but we don't really have any alternative
<MoeIcenowy>
yes as a distro maintainer systemd freed me from maintaining init scripts ;-)
<KotCzarny>
simplicity for distro maintainer != security/sanity for the user
<mripard>
indeed
<KotCzarny>
see the bananapi-debian for example
<bananapi-debian>
Ok... I gotta prepare some dinner now.. but I'll leave the chat open, so if anybody has more ideas what I might check or look her, I'll catch on later. Thanks
<MoeIcenowy>
but systemd is now becoming a standard of different distros
<KotCzarny>
bananapi-debian: it might be /dev/event/inputX
<KotCzarny>
replace X by proper number
<mripard>
now you know why distros maintainers and applications developpers want to ship something that just works and that allows them to code on something meaningful instead of a dumb broken and limited shell script
<MoeIcenowy>
in our distro this is joked to be "Lennart Standard Base" ;-)
<KotCzarny>
limited?
<mripard>
limited.
<KotCzarny>
in what way shell scripting is limited?
<MoeIcenowy>
KotCzarny: at least it cannot support cgroups
<mripard>
how do you monitor that the application is still running, and respawn it afterwards ?
<MoeIcenowy>
so programs can escape the monitering of shell scripts by forking twice
<KotCzarny>
uh, inetd ?
<mripard>
how do you say something like "spawn those 5 different services and trigger a LED depending on the outcome" ?
<KotCzarny>
some other daemon watcher?
<KotCzarny>
i can script/code it for a multitude of ways
<MoeIcenowy>
KotCzarny: inetd has lost its value in systemd world, as systemd's *.socket can replace it
<mripard>
those are very standard use case
<MoeIcenowy>
mripard: do you have any ideas of possible fix of my drm problem?
<MoeIcenowy>
and did you met it on SinA33?
<mripard>
MoeIcenowy: I didn't, but I'm not sure I ever disabled it
willmore has quit [Ping timeout: 245 seconds]
<mripard>
can you enable drm.debug and give all the logs?
<MoeIcenowy>
of course, can it be done by add "drm.deubg=1" in bootargs?
<MoeIcenowy>
oh it's 0x3f
<MoeIcenowy>
mripard: the problem *won't* occur in only fbcon, neither with weston, only with X it occurs
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<mripard>
MoeIcenowy: that would be interesting to get an idea why
<mdsrv>
if h3 does not support opengl, this means all opengl stuff will run with sw rendering?
<KotCzarny>
yup
<mdsrv>
and u mean that opengl es is not the same as opengl?
<KotCzarny>
yup
<KotCzarny>
see glshim project
<mdsrv>
ok
<tkaiser>
mdsrv: What is your use case? Running benchmarks or real stuff?
<KotCzarny>
tkaiser: did you see the link about overclocking and chip aging?
<mdsrv>
i want to find out why my SDL2 app does not work when mesa with hw support is installed
<tkaiser>
KotCzarny: yes
<bananapi-debian>
Ok, I'm back. So about my keyboard problem...
<mdsrv>
with libgl-mesa-swsomething it works ok, but a bit laggy
<KotCzarny>
tkaiser: that means 1296 might not be exactly best idea
<tkaiser>
KotCzarny: Then use 480 or whatever you like
<KotCzarny>
just saying, because you care about reliability, and having sudden errors due to oc/age isnt good
<KotCzarny>
yet, its default in armbian
<tkaiser>
KotCzarny: C'mon, it's default for the few H3 devices with SY8106A and it's known to work. If anyone does number crunching on a H3 device he's dumb anyway.
<miasma>
can't they just install bigger heatsinks
<KotCzarny>
'known to work' isnt the best argument here, and while i agree those boxes are mostly hobbyist, you were adamant on stability/reliability stance
<KotCzarny>
miasma: its not about temperature, but higher mhz
<miasma>
ok
<bananapi-debian>
I was kinda stupid :( After wondering why my keyboard would not show up in /dev/input/* (thanks @KotCzarny!), I decided to go to the basement and pull out a different keyboard. And with that other keyboard, everything works. So, it turns out there is no problem with the console/tty configuration or systemd at all.
<bananapi-debian>
I'm surprised that the other keyboard worked in U-Boot but not in Linux, but I suspect it doesn't register as a normal USB HID device and require some magic kernel module. I'll look into that. But for now, I'm glad to know that the installation itself is fine.
<KotCzarny>
plug it into pc and see what modules load / msgs show up in dmesg
<bananapi-debian>
KotCzarny: Yeah, I was about to do that now ;)
<tkaiser>
KotCzarny: So you suggest 480 MHz max cpufreq? Or 720? Or 960?
<KotCzarny>
nope, 1200 (as suggested by allwinner sdk) with easy overclock/downclock by user choice
<tkaiser>
KotCzarny: Please do a 'cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state'
<KotCzarny>
my boxes are mostly idle
<KotCzarny>
at least when not compiling
<tkaiser>
KotCzarny: Great, so they're at 480 MHz and not 1296 all the time.
<KotCzarny>
but my usecase might be different than other users, and im not the distro maintainer which is what you are
<KotCzarny>
my choices only affect me and my boxes, yours might affect thousands
<KotCzarny>
and it might not even show during lifetime (ie. before being replaced by faster board next year)
<mdsrv>
tkaiser: real stuff
<tkaiser>
KotCzarny: Armbian does also slightly undervolt the SoC so your argumentation fails completely. This undervolting happened by accident (communication issues between Igor and me) but we left it and were curious whether reports come in about undervoltage issues. We had 2 out of thousands so far
<KotCzarny>
tkaiser: nope. its not about voltage/temperature at all. its about aging because of higher freq
<tkaiser>
KotCzarny: To be honest I really don't care about this. If someone wants to do number crunching on a $15 SBC then he should do and maybe buy a new SBC after 3 instead of 5 years.
<tkaiser>
Since 'aging' is an issue
<bananapi-debian>
KotCzarny: The keyboard in question seems to require the HIDRAW module, which is not included in the kernel. Good to know. Now I can actually start doing something useful ;)
<KotCzarny>
at least it's supported at all
rah has quit [Quit: leaving]
rah has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
yann-kaelig has quit [Quit: Leaving]
rah has quit [Quit: leaving]
rah has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
leviathanch has quit [Read error: Connection reset by peer]
f0xx has quit [Ping timeout: 244 seconds]
AneoX has quit [Ping timeout: 260 seconds]
bananapi-debian has left #linux-sunxi [#linux-sunxi]
dr1337 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leviathanch has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
station has quit [Ping timeout: 260 seconds]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Ping timeout: 244 seconds]
station has joined #linux-sunxi
gianMOD has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]