[Gta04-owner] QtMoko snapshot

H. Nikolaus Schaller hns at goldelico.com
Sun Dec 31 17:05:56 CET 2017

> Am 31.12.2017 um 15:46 schrieb Andreas Kemnade <andreas at kemnade.info>:
> On Sun, 31 Dec 2017 12:31:41 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> Also if we are going down the dfu road of installing/updating
>>> bootloaders, those mistakes would probably be avoided for a big part.
>>> Reason: If we boot spl/uboot via usb and it is the wrong one it will
>>> in most circumstances not be able to flash nand.
>>> Additionally, we can do some matching on usb product ids or device
>>> names.
>> A general problem is that the dfu approach can be made working only
>> for only a small group of devices that are currently supported by
>> Letux OS (for a current list see: <http://projects.goldelico.com/p/letux/>).
> Why? Don't they all have musb inside?

No. They have different USB controllers. And not all devices can be
operated through pserial. Or you can't boot through USB. Every
SoC generation is different :( And even if it could do, it might
still not be available (depends on boot mode selection of the hardware).

Well, on the Pyra we would luckily have it (sequence: SD-Card => eMMC => USB).

> What are the obstacles?

Another one is that some devices ONLY have SD card and no flash, so they
always need an SD card with proper FAT partition. You can't setup such
partitions through USB, so the card must be formatted through a host anyways.
Installing files in that step is done by makesd as well and does not
need a separate DFU step.

>> makesd works for all of them in the same way and even if the device
>> itself is bricked.
> Well usb does work in that situation also for unbricking devices.
> It does not need a working MLO/SPL/uboot whatever on that device.

Only if the Boot ROM supports USB boot.

> I do not think makesd should be fully replaced. Now I am thinking about
> whether the task should be clearly splitted in
> a) unbricking/install/replace bootloader
> b) installing operating systems
> so that you do not accidently touch the bootloader as Thierry did.

AFAIR he wanted to update the boot loader so he touched it...

> For
> a) I think the dfu method is a nice choice, does not need a separate sd
>   card, but maybe putting all rescue paths here into a separate
>   letux-rescue program (like usb, serial, uboot flash sd cards)

On the other hand how often does this happen? In my memory there has been
ca. 1 rescue requests every 2 years. It looks as if most GTA04 users do not
often touch the boot loader. Or if they do, they know what they do...

> b) here clearly does makesd a good job, it makes no sense to fully
>   replace it.
>   It could be even better if we set device into mass storage gadget
>   mode. So it can access the sd card in the device directly.
>   A way to achieve that would be dfu mode.
>   DFU could open other, additional paths here (like booting
>   the e.g. the debian installer)

Well, all these options basically existed back from the BeagleBoard
but they all had their own mantraps and almost all people came back
to prebaked SD images for unpacking to some SD. This seems to be the
most popular method of distributing firmware/software for embedded

After having a lot of work with all alternatives we invented the makesd
approach some years ago. And that works usually very well. Thierry was
even able to unbrick his device using this method.

And makesd seems to have not many very difficult dependencies on the
Linux host. Well, sfdisk did have a nasty API change between minor
versions but we have fixed that as well now. If we provide an executable
("letux-rescue program") we probably run into more binary and library

Another aspect is that the inital flashing of the device is done
by such a FAT+ext partitioned card and inherently tests if the SD
interface works... Hence the name "production image".

So IMHO the makesd approach works well enough in almost all situations
and does not need a replacement.

Therefore I see the DFU approach a nice amendmend to what we have, but
not central for using the devices.

Much more important is to overhaul a QtMoko and Replicant where we
already have a big step forwards. Without these the devices have no
good user experience.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20171231/0718178a/attachment.asc>

More information about the Gta04-owner mailing list