[Gta04-owner] Kernel 3.16-rc2

Dr. H. Nikolaus Schaller hns at goldelico.com
Fri Jun 27 16:18:57 CEST 2014

here an additional answer.

Am 27.06.2014 um 09:23 schrieb Dr. H. Nikolaus Schaller:

>> I spent some more time with this tonight.  I don't see an sd image in
>> http://download.goldelico.com/gta04/20140610-GTA04-beta-3.15.0-wheezy-7.5/
> Ah, there is no primitive SD image (I have to find out why the file got lost), but the makesd script.

Ok, we had upgraded the build system a while ago but for unremembered reasons it was
not 100% perfectly finished and documented.

The new approach is that you will always find the "production images" for unbricking and
reflashing u-boot etc. here:


Note that this currently is a 3.12.7 kernel. This is the latest one that runs well enough for this purpose.

Then, we have the (no-bootloader) Debian images (to be installed in a single partition):


There is always a basic Debian image without GUI and without (!) kernel:


and a LXDE image (which can be installed as a single partition stand-alone
or is used for the "production image" and fallback in NAND):


This LXDE image contains the latest stable kernel and therefore can simply be copied
onto some etx2/3/4 partition and should then boot.

It is assembled from components by this makesd script:


Next we have the Replicant root file systems (single partition):


And finally the system packages incl. sources (but not including any rootfs):


The newer ones will no longer contain the "production images", but the makesd
file to create one.

So you should reflash u-boot (red screen etc.) using the latest production image
you find on:


Then you can use the rootfs from


and just replace the uImage, bootargs.scr, *.dtb files. And don't forget to install the
new kernel modules (usually a new kernel boots without depmod -a)...

Hope this does not increase the confusion (although it is very likely and would
be understandable)...

This process isn't really optimally streamlined yet, because there are many
dependencies when handling all these variants. And moving files around
isn't very easy because there are external deep links onto the download server...

Let me try to draw the flow from sources to binary SD images and rootfs tarballs:

1. new code (e.g. 3.16-rc2) and sources => gta04/unstable/src (upgrades ~weekly)

2. gta04/unstable/src => gta04/unstable/uImage etc. (compiled)

3. gta04/unstable => gta04/latest/ (when tested and stable enough to build a production image on it)

4. gta04/debian/latest-debian.tbz + gta04/lastest/uImage + apt-get-install lxde  => gta04/debian/latest-lxde.tbz (unpack to partition on SD)
4a. gta04/debian/latest-debian.tbz + apt-get upgrade => gta04/debian/latest-debian.tbz (rolling upgrade every 2-3 months)

5. gta04/debian/latest-lxde.tbz + gta04/lastest/MLO+uBoot+uImage => gta04/production (dual partition SD images for NAND)
5a. the same for GTA04b2 (Letux3704)
5b. the same for GTA04b3 (Letux7004)
5c. the same for GTA04b7 (Neo900)

6. replicant sources -> replicant/4.2/unstable-replicant.tbz (compiled from scratch directly from the most recent git sources)
6a. replicant/4.2/latest-replicant.tbz (when tested to be good)

The idea for next steps is:

7. gta04/debian//latest-lxde.tbz  apt-get-install lxde- qtmoko+  => gta04/qtmoko/latest-qtmoko.tbz (unpack to partition on SD)
8. gta04/debian//latest-lxde.tbz  apt-get-install lxde- quantumstep+  => gta04/qtmoko/latest-quantumstep.tgz (unpack to partition on SD)

All this is to support the new device tree based way of handling variant specific (and variant agnostic) SD images:



More information about the Gta04-owner mailing list