[Gta04-owner] Second Debian Status Update

H. Nikolaus Schaller hns at goldelico.com
Tue Sep 19 11:28:36 CEST 2017

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.

>>> - 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).

> 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


More information about the Gta04-owner mailing list