[Gta04-owner] Upstream Replicant 4.2 support for GTA04

Fri Feb 28 20:49:07 CET 2014

Le vendredi 28 février 2014 à 13:47 +0100, Dr. H. Nikolaus Schaller a
écrit :
> Am 28.02.2014 um 13:16 schrieb Lukas Maerdian:
> 
> > On 28.02.2014 11:44 UTC+0100, Dr. H. Nikolaus Schaller wrote:
> >> 
> >> Am 28.02.2014 um 10:58 schrieb Paul Kocialkowski:
> >> 
> >>> As I wrote in my previous message, I'm giving the GTA04 a new try at
> >>> Replicant 4.2. I see that you have been busy during the time I retired
> >>> and I'm glad some progress was made, especially on the kernel.
> >>> 
> >>> I just tried Alexandre's Replicant 4.2 images and the suspend/resume
> >>> issues seem to have vanished.
> >>> 
> >>> However, I encountered some issues related to the kernel:
> >>> * OTG seems to work fine but refuses to configure USB flash drivers
> >>> since they apparently ask too much current: this doesn't look like
> >>> normal behavior.
> >> 
> >> Well, the official limit of the OTG port is 100mA. In practice it may be
> >> 200 mA.
> >> 
> >>> * The battery driver seems not to work (the sysfs nodes all return
> >>> errors). I suspect this is because of the 1-wire interface.
> >> 
> >> Yes, there is some known bug. Lukas is already looking for it.
> > 
> > I'm usually working and testing on the Goldelico Letux-3704 and not on
> > the GTA04/Letux-2804. That devices uses the twl4020-madc battery driver
> > instead of the bq27000. I'll have to check what's wrong with bq27000.
> > AFAIR it was working on our Replicant-4.0 where the device was detected
> > by a shell script and the corresponding battery driver was loaded.
> > My assumption is, that this script is not working in Replicant-4.2 and
> > the twl4030-madc driver is loaded by default.
> > 
> >>> * ADB driver seems to crash at poweroff
> >>> * Plugging the USB cable before the device is booted made my host
> >>> computer crash several times, with kernel panic
> >>> * I'm not sure audio worked all the time after suspend/resume
> >>> 
> >>> These are just quick notes, we should look deeper in details for all
> >>> these points.
> > 
> > Yes, I didn't look into these details either, as it was working well
> > enough for my development purposes when plugging the USB connector after
> > the device was booted. I don't have speakers/mic on the Letux 3704, so I
> > didn't look into sound handling at all.
> > 
> >>> I am going to start over the Replicant 4.2 bringup on my own since I
> >>> dislike some of the changes that were made on the goldelico replicant
> >>> trees:
> >>> * The Replicant logo in the bootanimation is too small, it should have
> >>> 420px height.
> >>> * GTA04 model detection is unacceptable. The kernel should provide a
> >>> sysfs node with that info or something like that, but in no case should
> >>> the userspace have to parse dmesg.
> >> 
> >> I agree that it never should parse dmesg. (I am not aware that it is really
> >> the case) If we do it, it is clearly a mistake.
> >> 
> >> The official GTA04 device detection should go through /proc/cmdline -
> >> or even better (future) through /proc/device-tree/model
> > 
> > AFAIK we're not parsing dmesg anywhere, but check /proc/cmdline for the
> > model value provided by U-Boot.
> > I did this in a script, as it was the fastest and easiest way to do.
> > 
> >>> * I don't want the single partition approach in Replicant.
> >> 
> >> Why not?
> >> 
> >>> * The Wi-Fi firmwares should not be in the source code
> >> 
> >> Ok. I agree. We keep it there for convenience at least during development.
> > 
> > Yep. The best way would be to provide an APK which contains the
> > Wifi-firmware, I guess. I didn't put effort into this direction, yet,
> > due to the early state of development.
> > 
> >>> I see two ways of correctly performing GTA04 version detection by
> >>> userspace. On the kernel side, they involve having a sysfs node that
> >>> will provide either a number or a string that matches a particular gta04
> >>> variant.
> >> 
> >> No new /sys node. Because we never get that upstream. The 
> >> /proc/device-tree/model is the canonical way to do it in the future.
> >> 
> >>> Then, the modules should access that information and behave
> >>> accordingly.
> >> 
> >> Yes, it should be /proc/cmdline or /proc/device-tree/model
> > 
> > Paul, would it be OK to have the model name provided by /proc/cmdline
> > and/or /proc/device-tree/model? /sys or /proc doesn't make a big
> > difference...
> > 
> >>> For accessing the information, modules could either read the sysfs node
> >>> directly or communicate by a gta04-specific daemon (gta04d or goldelicod
> >>> perhaps) that reads the string and returns it to the module upon request
> >>> through a unix socket.
> >> 
> >> Much too complex. Please don't introduce new daemons someone has to
> >> maintain...
> > 
> > I do not yet see the big advantage of having a C daemon instead of a
> > shell script handle the model differences. Right now this is just
> > loading the correct battery module...
> > 
> > But if the daemon is the way to go, I'd be OK with it, as it doesn't
> > need to be maintained a lot, once written, and could live in the
> > GTA04-device overlay in the replicant tree, similar to liblights.
> > 
> >>> The advantage of having a gta04-specific daemon (called at early-init)
> >>> is that it also makes it possible to perform all the variant-specific
> >>> actions:
> >>> * load the correct battery driver
> >>> * swap the correct initlogo.rle/bootanimation.zip for each resolution
> >> 
> >>> These actions could also be done by a single script (the way it's
> >>> currently done on the goldelico tree), hence without the possibility of
> >>> having a socket. However, I would prefer having a daemon cleanly written
> >>> in C code.
> >> 
> >> What is bad with a script? It is simple and easily maintainable. And executed
> >> only once. So IMHO no need to use C and a complier to achieve what we
> >> can do directly.
> > 
> > Hmm, what is the big advantage of having a socket?
> > 
> >>> On the single partition approach: I understand this is how you like to
> >>> do things on regular GNU/Linux systems, but this is Android. It is
> >>> mandatory to have separate partitions for /system, /data, /cache and
> >>> having an initramfs.
> >> 
> >>> Android is built around with that assumption and
> >>> not following this scheme will draw incompatibilities. For instance,
> >>> features such as encrypting the data partition will be unavailable as
> >>> well as wiping the data partition will be unavailable.
> >> 
> >> Is there a document describing that in more detail? I have only found tools
> >> that manage partitions - but if we haven't we don't need the tools.
> >> 
> >>> I also worked on bringing recovery support (which is something everyone
> >>> who installed a community Android version on an Android phone knows
> >>> about). It's basically a single binary, packed into an initramfs that
> >>> will perform actions such as installing a system zip, wiping /data
> >>> (factory reset), making a backup of the system, restoring the backup,
> >>> etc. Again, that won't work if we don't have separate partition
> >>> for /system, /data and /cache.
> >> 
> >> Why does this need separate partitions? Isn't it sufficient that these directories
> >> exist and point to something reasonable? Is it required that they appear in
> >> the mount table or do all tools just access them through their file name?
> >> 
> >> Can recovery be simplified if we don't have separate partitions and no
> >> initramfs?
> >> 
> >>> On top of that, it doesn't seem outrageous to me to require the whole
> >>> sdcard for installing Replicant. That's what it takes.
> >> 
> >> No - that is what we took a lot of work to get rid of having U-Boot on every
> >> SD card. Booting is booting - for any system. Therefore Replicant should
> >> not do its own story... Even if there is some reason behind.
> >> 
> >>> I also prefer to go with my own minimalistic boot.scr that handles
> >>> recovery booting and the Android kernel names (boot.img and
> >>> recovery.img).
> >>> 
> >>> That's all for now, feel free to share any remark/suggestion.
> > 
> > IMHO most of your changes are acceptable, at least for the official
> > Replicant version. It should then be easily possible to have go
> > Goldelico-Variant, which provides a single partition rootfs without an
> > initrd.
> > 
> > But PLEASE, don't mess with the boot.scr, which is located in the users
> > NAND flash. This will break the users boot environment, if they want to
> > switch between Android/Replicant and GNU/Linux systems. We had a lot of
> > those problems with Replicant-2.3.
> > 
> > You can still tweak the boot process to your needs, e.g. through
> > bootargs.scr, which will be executed by the default uboot+boot.scr from
> > the NAND, see: http://projects.goldelico.com/p/gta04-uboot/page/Usage/
> > 
> > Just please don't flash/override the users uboot+bootenv in NAND.
> 
> Yes, this should never be done by any distribution - except the one
> for flashing a new boot system.

