SD based Orange Pi Zero

[darkdrgn2k]

After dissecting mesh orange a bit I realized that the way you get the ram disk is by never leaving the initrd stage one boot.

I have not been able to figure out how leechie builds a separate initial initrd and writes the rest of the data to the sd card. Since i was unable to figure out exactly how/where the leechipi writes its

I had some success using the Armbian stock uInitrd to boot the mesh orange with an SD Card (dumping mesh's orange uinitrd into the partition) but there are some incompatibilities so thats not an option.

What do you think the best (or easiest way for now) way to

• Start with a small uInitrd
• Write the mesh orange OS to the partition instead the uInitrd

Even if you can help me figure out the first point the rest i can "Worked around"

[darkdrgn2k]

I started trying to adjust the Makefiles

This seems like a kludge? why remove debain just to add it in the same line?
darkdrgn2k@87efa88#diff-cc571d850d876ec7204c209be153fa45L16

[darkdrgn2k]

So I got the builder to build an initrd without the Debian os totaling only 10 mb. After flashing the sd card, formating the partition extracting the old uInitrd to it and setting a root device it booted. Although some service failed to start but i think its because root is RO. I think i can fix that by adding a ram disk overlay.

What still needs to be done (if anyone has any suggestions how to accomplish I'm all ears.)

• Make some sort of flag to allow building image as a ram disk or as an SD card for rootfs
  (instead of relaying on PART3_SIZE_MEGS)
• Make a rootfs on build
  instead of extracting old uInitrd into the partition after build
  (Maybe just roll a new image file containing $INITRD_PARTS + $DEBIAN)
• Figure out how to actually format/flash the rootfs into the image on build
• Add Ram disk overlay
  Should be easy. Arabian instructions see cryptpad

[hamishcoleman]

Just so you know, my plan is to make the lichee-pi stuff more generic and make it available to the rest of the boards, which I think is a completely different path than the one you are taking

[darkdrgn2k]

I'm poking and prodding. And on a bit of a time line with the workshop around the corner.

I'm happy to to keep this and fork for now and try to get it to work untill you get your refactoring done.

Or if there is something I can help with.

[benhylau]

@hamishcoleman in the licheepi-zero image, does PART3_SIZE_MEGS = 500 # ext2 root mean the image contains a 500 MB real disk containing the root filesystem, and we will boot into it on startup because of boot.cmd?

If I am to enable that in common-partitions.mk for other boards, it would not have that behaviour right? It will just format the partition but not actually use it on startup?

@darkdrgn2k since Raspberry Pi 2 and 3 are both working now, I don't think we need anything else out of mesh-orange for the workshop do we? Also I wonder if this patch will make the sun8i-h2-plus-orangepi-zero (at least the 512 MB version) run docker now, since the rootfs will use swap space, it should work the same way as the Raspberry Pis.

[hamishcoleman]

@darkdrgn2k I do think that the easiest way to get this working is to do it the same way the lichee pi board is working, but you have already been down that path, so perhaps wait a bit for me to untangle it more.

The plan is not to even build a small initrd - since that is another entire build system project - and just rely on one simple rule: For non ramdisk use, the kernel has built-in support for the block device containing the root filesystem (ie, no modules are needed to be loaded to support the /dev/mmcblk0 device driver) - this is the case for the raspbian raspberry pi kernel and I have configured our kernel to have this for the orange-pi-zero board (and the other similar Allwinner boards)

The reason for the remove/add Debian line you refer to is to ensure that the debian cpio is always first in the list - that allows the default paths to all be created by the debian cpio (and there is nothing in the build that ensures that the initrd list is constructed deterministically, so we use these filters.

Rather than having a flag to allow building as ramdisk or not, I'm planning on building both images always - the PART3_SIZE_MEGS is more an internal implementation detail than anything else (And it will need to change to support building both from the one make cmd)

The current lichee pi build actually extracts all the cpio files into a root dir, instead of concatenating them into the "initrd" file, so that allows a common build flow - components create archives with their output and then the backend either concatenates or extracts for either type of output.

I'm going to skip adding a ramdisk overlay - if you want a ramdisk, use the ramdisk version! However, I am looking at putting in a filesystem snapshot / rollback system that might achieve a similar result for your expectations.

At this point, I cannot think of anything specific I could point you at to help with - but if you keep poking and prodding, you will gain more familiarity with the system in general.

[hamishcoleman]

@benhylau yes, the licheepi PART3_SIZE_MEGS flag does exactly what you are saying. There is some more logic in that board file that actually fills in the root partition (which is what I need to make general and factor out) and once that is done, it will be broadly speaking the same for other boards.

If you enabled it now, you would just get an empty partition created - and nothing inside it (actually, if you didnt notice, it enforces enabling PART2 before PART3 does anything)

[darkdrgn2k]

If I am to enable that in common-partitions.mk for other boards, it would not have that behaviour right? It will just format the partition but not actually use it on startup?

Check out this commit

You don't actually want to change common-partitions.mk, instead define the variable in your boars's make file and this line will detect it in common-partitions.mk

[darkdrgn2k]

The plan is not to even build a small initrd

But you still need an initrd to boot. Does that mean Debian comes with one? I don't think i ever seen a Linux boot without a kernel and an initrd
From the looks of it you don't need one. But wouldn't it make it more compatible with boards in the future that may need one?

I'm going to skip adding a ramdisk overlay

Honestly I'm not to worried about doing or not doing an overlay. Its easy to slide in manually if needed. But it would reduce the writes to the SD card for longer-running installs. If we ever wanted to add this it be like 2 or 3 lines of code.

lichee pi

Ill take a closer look at the makefile now that i have a better understanding of the boot sequence. (See lower down)

[darkdrgn2k]

Also I wonder if this patch will make the sun8i-h2-plus-orangepi-zero (at least the 512 MB version) run docker now

I don't think so. Although @hamishcoleman does mention that there is some "non obvious logic".

But from what i see patch remove the Root Device settings from the boot arguments that (if i understand correctly) are used in a normal initrd to load a root partition. In current Mesh Orange the default initrd init's script is overwritten with one that does the conf.d/init.d boot ignoring most of these settings anyway.

[darkdrgn2k]

My dissection of the LicheePi (sorry i was spelling it wrong) can be found here

https://cryptpad.fr/code/#/1/edit/4kyci5JqgeYJjRzy2Hq2xg/9338RNXJeJteSf5tjhbY0pgl/

@hamishcoleman

So based on what you said and what i understand... as a high level,

If i was to take an orange pi zero build, extract uInnitrd to a partition, add rootdev= and rootfstype= to the armbianEnv and to point to that partition, then delete uInitRd it would boot from the sd card skipping uinitrd?

Update
(Obviously I'm missing something with the above process since its still looking for a ramdisk)

U-Boot 2017.05-armbian (Jun 15 2017 - 03:38:31 +0200) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Zero
DRAM:  256 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   phy interface0
eth0: ethernet@1c30000
Hit any key to stop autoboot:  0
reading /boot/boot.bmp
** Unable to read file /boot/boot.bmp **
reading boot.bmp
** Unable to read file boot.bmp **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
reading /boot/boot.scr
3708 bytes read in 26 ms (138.7 KiB/s)
## Executing script at 43100000
U-boot loaded from SD
Boot script loaded from mmc
reading /boot/armbianEnv.txt
221 bytes read in 22 ms (9.8 KiB/s)
reading /boot/uInitrd
** Unable to read file /boot/uInitrd **
reading /boot/zImage
4920008 bytes read in 389 ms (12.1 MiB/s)
Found mainline kernel configuration
reading /boot/dtb/sun8i-h2-plus-orangepi-zero.dtb
17292 bytes read in 41 ms (411.1 KiB/s)
reading /boot/dtb/overlay/-sun8i-h3-usbhost0.dtbo
** Unable to read file /boot/dtb/overlay/-sun8i-h3-usbhost0.dtbo **
reading /boot/dtb/overlay/-sun8i-h3-usbhost2.dtbo
** Unable to read file /boot/dtb/overlay/-sun8i-h3-usbhost2.dtbo **
reading /boot/dtb/overlay/-sun8i-h3-usbhost3.dtbo
** Unable to read file /boot/dtb/overlay/-sun8i-h3-usbhost3.dtbo **
reading /boot/dtb/overlay/-fixup.scr
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

USB device 0: unknown device
BOOTP broadcast 1
data abort
pc : [<4ff9a84c>]          lr : [<0000a560>]
reloc pc : [<4a03984c>]    lr : [<fa0a9560>]
sp : 4bf3c940  ip : 00000000     fp : 4ffecff8
r10: 4ffecb4c  r9 : 4bf40ee8     r8 : 0000000e
r7 : 4ffeee84  r6 : 4ffeee8c     r5 : 00000000  r4 : 4ffed04e
r3 : 00060101  r2 : 00000008     r1 : 4ffecffe  r0 : 0000000e
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

[hamishcoleman]

just a quick redirect - the "non obvious logic" is in how the kernel decides which filesystem to use for the ramdisk - with that patch, it always uses the "tmpfs". yes, it looks like it is dicking around with root devices etc, but thats why its "non obvious".

So, the whole point of those changes is to make the tmpfs available, so you can add some swap and thus have enough space to try installing docker