[Gta04-owner] Second Debian Status Update

H. Nikolaus Schaller hns at goldelico.com
Tue Sep 19 09:38:39 CEST 2017


Hi Josua,

> Am 18.09.2017 um 22:25 schrieb Josua Mayer <josua.mayer97 at gmail.com>:
> 
> Greetings everybody,
> 
> After a long pause I have yet again found some freetime to tinker with
> the gta04.

Nice!

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

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.

> 
> Testing:
> - currently on kernel 4.12.6
> - charging doesn't work

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.

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.

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

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

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

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

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

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.

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

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.

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.

> 
> best regards
> Josua Mayer

BR and thanks,
Nikolaus



More information about the Gta04-owner mailing list