I totally agree here. If I did that with Replicant 2.3, it was clearly a
mistake. What I'm suggesting is having the bootloaders on the first
sdcard partition (/boot) as well as boot.scr, knowing that the
bootloaders won't be executed unless AUX is pressed but boot.scr is
executed by the NAND u-boot, which suits me just fine.

> For details how it should work in the future (device tree based kernels),
> please see:
> 
> http://download.goldelico.com/gta04/files/Device_Tree_Migration.pdf
> 
> This document also discusses partitioning and model specific user-space
> configs.

Thanks for putting this up!

> > 
> >> Well, I see that there are some fundamentally conflicting ideas how the
> >> future should look like (single partition vs. multi-partition, initramfs, make
> >> simple solutions vs. complex ones) which may make it difficult to merge
> >> the efforts back into a single one.
> >> 
> >> But we have enough time to let things evolve. And you are free to
> >> do it differently from us. If they are good (for our purposes) we will take
> >> them of course.
> >> 
> >>> My next steps are building a full system with my code, then publishing
> >>> all the source once the state is as good as 4.0 and then I'll work on
> >>> particular hardware features.
> >> 
> >> Great.
> > 
> > I think the biggest difference is the single partition rootfs. Maybe we
> > should go into two directions with this for now and cooperate with all
> > the other work.
> > 
> > Please send a short heads up mail to this list, once you are happy with
> > what you have prepared for the GTA04, so I can check and reintegrate
> > some stuff.
> > 
> > The work we have done is all public here:
> > GTA04 device overlay:
> > http://git.goldelico.com/?p=gta04-replicant-device.git;a=shortlog;h=refs/heads/replicant-4.2
> > GTA04 kernel overlay:
> > http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/3.12-replicant4
> > 
> > I'm happy you're interested in the GTA04 again and hope we can soon
> > provide users with your free version of Android on our open hardware!
> > 
> > Regards,
> >  Lukas
> > 
> > _______________________________________________
> > Gta04-owner mailing list
> > Gta04-owner at goldelico.com
> > http://lists.goldelico.com/mailman/listinfo/gta04-owner
> 
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner at goldelico.com
> http://lists.goldelico.com/mailman/listinfo/gta04-owner

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution

Website: http://www.replicant.us/
Redmine: http://redmine.replicant.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20140228/3bb20727/attachment.bin>