[Gta04-owner] Upstream Replicant 4.2 support for GTA04

Paul Kocialkowski contact at paulk.fr
Fri Feb 28 20:46:43 CET 2014


Le vendredi 28 février 2014 à 13:16 +0100, Lukas Maerdian a écrit :
> 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.

IIRC the module was probed, but the sysfs interfaces returned errors. I
remember having an issue with the 1-wire interface that caused similar
results, back when I was trying to adapt a 3rd party kernel for the
gta04.

If it's not fixed by next week, I suppose it's one of the first things
I'll look into.

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

Ah ok, good to know. Then I'll have to investigate on that side too.
Note that headset detection also has to be adapted for Android.

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

Ah you're right, my bad. I read the script quickly and cmdline appeared
to me as dmesg (IIRC dmesg also prints something about the gta04
revision).

cmdline looks like an acceptable solution. I understand sysfs will never
make it to mainline.

> >> * 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 doubt an apk will do it (these are simply java applications), though a
recovery update zip would do. On the other hand, simply installing them
with adb push would be considerably easier.

The path is also wrong, it should be /system/vendor/firmware, in order
to have a clear separation between proprietary software and the rest and
thus make it easier to get rid of them afterwards.

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

/proc/device-tree/model would be best. Is it there yet? I'm not sure the
kernel I built was using device tree.

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

I just don't see the advantage of a script over proper C code.

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

Indeed, that would be the plan.

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

Avoid code duplication with implementing the same parsing function in
every module. Come to think of it, I think a library would be the most
elegant solution, with a one-shot program that would handle the startup
stuff like moving the proper initlogo.rle and loading the correct
battery driver.

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

One advantage of having a dedicated boot.scr is that it doesn't mess
with the NAND at all (i.e., the NAND boot.scr doesn't need to have
special adaptation for Replicant) and the sdcard boot.scr holds only the
instructions to properly boot Replicant and recovery. Hence, when the
user removes the sdcard, it boots to NAND normally and when the sdcard
is inserted, it loads Replicant. That makes sense to me.

Note that I am not proposing for anything to be installed in NAND.
Neither the kernel nor the boot.scr should be written to NAND: rather,
it should all stay in the /boot partition.

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

Indeed, I do not intend to do that. (For the record, what I did for
Replicant 2.3 messed up by boot process at some point too.)

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

Indeed. I think that the most important part to have is hardware in
userspace support and a robust kernel.

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

That will probably come next week's Saturday.

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

That's the plan! I'm glad that you took over development and got as far
as having Wi-Fi working on 4.0!

-- 
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/78f918ff/attachment-0001.bin>


More information about the Gta04-owner mailing list