Booting the Pyra : unifying the efforts.

[Linux-SWAT]

Hi !

working on a variant of Nikolaus (hns) makesd script who creates root filesystems for various devices ( http://projects.goldelico.com/p/gta04-makesd/ ), I realized that his efforts and aTc ones were a bit different.

For example, they use a different u-boot/MLO, with different options.

Also, aTc uses a one partition system, hns uses two.

Not only there's hns kernels http://download.goldelico.com/gta04-kernel/latest/ , but there is the dev branch which seems unrelated being one kernel version behind http://dev.pyra-handheld.com/index.php/p/pyra-kernel/timeline/
And aTc's kernels http://next.openpandora.org/omap5/kernel/ with an update system which seems to take newest ones in a repository i didn't found.

I would say that maybe it's time to talk about what is better for the Pyra.

My main concerns are :
1- the partition scheme
2- the way u-boot options are passed

1- I have no opinion, but I wonder if there's good and bad things with each options.
2- I think having a uEnv.txt/autoboot.txt or something editable with a simple text editor is important. The way aTc handles the boot with extlinux.conf is SYSLINUX-friendly and i'm fine with it.

 

[TrashyMG]

To me aTc's method is a bit more elegant, setup on an SD card it's just essentially just untaring it to an SD card.  I also like his u-boot method as it's user customizable via a config file in the etc directory and still allows kernel updating via the official pyra repository. Nikolaus images to me have felt a tad unpolished as it seems it may just be for debugging work and not a push to a polished OS on the device. 

 

 

[aTc]

u-boot and some distros are in the middle of trying to find a unified way of handling booting on all arm devices. There are still a lot of things to be decided, but extlinux.conf seems to be the way to go.

hns his work is really for all his different devices, while mine is for a more streamlined pyra version, that doesn't require any manual configuration anywhere.
I did make a bit of mess of things, leaving various test images and kernels all over the place, but now that the kernel installing/upgrading can all be handled by apt, i'll clean up all the obsolete stuff.

 

[Linux-SWAT]

What about the number of partitions ?

 

[TrashyMG]

It's not really fixed to one partition, it just expects that all the files specified in the extlinux.conf are on the same partition as where it found the extlinux.conf itself.

I think essentially aTc's setup uses one ext4 partition.

 

[Linux-SWAT]

Yes, but what about the Pyra.
Is it interesting to separate it for some reason, like multiboot ?

I don't think a splitted /home is needed. With the OP experience, I think we all put user data in a dedicated SD card.

 

[TrashyMG]

It shouldn't be any different on the eMMC...

 

[levi]

I lost a couple of things that would've been nicer to have kept on my Pandora when I reflashed; mainly settings like mplayer settings and the likes.  So there's value in a home partition, I reckon.  Perhaps also, limiting home to its own partition limits its size, and stops people breaking the system by installing too much stuff there (not that that's ever been a problem I've observed here, I guess).

The way some people are talking, some are expecting us to use more software apt-get installed to the eMMC on the Pyra.  Having done so, I'd probably want to store most data for those apps in my home directory, but who knows if it'll be like that, or like a static Pandora OS occasionally updated (by skilled hands) again?  But perhaps, if we don't know, having a home partition that doesn't get nuked if you reflash might be good to have just in case.

 

[hns]

Just for background info: the makesd and multi-partition boot approach is there for quite a long time (~5 years) and has grown to support BeagleBoard and GTA04 and more and more devices. It works well for that purpose. By that it has collected a lot of features and requirements that seem to be (or are) unrelated to the Pyra. One of them is to be flexible to support up to 4 different OS images in different partitions (e.g. Debian, QtMoko, Replicant, QuantumSTEP). And to be able to produce "production" or "recovery" images for the GTA04 (if NAND has been deleted).

It also shall work with devices with built-in boot-loader and without. For example on the GTA04 it suffices to make a single partition SD card because there MLO+U-Boot are in NAND flash. For the uEVM&Pyra the same could work if MLO+U-Boot are in the eMMC, but this requires some tool to do that (basically one could run makesd with the eMMC as target). The result is that only developers or production facilities needs these two-partition cards to initally flash thNAND/e eMMC. For the Pyra this is also possible but has not been worked out (there are more important things to be solved).

Now more to the question about unification:

Basically I imagine that we will have a world consisting of two OS (or more if we consider RiscOS etc.). One is "the Pyra OS" and the other is "Letux which supports Pyra amongst other". Of course the first one is more polished and optimized while the other allows easy exchange of data (even root-file systems). But it may lack behind in polishing and some features.
Both can be related or harmonized but must not be. Maybe it is even impossible in some areas.

Of course the optimal harmonization would be if all modifications are upstreamed to denx.de or kernel.org. Then, there is only discussion about the root file system to choose and the boot/kernel system is the same for everybody. But upstreaming is a signifiant amount of extra work stealing time from other areas. Therefore it is very tempting not to do it and just develop a fork 

 

[_jr_]

I suspect 'must not' = 'need not' in the above

 

[hns]

I suspect 'must not' = 'need not' in the above

Yes  Thanks for the correction in wording.

 

[aTc]

The thing I always run into when having a seperate home partition (or anything else really), is that I'll always run out of space on one partition , and have loads of it left on the other.
This only gets worse when the space is relatively limited, like on the emmc.

The seperate boot partition isn't really required on the uevm/pyra, since it can find MLO and u-boot perfectly fine when they're sitting in the empty space in front of the partition. (also on emmc, which it sees as just another sd card )
One case where a seperate boot partition might be useful is if there's a significant advantage to using F2FS or NILFS on the emmc, since I don't think u-boot can boot from those directly.

 

[hns]

The seperate boot partition isn't really required on the uevm/pyra, since it can find MLO and u-boot perfectly fine when they're sitting in the empty space in front of the partition. (also on emmc, which it sees as just another sd card )

Surely, it works if MLO/U-Boot are hidden and the auto-mounter thinks there is only one partition.

But replacing hidden boot files by a simple apt-get update is more difficult, since it can not be accessed as a file in some standard file system format any more (because you wanted to avoid to make it visible as a partition). Well, you can install it to /boot and run a special dd command in the postinst script which knows the location of the "hidden" partition. So there are tricks, but I try to avoid them (maintainablility).

In my view it does not even matter if there is a single or double partition on SD cards, as long as some well designed MLO and U-Boot is factory installed in a small partition on eMMC (factory installation is done by using a directly bootable SD card). This is the standard case for the OpenPandora and the GTA04 (I have an SD card that can boot on both because it only carries the kernel and the rootfs and neither MLO nor U-Boot).

Then, the average user does not have to care about it any more. Neither in the big rootfs partition of the eMMC or any SD card.

Only preparation of the factory SD card (or in case you want to unbrick a damaged eMMC) needs a mechanism to create two-partition cards (and then it doesn't matter if the boot partition is hidden or visible).

Some older documents (focussing on DT work) include a description of these ideas:
http://download.goldelico.com/gta04-u-boot/files/Device_Tree_Migration.pdf
http://download.goldelico.com/default/Presentations/20141129 OHSW/4 Device Tree Tutorial.pdf

So basically I have split the formatting goals into two purposes:
1. SD card with rootfs that can run on multiple devices
2. SD card to (rarely) reprogram the boot system on a specific device

All this has influenced the design of the makesd tool. If you run makesd for a specific device, it will (case 2) include everything to boot from SD card (usually making a dual-partition card). If you just "makesd debian" or "replicant", it will assume that a boot loader exists and just fill a single partition (case 1). Just as a side-note: it is possible to make a three or 4 partition SD card with different root-file systems. Then, the boot loader should of course allow to switch between them.

For the final Pyra we probably should also include a small initrd based kernel in the boot partition. The reason is that we need a MIPI display driver and a driver for the SSD2858. It is impossible to integrate this into U-Boot (adding a frame buffer for a simple RGB panel and write some boot text is much easier) so there is no chance to integrate boot source selection into U-Boot. Therefore, MLO will load U-Boot which will load this Mini-Linux which will give the user a choice. And depending on the final choice, the real Linux is loaded and executed through kexec. Potentially we could even skip U-Boot but I am not sure if MLO can be made to load and run some initrd based kernel image directly.

 

[Linux-SWAT]

hns, the 4.3.0-rc5-letux-pyra kernel doesn't list sensors output on the EVM :

# sensors
bq27425-0-virtual-0
Adapter: Virtual device
temp1:            N/A  

 

[aTc]

The bq27425 doesn't show up because it's not on the board, it's part of the battery charger stuff.

The cpu temp sensor only showed up in the 3.8 TI kernel, so it's either a module that needs to be enabled, or it's just another case of things disappearing from the dtb.