[Gta04-owner] Second Debian Status Update

Josua Mayer josua.mayer97 at gmail.com
Tue Sep 19 11:48:25 CEST 2017

Hi Nikolaus,

Am 19.09.2017 um 11:28 schrieb H. Nikolaus Schaller:
> Hi Josua,
>> Am 19.09.2017 um 11:19 schrieb Josua Mayer <josua.mayer97 at gmail.com>:
>> Hi Nikolaus,
>> Am 19.09.2017 um 09:38 schrieb H. Nikolaus Schaller:
>>>> So first I'd like to revisit the current status (tested on an A4):
>>>> Stretch:
>>>> No changes from last update
>>>> - integration with flash-kernel package is missing
>>>> - charging doesn't work (as expected)
>>>>  cat /sys/class/power_supply/twl4030_ac/status
>>>>  Not charging
>>>> - WiFi doesn't work. Hmm. Attaching a log of booting stretch with the
>>>> 4.9.0-3 Debian kernel.
>> For the A4, WiFi is a regression from Debian package 4.9.0-1-armmp which
>> had it working back in February!
>> Maybe easiest is opening a Debian bug about it. But I am unsure if we
>> want to, considering that it is pretty useless even as a headless
>> machine as long as charging has trouble.
>>> Well, it looks as if you are using the Debian mainline kernel and this
>>> is far behind supporting everyhing.
>>> The problem is that many of the Letux kernel patches are not (yet) properly 
>>> upstreamed. We have ca. 150 files with smaller or bigger differences and
>>> ca. 50% are relevant foe GTA04.
>> Yes. So this is not the one we want to improve beyond what was there in
>> 4.9.0.
>>>> Testing:
>>>> - currently on kernel 4.12.6
>>>> - charging doesn't work
>> - Display stays white
>>> Well, that should work since AFAIK we have no additional patches or
>>> hacks for upstream for twl4030-charging. At least I am not aware that
>>> we have anything different...
>>> Does the ethernet-gadget work? In my experiments it is more likely to
>>> have charging working, but no ethernet gadget.
>> [   40.255889] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
>> [   40.262969] g_ether gadget: g_ether ready
>> [   40.359313] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
>> Didn't try to use it though (I have to go look for my usb cable).
>>> A general source of trouble seems to be to boot the kernel with USB
>>> plugged in. If you boot first and then plug in it did work always for me.
>> So all my experiments right now have been done with the wall-charger.
>> So I tried booting the Debian 4.12.0-1 without power plugged in, then
>> after login prompt appeared I plugged it back in, and still nothing happens
>>>> experimental linux-image-4.13.0-trunk-armmp_4.13.1-1~exp1_armhf.deb:
>>>> - charging doesn't work here either
>>>>  Any ideas why?
>>>> - WiFi doesn't work
>> Plugged in power only after login-prompt appeared: Same story, BUT: Q:
>> Did I check the wrong file?
>> cat /sys/class/power_supply/twl4030_usb/status
>> Charging
>> So ..... maybe it's all good? I have no idea.
>> There is no /sys/class/battery entry :(
> Yes, there isn't. The battery has no driver and no /sysfs node.
> Justa charger node and a fuel gauge node.
>> - Display stays white
>>>>  Neither does it work on the A5, but there not even the wl18xx module
>>>> comes up on its own.
>>> Wl18xx needs updates in the device tree which are not upstream and therefore
>>> not in any Debian kernel (unless we build our own).
>> So as long as that is missing I'll only check the status of the A4 with
>> libertas wireless.
>>>> This is the one I think we should work on fixing, if it is just a matter
>>>> of missing kernel config options.
>>> Yes, it might additionally be a kernel misconfig.
>> Attached a boot-log on the A4. Maybe it has a hint why WiFi doesn't
>> work? And the display?
>> I added loglevel=7 to cmdline (to get debug output but *not* from
>> systemd); it didn't appear to have any effect on the detail level of
>> console messages.
>> I don't know how useful it is to figure out why this stuff doesn't work
>> on Debian.
>> My goal was to reach a point where the standard Debian would boot,
>> charge and connect to a network via WiFi. But right now that feels
>> farther away than back in February.
>>>> There is little need for thoroughly
>>>> testing the earlier kernel packages.
>>>> To Do:
>>>> - figure out nand flash partitionining (see below)
>>>> - update the big gta04 boot.txt to properly integrate Distro-Boot feature
>>>> - integrate with flash-kernel - see #871792
>>>> - try making the debian kernel package smaller - see #772628 for one idea
>>>> - is it feasible to get the required patchsets that made it into 4.13,
>>>> included in the Stretch kernel package?
>>>> #871792: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871792
>>>> #772628: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772628
>>>> And now a few notes on what I mean by figuring out nand flash:
>>>> - who figures out the root= argument: u-boot? Debian? flash-kernel package?
>>> u-boot (default for bootargs) or boot.scr. In my experience all the standard
>>> methods are quite fragile and limited. This is why we have our own.
>> Sure.
>>>> - where does the kernel come from? the kernel partition in nand-flash?
>>>> If so, is it an uImage or a zImage?
>>> It depends on which boot command the boot script calls (boot, bootm, bootz).
>>> The Letux-OS uses uImage:
>>> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/flash-nand;h=3bbadda919f6405c6d9b68e79566c785ea620ea8;hb=c4729e229fa3d61c3937865972fa0f57058830c8#l237
>>>> - where does the initrd come from? How does u-boot know its name on
>>>> filesystem, or location in flash?
>>> IMHO it should be compiled into the kernel image.
>>> If not, it can be on any file system that the kernel understands. AFAIR
>>> it is not loaded at all by u-boot but in the early stages of kernel startup
>>> by the kernel.
>> Does this work with a typical debian initrd size of 16MB?
>> I guess this can be reduced, but probably requires quite some effort.
> Hm. Most likely no. AFAIR we have 6MB kernel partition in NAND - but that
> is quite arbitrary and a matter of having matching tables in U-Boot and Device-Tree.
Not something we want to change I think. We need all the rootfs space we
can get.
>>>> - should u-boot just load a boot.scr or extlinux.conf from the rootfs in
>>>> nand? That might mean kernel and initrd are both in the rootfs.
>>> This requires that U-Boot can understand the file system of the NAND partition
>>> used for kernel and rootfs, e.g. ubifs.
>> I see. That is pretty unlikely.
>>> In Letux-OS u-boot only uses direct NAND, FAT and ext. And since it only
>>> loads the kernel directly from NAND it does not have to know anything about
>>> the format of the rootfs partition.
>>>> - And finally a short-coming of flash-kernel package: It does understand
>>>> putting an uImage to nand-flash, but it does *not* differentiate where
>>>> the rootfs is.
>>> They can be in separate locations.
>> By that I mean: One database entry in flash-kernel for every device
>> "model" (from DeviceTree).
>> And then exactly one boot method. It can be boot-script on rootfs, or
>> uImage in nand flash.
>> I couldn't find any other supported methods such as perhaps extlinux.conf.
>> Why we need flash-kernel?
>> - It takes care of copying a DeviceTree Blob from
>> /usr/lib/<versioned-kernel-folder> to /boot;
>>   When using the Debian kernel, this would be a pain to copy by hand.
>>   Debian does have symlinks to latest kernel image, and initrd at /, but
>> sadly none pointing at the location of the latest DTBs in the rootfs.
>> - It would take care of replacing the uImage in nand flash.
>>>>  So either we get a database entry into flash-kernel for uImage in nand
>>>> flash, or we get an entry in there for generating a boot.scr.
>>>>  Note that this is the real reason for all questions above!
>>>> I would propose this solution:
>>>> - remove kernel partition in favor of a slightly bigger rootfs
>>> this assumes that U-Boot can load the kernel from the rootfs in flash (file system)
>> ^^
>>>> - fetch boot-script, kernel and initrd from whatever filesystem is on there
>>>> - let u-boot come up with the bootargs, including root= set to whatever
>>>> parttiion is being booted
>>>> This way the process looks the same for nand flash and microSD, and the
>>>> flash-kernel entry would be sane.
>>>> What are your opinions here?
>>>> Any ideas how Debian should be installed in nand flash, and how
>>>> flash-kernel package should take care of updates?
>>> Well, my opinion is clear (although it is something you might not want to hear :): 
>>> 	focus on Debian rootfs topics. Ignore Debian kernel/u-Boot flashing etc.
>>> The reason is that we have a quite mature and tested setup for flashing and
>>> booting up to the point where some rootfs is loaded. This is very universal and
>>> users can even choose between different SD partitions with different kernels and
>>> root file systems.
>>> One of them can be Debian. Another can be Replicant. Or something else.
>>> And the flash-nand tool can copy a running Debian to flash. Hm. Maybe we should
>>> try to package more of the Letux tools (flash-nand, makesd) into Debian...
>>> So this all seems to reinvent a lot of things by trying to use the standard
>>> Debian toolset for a task that is already solved well.
>> We could ignore nand-flash in the flash-kernel package, and have it only
>> work with mmc.
>>> Of course it is a nice exercise to find out how and if it works. And gives a
>>> lot of moments and pleasure for learning. But I don't see a big step forwards
>>> in working on that early stage boot.
>> Ideally this work would lead to a moment where we can take a
>> debian-installer sdcard as is, put it on the microsd and have it install
>> to flash without hickup.
> Yes, that would be nice! Except that it would not be compatible with other
> rootfs (AFAIK it would not even be able to boot a Replicant SD).
That's not how I'd like to see it.
Say we treat U-Boot as firmware, Debian aint touching it.
So U-Boot is installed in nand flash; then it runs your boot.scr,
presenting a menu;
And then whatever boot option has been chosen, chainload a boot.scr on
the selected partition.
While doing that we should be setting the expected distro-boot
variables, and the debian boot-script will be happy.
>> In the last months I have figured out that the only things that need
>> figuring out are:
>> - flash-kernel (generating a boot.scr, and copying DTBs to /boot)
>> - running the default debian boot.scr (which relies on a few distro-boot
>> variables to be set such as boot_type, and boot_part, and does not
>> override bootargs afaik)
>> - Have a Debian release kernel with working wifi that does not drain the
>> battery during install
>> For the last two we are almost there!
>>> Much more missing is user space and GUI support, not only for GTA04 but all
>>> mobile devices.
>>>> On another note: What is my time best spent on now?
>>>> Going through the FSO packages and checking why they do(don't) currently
>>>> work on Debian, and are not even properly in testing?
>>> Yes! Would be of benefit for many other devices as well.
>>>> Revisit QtMoko?
>>> Yes! Would be of benefit for many other devices as well.
>> I shall see which one to look at. Anyone else with an opinion on this
>> last question?
>>>> best regards
>>>> Josua Mayer
>>> BR and thanks,
>>> Nikolaus
> BR,
> Nikolaus
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner at goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
- Josua Mayer

More information about the Gta04-owner mailing list