On other SoCs the device tree blob/binary needs to be loaded with the kernel in Extlinux and is defined by using

fdtdir /location

and

fdt /location/file

but on the PI this can't been done. Not sure why Grub would be able to handle this, but ok? I'll read over ur post further when I have some time.

Extlinux can load device-trees. It is the next stage of the bootloader on the Pi that gets confused, which is really just the first stage. That's the So what? As you so finely put it.

If you've had it working for 6 months why are you keeping it a secret and being a jerk about it here? Why not just contribute?

I'm not ignoring it, I just don't care I find it at this time to be a bit fruitless, hence why I suggested if you wanna put in the work to make it happen. Have at it!

You can simply review the latest changes in mainline to find what ur saying about kernel revisions isn't accurate at this time: https://git.kernel.org/pub/scm/linux/ke … 10.52&dt=2

I'm not against getting this working, I'm simply saying that the effort needed to get that done would be very time consuming.

Cheers!

This would be easier to accomplish using u-boot and extlinux, with extlinux you can add an optional menu. One problem though, would be the current kernel packaging, as currently it purges the old kernel, dtbs, initrd, overlays and headers during install.

As for Grub, I've played around with it on other SBCs, but am not 100% sure how to set that up correctly on a Pi.

Did it ever work or did you install something and it stopped working? If it wasn't setup upon firstboot, it can than be done manually using the following script.

Try this one: https://github.com/pyavitz/rpi-img-buil … -26.img.xz

The name of the img is misleading, as it will actually boot both the Raspberry Pi 2 and 3.
More information on the img and options can be found here: https://github.com/pyavitz/rpi-img-buil … tag/images

Yes, it seems to vary in USB-3 storage type and manufacture.

Alright, well I just installed some needed bits and it seems to be appearing for me.

uncomment:

dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=spi=on

Install:
sudo apt install -y python3-dev python-smbus i2c-tools python3-pil python3-pip python3-setuptools python3-rpi.gpio

make sure the above modue is in /etc/modules and reboot.

Came right up:

ls /dev/i2c*
/dev/i2c-1

patrick@devuan:~$ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

If you are using one of my images it doesn't a have a root password, as that's a security risk. You can easily create one though: sudo passwd root

As for writing to SSD run:

deb-eeprom -u (updates the script and shows options)
deb-eeprom -v (edit version variable to 11.8)
deb-eeprom -U (this will upgrade you to the latest eeprom)

Now reboot and attach the SSD (make sure only one SSD or USB storage device is attached)

deb-eeprom -w (this will setup eeprom, partition the drive and transfer the contents of the SDCARD to the SSD) 

My images by default should just boot off SSD. So next time just write the img to SSD, attach and go.

Note:
If you run into problems such as the drive being slow or not bootable, then you need to add usb storage quirks to the cmdline.txt

Images can be located here: Images
Along with an explanation on how to use them. Such as a wifi setup script and the ability to choose your own username & password upon first boot.

I don't support armhf images, but do have an armhf branch for those who don't mind building their own images.

My guess would be that after using gparted the PARTUUID has changed. Attach the SSD and run sudo blkid and see if it matches whats in /boot/cmdline.txt

Personally I think this approach is just silliness and what I mean by this is, that these boards "no matter what the manufacture may suggest" are a niche device. If you are interested in proper video playback, I would go with an OS that is specializing in this approach.

I wouldn't buy a toaster to cook a turkey and then act surprised when it didn't work.

I tend to lean towards Amlogic SoC's for video play back and use CoreELEC and just throw things at it like you would any commercial device: Chromecast, Firestick and Roku. This could also be done using the Pi4 and LibreELEC, but generally not as cost effective.