I've tried this latest dtb but can't get the SD card to show up so I've reverted back to the .dtb from 26 September. I've cloned the USB stick to a SD card and plugged it into the device. I then change uboot environment from serial using the following commands:

This boots into Debian from the SD card however it is not very responsive probably due to the low quality (class 4) card. The stock system doesn't offer a terminal or ssh access so I'm thinking of wiping the internal memory and installing Debian there.

So I'm thinking of removing the uImage and squashfs files from partition 2 but leave the three small files in place. I would then resize partition 2 to its minimal required size, wipe the contents of partition 3 and resizing it to the maximum size and install Debian in there.

OK the steps above have worked. I've created backups of the original partitions to an external drive and removed most of the files. Then I've resized the filesystem and partition mmcblk1p2. I've removed the old mmcblk1p3 partition and re-created it with the rootfs label. Then I used the following commands in serial to boot from the internal memory:

stock uboot loads an image from the 2nd partition to display on screen during boot. I can't find it anywhere in the uboot environment variables so I assume that this behavior is hard coded. This happens before you get to the uboot prompt so I am afraid that removing the 2nd partition may result in a brick. The 1st partition can't be mounted in Debian so I'm not sure what is stored in there. In the end the size of the 1st and 2nd partitions is now small enough that I don't care too much about the wasted space.

Unfortunately this doesn't work. Once the first attempt at booting fails the device continues into some sort of recovery mode and tries to boot from a server. I'm not sure if this is behaviour is hard coded since it is not defined in the normal uboot environment settings?

The envs logic needs to be a little bit more complicate than what you currently have. I don't think I covered this part for you, since we are still getting these boxes to completelly brought up to the way we want (i.e. display, sound are remaining works).

But, since you are apprently want to use them as headless production servers now :), I will show you how to change the envs to make it resilient, and fall through the execution paths correctly from the 1st to the last device.

at the moment I don't care about the network booting 'recovery' option as implemented by the stock uboot.

Quotebodhi
But, since you are apprently want to use them as headless production servers now :), I will show you how to change the envs to make it resilient, and fall through the execution paths correctly from the 1st to the last device.

yes I've become a bit impatient and I'm trying to get my devices in a state so that they have an easy recover option which does not require serial connection. Audio and video are nice to have but not essential in my use case. I enjoy the search for information, reverse engineering and figuring things out but seem to have reached the end of my knowledge at the moment. I did email ChipPC about the GPL sources and did get an initial response but it has been quiet ever since. Based on this I think it is unlikely that we will ever have access to uboot and/or kernel sources.

> Stock uboot doesn't know 'if then else' statements
> so the settings you have provided don't work
> unfortunately.

Ah :) this u-boot is old and did not even have a hush parser activated.

> I'm not sure if I should just adjust uboot environment such that it says 'enaMonExt=yes' instead of 'enaMonExt=no' ?

I am not sure that env play any role in this.

> Audio and video are nice to have but not essential in my use case.

That's great! then you are all set to use it as a headless server. Go ahead and also try testing in Debian, I recall you've listed a summary of what capabilities we got so far for this box. Is there anything important missing?

There are still some more hacking possible in u-boot, even without the GPL source. Let me look at my notes and suggest what you can do.

I've found a way to get multi stage booting to work without 'if then' statements or dropping into the stock network boot recovery mode. My settings are listed below. First it loads the uImage and uInitrd from internal memory into RAM. Then it tries to load them from the SD card. If an SD card is present the uImage and uInitrd in RAM get overwritten by those from the SD card, resulting in the device booting from the SD card. If no SD card is present the uImage and uInitrd in RAM remain unchanged and the device boots from internal memory.

This probably isn't the cleanest solution since if there is a difference in the 2 uImage and uInitrd file sizes you could end up with bits of RAM that contain executable code which does not get overwritten. However I think this risk is small and it does allow me to run the device with an easy recovery method.

The script would be sourced from the SD card so the label is only changed when the SD card is actually present. If the SD card is not present the script can't be sourced and hopefully the device will continue to boot from the internal memory.

The load address 0x10000000 is just a large number so it is hopefully far enough away from uImage and uInitrd. It seems to work OK since the device boots from the SD card if it can find it during boot and otherwise it boots from the internal memory.

It seems that ${mtdparts} does not get replaced by the value / string that is already present in the uboot environment settings. Maybe scripts don't have access to the other environment values. Anyway I guess I need to add a line which defines mtdparts to the script and try again.

No need to use the boot script (more moving parts), you should just set a different root label in the bootargs for each type of device. You can also use an env for this rootfs label, too. Something like this.

Please, enter the code that you see below in the input field.
This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right.
If you enter the wrong code, a new image is created and you get
another chance to enter it right.