**** BEGIN LOGGING AT Thu May 25 03:00:03 2017
May 25 07:04:10 <greguu> VartiWork: good progress.
May 25 07:04:21 <VartiWork> hi greguu
May 25 07:04:28 <greguu> just to confirm, did you try https://github.com/greguu/linux-3.10.y-c3x00-f2fs-kexec-r0/releases/download/r0/linux-3.10.y-c1000-f2fs-kexec-test-r0.tar.gz
May 25 07:04:32 <VartiWork> yep, finally I did it!
May 25 07:05:14 <VartiWork> if that's the version you asked me yesterday to test, then yes
May 25 07:05:27 <VartiWork> let me check to make sure
May 25 07:08:21 <greguu> yes same version.
May 25 07:08:53 <greguu> so the 2.6 frankenstein can boot 4.12-rc1-c3x00 fine for you?
May 25 07:08:53 <VartiWork> yes, I tested it yesterday at lunch break
May 25 07:08:56 <VartiWork> May 24 11:03:58 <VartiWork> greguu: no luck with the new f2fs kexec, blinking led again
May 25 07:09:10 <VartiWork> didn't manage to try that
May 25 07:09:56 <VartiWork> I have only tried to boot ant's 4.4.8 kexec via your frankenstein kexec, and it worked
May 25 07:10:18 <VartiWork> I'll try your 4.12 next and report back
May 25 07:11:29 <VartiWork> there was also an akita-test.tar.xz to be tested, it was your first kexec for akita, but I see you removed it
May 25 07:11:44 <VartiWork> didn't test that one either
May 25 07:11:47 <greguu> well, you did boot 4.12   VartiWork | http://www.oesf.org/pics/IMG-20170524-02284.jpg
May 25 07:12:51 <VartiWork> ah, sorry, you meant if I booted the 4.12 *alarmz* kernel
May 25 07:13:25 <VartiWork> I thought you meant if I have tried the 4.12 kexec via the 2.6 one
May 25 07:14:06 <VartiWork> yes, so alarmz runs on C1000 too with no tweaks required :)
May 25 07:15:06 <VartiWork> hi ant_work
May 25 07:15:47 <ant_work> hello
May 25 07:16:06 <greguu> hi
May 25 07:16:15 <VartiWork> greguu:
May 25 07:16:17 <VartiWork> May 24 11:37:03 <VartiWork> btw why does Danboid suggest in his guide to do this once the rootfs has been copied to the SD card? May 24 11:37:05 <VartiWork> # cp alarm-zaurus-c3x00-minimal-rootfs-october2015.tar.xz /mnt/root/
May 25 07:16:47 <greguu> not sure , it is silly
May 25 07:16:52 <VartiWork> just curious to understand why to have a copy of the whole rootfs
May 25 07:17:08 <greguu> just extract to the SD and that is it
May 25 07:17:12 <VartiWork> ok, maybe some wrong cut and paste
May 25 07:17:57 <VartiWork> I'll now update the thread about alarmz on c1000
May 25 07:18:15 <greguu> I removed that line from the fork I did of his howto. I guess I make a new howto from scratch
May 25 07:19:03 <greguu> VartiWork: ok, you can do that, but make sure people know about the right 2.6 frankenstein and ext3 limitations
May 25 07:20:07 <greguu> I guess here is also a workaround. If you want to use f2fs on C1000, you can boot to ext3 (kernel only) then set real_root to sda2 (f2fs)
May 25 07:20:34 <greguu> like in the old days, when boot was on a seperate ext2 parition
May 25 07:21:14 <greguu> let me write up a howto on the oesf first for that
May 25 07:21:42 <VartiWork> a new howto would be great
May 25 07:21:53 <greguu> I guess, ant_work and me want to figure out why C1000 kexec does not boo, in the first place
May 25 07:22:24 <VartiWork> ah, that workaround would be interesting
May 25 07:23:11 <VartiWork> I was thinking of having a separate ext3 partition with the 4.12 kexecboot, boot that, then boot alarmz
May 25 07:24:05 <VartiWork> but your solution seems better, that way you don't have to boot 2 kexecs
May 25 07:24:40 <greguu> no, no need, just have a ext3 on sda1 (10MB) with the 4.12 kernel and boot.cfg, then add a real_root parameter, pointing to sda2, on sda2 you will have the arch rootfs
May 25 07:25:16 <VartiWork> ok
May 25 07:25:55 <greguu> I will make up a howto and dump the "silly" howto from danboid
May 25 07:26:14 <greguu> ant_work left?
May 25 07:26:36 <VartiWork> I'll wait for your howto, then update my thread, I wanted anyway to report about my badblock and SD check
May 25 07:27:00 <VartiWork> do you have an account on his wiki?
May 25 07:27:08 <greguu> VartiWork: did you reboot the 4.12 on your C1000 a few times ? did you still get "failed" on corgi backlight when booting ?
May 25 07:27:39 <VartiWork> I only booted it once (and damn I left my akita home today)
May 25 07:28:05 <VartiWork> I'll let you know
May 25 07:28:06 <greguu> just contribute to this : https://github.com/greguu/ZALARM-install
May 25 07:28:13 <greguu> we will rewrite it
May 25 07:28:26 <VartiWork> ok
May 25 07:28:40 <greguu> or create a new one
May 25 07:28:42 <VartiWork> (check #alarmz)
May 25 07:40:07 <ant_work> power outage :/
May 25 07:40:21 <VartiWork> sorry about that
May 25 07:40:26 <ant_work> I've quickly read the logs
May 25 07:40:42 <ant_work> no need for workarounds, there must be smthg really simple
May 25 07:41:35 <ant_work> I had a similar issue with c700
May 25 07:41:45 <ant_work> c750 c860 all was booting but not c700
May 25 07:42:00 <greguu> ant_work: I agree, I think it may be in sharp_param.c
May 25 07:42:09 <ant_work> we discovered the compression factor was needing too much ram. Kernel did not decompress...
May 25 07:42:23 <ant_work> but here it is not the case
May 25 07:42:29 <greguu> using xz ?
May 25 07:42:36 <ant_work> other issue was oversized zImage, also excluded
May 25 07:43:02 <ant_work> (you get truncated kernel...it happened in the past)
May 25 07:43:06 <greguu> you remember this "no boot" issue on c3x00 that was related to sharp_param.c ?
May 25 07:43:18 <ant_work> yes but I sent patch upstream
May 25 07:43:26 <greguu> was that tested on C1000 ?
May 25 07:43:54 <VartiWork> I remember you greguu mentioned me that the Akita needed a "password" to boot
May 25 07:44:05 <greguu> ?
May 25 07:44:16 <VartiWork> let me find your quote
May 25 07:44:57 <ant_work> if 4.x boots kexec'ed then it is probably an early issue
May 25 07:45:15 <greguu> ant_work : my 3.5 kexecboot had the section in sharp_param.c completely commented out, it did not boot on C1000
May 25 07:45:45 <ant_work> I have built last night old OE 3.10, with this patch
May 25 07:45:47 <greguu> ant_work: the issue must be in the difference kexec and real boot work
May 25 07:46:33 <greguu> a real (flashed) kernel needs to get it right, where as a kexec'd kernel relies only on the success of the kexec kernel
May 25 07:46:41 <ant_work> the only diff is the gpio expander on akita
May 25 07:47:04 <ant_work> maybe we need some regulator
May 25 07:47:21 <ant_work> check again spitz.c
May 25 07:47:28 <greguu> hm, not sure
May 25 07:47:41 <greguu> my 4.12-rc1 boots once kexec'd.
May 25 07:47:52 <greguu> what does the kexec need to boot
May 25 07:47:54 <greguu> ?
May 25 07:48:07 <greguu> there must be something we missed
May 25 07:48:24 <VartiWork> can't find your quote, I have probably misread what you wrote
May 25 07:50:56 <VartiWork> my guess is that something is set correctly by kexec 2.6, and wrong by kexec 4.x, and this setting seem to survive a reset...
May 25 07:51:16 <greguu> it is not only 4.x, even 3.x does not boot on akita
May 25 07:51:24 <VartiWork> remember that flashing 2.6, booting it, flashing 4.x and booting it also works
May 25 07:51:32 <greguu> once ?
May 25 07:51:38 <VartiWork> yes, only once
May 25 07:52:00 <greguu> does not make any sense.
May 25 07:52:23 <VartiWork> might be another issue too, not related to this
May 25 07:53:39 <VartiWork> I might try the same with your 4.12 kexec and make a photo of the boot log
May 25 07:53:53 <VartiWork> in case it might be helpful
May 25 07:53:57 <greguu> ant_work: I did force all "if machine=akita" in pitz.c and in spitz_pm.c but no luck accoring to Varti
May 25 07:54:12 <greguu> VartiWork: there is no 4.12 kexec
May 25 07:54:25 <greguu> the latest is 3.10.y
May 25 07:54:34 <ant_work> I can state that surely klinux-kexecboot 3.2 (the lost one) was booting on akita
May 25 07:54:34 <VartiWork> argh, sorry
May 25 07:54:54 <greguu> ant_work: this is good enough to give some hope
May 25 07:54:57 <greguu> :)
May 25 07:55:14 <VartiWork> too many test versions, I'm getting confused :)
May 25 07:55:16 <ant_work> VartiWork, pls note: kexecboot = binary doing the menu stuff, linux-kexecboot = kernel containing that binary in the initramfs
May 25 07:55:24 <ant_work> kexecboot = v. 0.6
May 25 07:55:28 <ant_work> since years
May 25 07:55:35 <ant_work> kernel version changes, just that
May 25 07:56:04 <VartiWork> I see
May 25 07:56:08 <greguu> ant_work: correct, the 2.6 frankenstein is just  https://github.com/LinuxPDA/linux-kexecboot/tree/master/zaurus/kernel-2.6.2x plus kexecboot 0.6
May 25 07:56:27 <VartiWork> now that makes more sense to me
May 25 07:56:31 <greguu> it was not recompiled
May 25 07:56:55 <greguu> kexecboot 0.6 brings at least the new boot.cfg structure but not more
May 25 07:57:03 <ant_work> I'll upload that 3.10 from OE and then I'll try to recompile the 3.2 series
May 25 07:57:30 <greguu> still got the patches and .config ?
May 25 07:57:33 <VartiWork> but what's the difference between your frankenstein kexec and these? https://github.com/LinuxPDA/linux-kexecboot/tree/master/zaurus/kernel-2.6.2x
May 25 07:57:36 <ant_work> greguu, it is hard to use the f2fs linux-3.10.y: I was using Yocto prepatched sources
May 25 07:57:44 <greguu> ant_work: try to use the 3.10.y source with f2fs
May 25 07:57:46 <ant_work> it doesn't merge cleanly
May 25 07:58:13 <ant_work> but atm f2fs is not the point
May 25 07:58:15 <greguu> ant_work: think out of yocto/oe for a minute
May 25 07:58:19 <VartiWork> sorry, messed it up again
May 25 07:58:35 <ant_work> greguu, it is to get the same binaries as then
May 25 07:58:46 <ant_work> I did test these artifacts
May 25 07:58:48 <greguu> well, that is tough
May 25 07:59:08 <ant_work> yep, reproducible binaries are coming only these days in OE
May 25 07:59:13 <greguu> best to create a VM from that time ago. a snapshot with all the toolchain etc
May 25 07:59:20 <ant_work> but you get the point: same gcc, same sources
May 25 07:59:26 <greguu> yes
May 25 07:59:35 <VartiWork> the kernel-2.6.2x kexec does contain a menu, but it's not kexec 0.6... then what is that menu, an older kexec?
May 25 07:59:56 <ant_work> yes
May 25 07:59:58 <greguu> yes it is older, ant_work will know what version it may be
May 25 08:00:16 <VartiWork> ok
May 25 08:00:24 <ant_work> https://github.com/kexecboot/kexecboot/wiki/Screenshots
May 25 08:00:28 <ant_work> 0.4 or 0.5 ?
May 25 08:00:34 <VartiWork> and is kexec still developed, i.e. will there be a 0.7?
May 25 08:01:04 <greguu> Kexecboot v0.5
May 25 08:01:11 <VartiWork> it's 0.4, I remember it
May 25 08:01:14 <greguu> it says 2.6.26
May 25 08:01:28 <greguu> https://cloud.githubusercontent.com/assets/943151/10638557/db3a35a4-780b-11e5-8ecd-aa990bd28c9a.png
May 25 08:01:42 <greguu> thats 2.6.26
May 25 08:02:12 <VartiWork> I have only seen the black border on 4.4.8 and on your franken version
May 25 08:02:37 <VartiWork> the older kexecs are all "full screen"
May 25 08:03:17 <greguu> realy ? I thought they been 480x480 all the time
May 25 08:03:36 <VartiWork> AFAIR it was the same for the omegamoon one, too
May 25 08:04:02 <greguu> ok, then it was <0.5
May 25 08:04:03 <VartiWork> http://www.omegamoon.com/blog/images/Zubuntu-Bootmenu-small.JPG
May 25 08:04:07 <greguu> I see
May 25 08:04:27 <greguu> I used 0.5 for my first kexecboot kernel
May 25 08:05:19 <VartiWork> ok, I don't know if I have ever tried that, I believe I have always tried with your latest one
May 25 08:05:45 <greguu> not sure I have published it
May 25 08:06:03 <greguu> it was in 2011 or 2012 I got arch going
May 25 08:06:23 <greguu> anyway, you need to do some more testing on you C1000 :)
May 25 08:07:03 <greguu> ant_work: we need to understand what does the kexec boot differ from a "real" boot.
May 25 08:07:16 <greguu> this is where the problem is
May 25 08:07:42 <ant_work> greguu, we are still using an old kexec version
May 25 08:07:55 <ant_work> kexec did heavily change but mostly for other arch
May 25 08:08:33 <VartiWork> greguu: yes, will do :)
May 25 08:08:45 <ant_work> kexec is not a real reboot
May 25 08:09:13 <ant_work> there have been patches to add 'hardboot' option for some boards
May 25 08:09:52 <ant_work> the point is, at power on the akita should have all registers set, MMU, etc
May 25 08:09:55 <greguu> ant_work : so the hardboot fails, but the kexec'd boot works, where does this leave us. ? decompression, machine detection ?
May 25 08:10:14 <greguu> early stage issue
May 25 08:10:18 <greguu> yes
May 25 08:10:50 <greguu> no screen, fbdev init
May 25 08:11:19 <VartiWork> I wonder, what does the blinking led indicate?
May 25 08:11:31 <greguu> charging LED ?
May 25 08:11:34 <VartiWork> yes
May 25 08:12:05 <VartiWork> it is blinking differently as when there's no battery in the compartment
May 25 08:12:19 <ant_work> we must build one kernel with no logo, printk and debug to see where it stops
May 25 08:12:20 <greguu> so my kexec kernel, and other have "charging LED" set to cpu heartbeat
May 25 08:12:44 <ant_work> gpio led are one difference btw akita and spitz
May 25 08:12:53 <VartiWork> yes, heartbeat, as in on-off-on-off-pause, then again
May 25 08:12:55 <greguu> if it is blinking, the kernel is idle on CPU, if it blinks fast, kernel is busy on CPI
May 25 08:13:06 <greguu> CPU
May 25 08:13:19 <ant_work> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-pxa/spitz.c?h=v4.12-rc2#n578
May 25 08:14:27 <greguu>  if (machine_is_akita()) {
May 25 08:14:29 <greguu>   lcd_data->gpio_backlight_cont = AKITA_GPIO_BACKLIGHT_CONT;
May 25 08:14:31 <greguu>   lcd_data->gpio_backlight_on = AKITA_GPIO_BACKLIGHT_ON;
May 25 08:14:33 <greguu>  }y
May 25 08:14:35 <greguu> Y
May 25 08:14:39 <greguu> I forced this already in my test kernel
May 25 08:15:43 <greguu> but if Varti is saying that the charging LED is blinking on my test kernels, this means the CPU is idle and kernel has access. just display/backlight is borked or something else
May 25 08:16:48 <greguu> this gpio is for backlight..
May 25 08:17:12 <greguu> why does it work if kexec'd then ?
May 25 08:17:20 <greguu> it has to be something different
May 25 08:19:04 <greguu> could be some SPI stuff too
May 25 08:19:37 <greguu> but anyway, the key is in the difference between the kexec'd boot and a "real" boot
May 25 08:20:08 <greguu> and to be honest, I do not know enought about the Z to finegrain that process
May 25 08:22:37 <greguu> VartiWork: When booting the 3.x or 4.x kexecboot, do you see a flash of "white" just after turning on the Z ?
May 25 08:22:51 <VartiWork> let me think
May 25 08:23:23 <VartiWork> I always see that flash with 2.6 or franken
May 25 08:23:35 <greguu> it should be there with any kernel that boots
May 25 08:23:39 <VartiWork> but I'm not sure about the 3.x or 4.x
May 25 08:23:57 <greguu> well give it a try, if you can, just to document the difference
May 25 08:24:09 <VartiWork> let me test it again, I really don't remember that part
May 25 08:24:28 <VartiWork> (I need to write down a to-do list now)
May 25 08:24:47 <greguu> I know if a kernel does not boot at all, you do not see the backlight flash
May 25 08:25:37 <VartiWork> ah, then that would make thing much more difficult to debug
May 25 08:25:39 <greguu> this means decompression issue or close to early stages
May 25 08:26:36 <greguu> well it would at least narrow down if the kernel can extract and init fbdev
May 25 08:31:24 <VartiWork> silly question, but... could be the _failed_ message on corgi's backlight I see on 4.12 be related to this? I guess you already mentioned it's not
May 25 08:31:41 <greguu> not sure, I need to know more about it.
May 25 08:31:45 <ant_work> VartiWork, have you tried to flash it with nandlogical ?
May 25 08:32:39 <ant_work> greguu, in userspace we have a minor issue with urandom not having enough entropy (no RTC)
May 25 08:33:02 <ant_work> it's a recent kernel warning
May 25 08:33:13 <ant_work> recent I mean 4.x
May 25 08:33:19 <VartiWork> ant_work: no, unfortunately I had no time for that, will try it this evening
May 25 08:33:57 <ant_work> the 2.6 is flashed correctly by updater.sh but you never know
May 25 08:34:55 <greguu> ant_work: there is support for RTC in the kernel for pxa2xx, but the Zaurus does not support it
May 25 08:35:03 <greguu> ?
May 25 08:35:14 <greguu> updater.sh is not the issue I think
May 25 08:36:26 <greguu> VartiWork: do a "journalctl -xe" after a logon to see what the corgi backlight issue is about
May 25 08:37:06 * greguu hates systemd and wonders why not to go back to gentoo\
May 25 08:37:08 <ant_work> I think he's referring to zaurusd
May 25 08:37:20 <greguu> there is no zaurusd on arch
May 25 08:37:37 <greguu> systemd handles the corgi backlight
May 25 08:37:47 <VartiWork> greguu: ok
May 25 08:38:55 <VartiWork> http://www.oesf.org/pics/alarmz_todo.txt
May 25 08:39:12 <VartiWork> I think it should be all, anything to add?
May 25 08:40:52 <greguu> May 14 14:12:42 zaurus systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:corgi_bl.
May 25 08:41:49 <greguu> VartiWork: well, yes, I guess you will be busy
May 25 08:43:30 <ant_work> about real root, you can 'pivot root' in boot.cfg
May 25 08:43:51 <ant_work> i.e. kernel is on mmcblk0p1
May 25 08:44:01 <ant_work> rootfs=/dev/mtdx
May 25 08:44:23 <VartiWork> as always :) there's the oesf todo list as well, the apps I wanted to compile for the Collie, other roms to install and check...
May 25 08:44:44 <greguu> ant_work : yes, good point
May 25 08:44:51 <ant_work> # Forced pivoting
May 25 08:44:51 <ant_work> LABEL=oldkernel
May 25 08:44:51 <ant_work> KERNEL=/boot/zImage-old
May 25 08:44:51 <ant_work> APPEND=root=/dev/mtd2 rootfstype=jffs2
May 25 08:45:00 <ant_work> from ..kexecboot/wiki/how_to_write_config
May 25 08:45:22 <ant_work> it was meant to boot cacko
May 25 08:45:26 <VartiWork> will try that too
May 25 08:45:52 <greguu> VartiWork, you still need to place the kernel on a ext3 partition
May 25 08:45:59 <VartiWork> yep
May 25 08:46:11 <greguu> your root can be f2fs
May 25 08:47:25 <greguu> to be honest I am not sure if there is a hughe benefit between ext3/4/f2fs
May 25 08:47:30 <greguu> speed wise
May 25 08:48:19 <VartiWork> I guess f2fs does a better job at wear levelling
May 25 08:48:40 <greguu> so does it say. to be seen.... by then your Z is dust already :)
May 25 08:50:23 <greguu> my microdrive is now 12 years old, works fine, amazing tech
May 25 08:50:41 <VartiWork> nice
May 25 08:50:58 <greguu> hammered it with swap for native kernel builds
May 25 08:51:03 <VartiWork> I believe I'll end up destroying many SD cards before I'll retire my Z
May 25 08:51:19 <greguu> I killed a few SD card with swap on them
May 25 08:51:56 <greguu> now I replaced the microdrive with a CF flash card, I will swap to to a old SD card or the microdrive
May 25 08:52:32 <greguu> note: even a "pacman -Syu" can get your Z to start swapping"\
May 25 08:53:56 <greguu> ant_work : time get a "oe/jocto" forked to a Zaurus only distribtion based on musl and busybox, using pacman
May 25 08:55:39 <greguu> I guess not worth the effort for just a handfull of users
May 25 08:56:27 <VartiWork> regarding the swap wearing, I have found this interesting product: http://www.dpie.com/ssd/compact-flash/innodisk-icf-1me
May 25 08:58:11 <VartiWork> the site claims it is an SSD in a CF casing... I understand this as having the same type of firmware with wear levelling as normal SSD drives, so that might be a better choice for a swap partition
May 25 08:58:38 <VartiWork> plus they don't seem to be much expensive: http://www.wdlsystems.com/iCF-1ME/
May 25 09:00:19 <greguu> not sure, I guess you can just buy another SD/CF card if it fails
May 25 09:01:17 <greguu> maybe you get a armv5el cryptolocker, even worse LOL
May 25 09:01:54 <greguu> just stick to he basic, the zaurus has reached its apogee
May 25 09:02:17 <VartiWork> if the life expectancy is 2 month vs years, it might be worth
May 25 09:03:43 <greguu> well, the sandisk ultra 8GB i just put in, will do 24 months, even if I would swap on it.. I just use it sometimes..
May 25 09:04:14 <greguu> it is not that much faster than the microdrive
May 25 09:04:20 <greguu> I expected more
May 25 09:04:33 <greguu> but the Z can not do 50MB/s
May 25 09:04:41 <VartiWork> I see
May 25 09:04:43 <greguu> maybe 5MB/s tops
May 25 09:05:32 <greguu> but access time is way faster and overall performance is better, but I got the same with a SDHC SD card.
May 25 09:06:09 <VartiWork> I believe SD/CF cards are in general not optimized to be used for booting and using an OS
May 25 09:06:28 <VartiWork> might be interesting to do some benchmarks and compare them
May 25 09:06:46 <greguu> not true, firewalls, routes and so called IOT stuff use SD/CF on a regular basis as OS storage
May 25 09:07:09 <greguu> most are RO for most of the time
May 25 09:07:39 <greguu> ArchLinux is a good example on how to do it right, keep config in memory until shutdown, just save config.
May 25 09:07:50 <greguu> sorry AlpineLinux I meant
May 25 09:08:11 <VartiWork> if only it supported armv5, pity
May 25 09:08:34 <greguu> yes, a shame
May 25 09:08:49 <greguu> someone made a homebuild port, but ..
May 25 09:10:37 <VartiWork> was it working?
May 25 09:10:37 <greguu> Yocto/Oe can moved to musl and busybox, but that buildsystem is a paint
May 25 09:10:40 <greguu> pain
May 25 09:10:49 <VartiWork> aha
May 25 09:11:03 <greguu> yes, it was, I still have the feed. but it is old now
May 25 09:12:09 <greguu> there are not many linux dist. that offer generic arm5vtel anymore
May 25 09:12:19 <greguu> arch is the best compromise
May 25 09:12:21 <VartiWork> yep
May 25 09:12:24 <VartiWork> btw "Ok, so there is a package called Ramlog which does the job of ensuring the logs are only written at power down"
May 25 09:12:36 <greguu> but a musl based and busybox based dist would be optimal
May 25 09:12:39 <VartiWork> http://tech.scargill.net/the-raspberry-pi-sd-wear-issue/
May 25 09:15:14 <greguu> ramlog or ramfs is not an option on a 64 MB device
May 25 09:15:27 <greguu> the pi has more resources
May 25 09:15:56 <greguu> actually, the zaurus is getting more and more of an challange
May 25 09:16:23 <greguu> I plan to switch to minirc and busybox
May 25 09:16:32 <ant_work> greguu, it is relatively easy to build a distro and a feed using OE. We did with OpenZaurus 10yrs ago :)
May 25 09:16:58 <ant_work> now the problem: who decided what goes in the image? which distro-policies?
May 25 09:17:16 <ant_work> where to host the feeds? which update-frequency?...
May 25 09:18:16 <ant_work> binutils/musl/systemd/...we have all, but the decision must be taken considering the 32/64MB ram...
May 25 09:18:39 <ant_work> so the package manager is still opkg because it is 'light'
May 25 09:19:00 <ant_work> but you can have rpm, dpkg, ..
May 25 09:19:10 <ant_work> so it really depends on the target
May 25 09:19:40 <ant_work> the predefined images I do build (core-image-base and core-image-minimal) are just a starting point
May 25 09:20:02 <ant_work> with few lines you can add packagegropus or single packages
May 25 09:20:21 <ant_work> even the SDK for target
May 25 09:20:35 <ant_work> if you really want to compile on Zaurus :)
May 25 09:21:10 * greguu build several kernels on the Z while traveling
May 25 09:21:37 <greguu> so OE or YOCTO ?
May 25 09:21:59 <greguu> the whole setup is a pain, I am used to simple toolchains :)
May 25 09:22:22 <ant_work> I find it easier than buildroot
May 25 09:22:41 <ant_work> you rarely touch the sources, mainly the metadata
May 25 09:23:02 <ant_work> I must write a simple how-to
May 25 09:23:29 <greguu> sure, the main issue is packages, arch arm5v does support the largest repo
May 25 09:23:36 <ant_work> on modern CPU you build toolchain + image in 1h 30mins
May 25 09:23:39 <greguu> this is hard to compete with
May 25 09:24:08 * greguu my kernel builds on a dual Xeon in 23 seconds
May 25 09:24:43 <ant_work> OE it's a bit like Gentoo
May 25 09:24:56 <greguu> that is a far fetched comparison
May 25 09:24:58 <ant_work> bitbake origins from portage
May 25 09:25:03 <ant_work> long long ago
May 25 09:25:05 <greguu> but I get your drift :_)
May 25 09:25:54 <ant_work> these are the basics anyway
May 25 09:25:55 <ant_work> https://www.openembedded.org/wiki/OE-Core_Standalone_Setup
May 25 09:26:16 <ant_work> then one must add the BSP layer (for zaurus it is meta-handheld)
May 25 09:26:53 <ant_work> greguu, just imagine one package and you'll fiond a recipe for it
May 25 09:26:54 <ant_work> https://layers.openembedded.org/layerindex/branch/master/layers/
May 25 09:27:12 <greguu> ah, same with arch AUR
May 25 09:27:17 <greguu> endless
May 25 09:27:17 <ant_work> there are now also scripts to create recipes from the sources in auomatic way
May 25 09:27:43 <greguu> I am just keen on musl and busybox, keep it low MEM
May 25 09:28:00 <greguu> this can be done with Arch too, keepin their repo
May 25 09:28:11 <greguu> who will look after the packages ?
May 25 09:28:16 <greguu> not me
May 25 09:28:17 <ant_work> musl is well supported: one of the main devs is OE dev
May 25 09:28:29 <greguu> arch has a team of dedicated volunteers
May 25 09:28:43 <ant_work> here is the best part: the Yocto project involves companies like Intel, Mentor, ...
May 25 09:29:00 <ant_work> they pay people to develop OE/Yocto for their boards
May 25 09:29:14 <greguu> bitcoin ?
May 25 09:29:26 <ant_work> no, employeed
May 25 09:29:37 <greguu> I alreay have a job
May 25 09:29:42 <ant_work> same here :)
May 25 09:29:56 <ant_work> I mean there is a solid base behind
May 25 09:29:57 <greguu> some bitcoin on the side, ok
May 25 09:30:22 <greguu> ant_work: solid base....?
May 25 09:30:23 <ant_work> in two words, Yocto tries to be OE 'commercial'
May 25 09:30:34 <greguu> seen this before
May 25 09:30:56 <ant_work> https://www.yoctoproject.org/ecosystem
May 25 09:31:22 <ant_work> sponsored by the Linux Foundation
May 25 09:31:26 <greguu> good ethics, but I would not join a commercial project for a dead platform
May 25 09:31:44 <greguu> I do this just for fun
May 25 09:32:07 <greguu> what is their current targetS ?
May 25 09:32:15 <ant_work> for me is an hobby as well
May 25 09:32:30 <greguu> well lets keep it that way . for the Zaurus sake of it
May 25 09:32:38 <ant_work> TV, set top boxes, servers, ...
May 25 09:32:45 <ant_work> there are big co.s
May 25 09:33:17 <greguu> that is mostly consumer devices ?
May 25 09:33:24 <ant_work> yes
May 25 09:33:26 <greguu> no enterpise stuff
May 25 09:33:42 <ant_work> dunno, maybe
May 25 09:34:04 <greguu> I would join a opensource company that can squeeze their foot in the enterprise door, foor good
May 25 09:34:48 <ant_work> Yocto was the try to package the goods from OE with more support, mainainers, stable releases, etc
May 25 09:34:50 <greguu> I do work at enterpise full time, and more opensource is needed, and cost savings are a big factor
May 25 09:35:11 <ant_work> have you seen the brandds I'm talking about?
May 25 09:35:37 <greguu> well I do work for 5 letter aviation/aerospace companay
May 25 09:36:18 <ant_work> he he..SanDisk joined.. :)
May 25 09:36:22 <greguu> haha
May 25 09:36:33 <ant_work> we can ask free samples to b0rk
May 25 09:36:36 <greguu> it is not about aht
May 25 09:37:00 <greguu> the Zaurus is a gimick we keep alive
May 25 09:37:18 <greguu> what else can we do with that skill ?
May 25 09:38:09 <greguu> there is not a big fanbase anymore
May 25 09:38:28 <ant_work> surely not
May 25 09:38:48 <ant_work> we lost many with the beagleboard and co.
May 25 09:38:58 <ant_work> dev boards appeared and were cheap
May 25 09:39:14 <greguu> indeed, the Iphone was also a factor
May 25 09:39:23 <ant_work> but still Z has keyboard and screen, unvaluable
May 25 09:39:39 <ant_work> and has a shell :)
May 25 09:40:30 <ant_work> I personally liked debugging on it
May 25 09:41:24 <greguu> I use it, play with it and run latest kernels on it.. but if it breaks, I am not sure I will get another one..
May 25 09:41:49 <greguu> this week I missed an auction
May 25 09:42:27 <greguu> sharp sould make a new one
May 25 09:44:36 <greguu> but be asured, the Zaurus SL series will go in history as classic linux PDA's that at that tiem beat the marked years ahead
May 25 09:55:05 <VartiWork> personally, I'll look if the Gemini will be worth having
May 25 09:56:44 <VartiWork> I can accepts some limitations or drawbacks on a similar device, but not too many... I realised that GPD Win's keyboard was a showstopper for me
May 25 09:58:11 <VartiWork> if I'll end up having a Gemini, I'll probably dedicate most of the time on it, and use my Zaurus only for some occasional tinkering
May 25 09:59:34 <greguu> 19:57:33     VartiWork | but what's the difference between your frankenstein kexec and these? https://github.com/LinuxPDA/linux-kexecboot/tree/master/zaurus/kernel-2.6.2x
May 25 09:59:35 <VartiWork> I'd like also to open a Gemini section on OESF, and see if it gains traction
May 25 09:59:48 <VartiWork> ignore that question of mine
May 25 09:59:54 <greguu> VartiWork: The difference is the kexecboot part not more
May 25 10:00:02 <greguu> ok:)
May 25 10:00:26 <VartiWork> yep, I realised only later than you already explained that :)
May 25 10:00:58 <VartiWork> [09:56] <greguu> ant_work: correct, the 2.6 frankenstein is just  https://github.com/LinuxPDA/linux-kexecboot/tree/master/zaurus/kernel-2.6.2x plus kexecboot 0.6
May 25 10:17:42 * greguu gone for the day
May 25 10:24:54 <VartiWork> nite greguu
May 25 13:13:09 <ant_work> VartiWork, I might have found the error
May 25 13:13:13 <ant_work> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/136072.html
May 25 13:13:25 <ant_work> seems akita suffers after 3.7
May 25 13:13:36 <ant_work> that explains my working 3.2
May 25 13:14:41 <ant_work> I am trying to see if this is solved by now but I bet no
May 25 13:16:24 <ant_work> disable
May 25 13:16:24 <ant_work>  CONFIG_MACH_BORZOI...just that?
May 25 13:17:38 <ant_work> btw here we have the luck RMK (Russell King) explains the asm distinguishing akita and borzoi
May 25 13:18:10 <ant_work> RMK is the ARM godfather
May 25 13:26:21 <ant_work> seem scommit is already in kernel...
May 25 13:26:24 <ant_work> 	1ecec696c8bb9b4cefb09495d81d081d1c81b578
May 25 13:47:23 <ant_work> in 3.8
May 25 13:47:24 <ant_work> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm/include/asm/assembler.h?h=v3.8
May 25 13:47:48 <ant_work> bbl
May 25 20:20:56 <ant_home> Varti, let me check what happened to akita after dromede leaved
May 25 20:22:16 <ant_home> seems there are subtle issues: the akita gpio expander can sleep..probably is not awake on cold boot but is ok after kexec
May 25 20:22:44 <ant_home> I am checking wether these are fixed (in theory) or not...
May 25 20:23:03 <ant_home> one commit seems still pending because of maintainer's death :/
May 25 20:50:22 <Varti> great find ant_home
May 25 20:51:03 <Varti> looks like it might be that the issue... explains the fail I'm seeing during the boot too
May 25 20:51:34 <Varti> there seem to have been a lot of work behind this issue
May 25 20:51:59 <Varti> damn, sorry about that maintainer :/
May 25 20:52:59 <Varti> I was lucky (or unlucky) that I have the only model affected by this issue, so I have been able to reproduce it
May 25 20:53:46 <Varti> I have contacted dromede via mail a year ago or so, he might still help us with committing this fix
May 25 20:57:55 <ant_home> that second one: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/046955.html
May 25 20:58:48 <ant_home> was not committed and in 2012
May 25 20:58:49 <ant_home> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/136075.html
May 25 20:59:40 <ant_home> we must check the two issues are fixed: 1) machine id is ok, gpio cansleep
May 25 21:01:14 <ant_home> about 1), iirc greguu compiled for akita+spitz only, no borzoi
May 25 21:27:48 <Varti> ok
May 25 21:40:05 <ant_home> sorry, I am on #mtd trying to push my patch
May 25 21:40:42 <ant_home> I got finally review and have to do little changes
May 25 21:41:27 <ant_home> let greguu wake up and read the logs, he'll surely catch up
May 25 21:41:39 <ant_home> I am almost asleep..gotta go
May 25 21:41:44 <ant_home> good night
**** ENDING LOGGING AT Fri May 26 03:00:03 2017