12-21-2018, 09:49 AM
I just wanted to share some messing around I've been doing to my rock64 today. Currently I'm running the latest linux-rock64 from ayufan on Ubuntu Bionic. I am using SPI to boot my system to a SSD I have plugged into the USB3 port.
Occasionally the u-boot has issues seeing the SSD properly and I have to reset the board a few times to get it to actually boot. This wouldn't be an issue if it wasn't for the occasional power outage sending my system to an unresponsive state remotely since it is trapped in the bootloader without manual assistance. Being willing to experiment I was considering trying to build u-boot myself, but I didn't get that far - I had noticed there was a new release flagged for build 1035 in ayufan's github.
Now I know I could just download the flash and do it that route, in fact that's what I had done last time I messed with the bootloader to get it to boot off the SSD in the first place with a pre-release at the time. But I saw that the latest build was in the cache for APT and decided I would try and do it the linux way.
So this is where I realize that there's a bit of a problem with manually updating the bootloader through APT. If I were to execute the command:
I would be met with APT having a bit of a meltdown regarding dependencies, wanting to remove linux-rock64, board-package-rock64 and u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1025-g482cd6ec8b.
Knowing that the bootloader is not actually a hard dependency for the other components that I didn't want to bother manually reinstalling, I tried to edit /var/lib/dpkg/status manually to attempt to fix this. Finding the section for linux-rock64, all I had to do was change this:
... into this:
Suddenly, I could change out the bootloader using APT to pull the new package and proceed to update the SPI! Next time I update linux-rock64 it will want to downgrade back to 1025, which isn't really a big deal since I would still have to reflash the SPI manually anyway.
Now, I don't really suggest doing this the way that I did, since the next time I update or change anything the information would just be overwritten and APT will actually use the dependency chain to want to downgrade back to 1025. But I think it is worth noting that the packages that pull the u-boot image could probably be changed to recommend a specific bootloader versus a hard dependency on it. This would allow us to use APT with the --no-install-recommends (or alternatively --install-suggests if it was changed to a suggested dependency) to bypass which bootloader you use more easily.
Or... you know, just flash with an SD card like a normal person. It was a fun experiment and hopefully sorted the SSD boot issue.
Have a happy holidays everyone!
Occasionally the u-boot has issues seeing the SSD properly and I have to reset the board a few times to get it to actually boot. This wouldn't be an issue if it wasn't for the occasional power outage sending my system to an unresponsive state remotely since it is trapped in the bootloader without manual assistance. Being willing to experiment I was considering trying to build u-boot myself, but I didn't get that far - I had noticed there was a new release flagged for build 1035 in ayufan's github.
Now I know I could just download the flash and do it that route, in fact that's what I had done last time I messed with the bootloader to get it to boot off the SSD in the first place with a pre-release at the time. But I saw that the latest build was in the cache for APT and decided I would try and do it the linux way.
So this is where I realize that there's a bit of a problem with manually updating the bootloader through APT. If I were to execute the command:
Code:
apt install 2017.09-rockchip-ayufan-1035-gd646df03acI would be met with APT having a bit of a meltdown regarding dependencies, wanting to remove linux-rock64, board-package-rock64 and u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1025-g482cd6ec8b.
Knowing that the bootloader is not actually a hard dependency for the other components that I didn't want to bother manually reinstalling, I tried to edit /var/lib/dpkg/status manually to attempt to fix this. Finding the section for linux-rock64, all I had to do was change this:
Code:
Depends: board-package-rock64-0.7-30, u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1025-g482cd6ec8b, linux-image-4.4.132-1075-rockchip-ayufan-ga83beded8524, linux-headers-4.4.132-1075-rockchip-ayufan-ga83beded8524... into this:
Code:
Depends: board-package-rock64-0.7-30, linux-image-4.4.132-1075-rockchip-ayufan-ga83beded8524, linux-headers-4.4.132-1075-rockchip-ayufan-ga83beded8524
Recommends: u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1025-g482cd6ec8bSuddenly, I could change out the bootloader using APT to pull the new package and proceed to update the SPI! Next time I update linux-rock64 it will want to downgrade back to 1025, which isn't really a big deal since I would still have to reflash the SPI manually anyway.
Now, I don't really suggest doing this the way that I did, since the next time I update or change anything the information would just be overwritten and APT will actually use the dependency chain to want to downgrade back to 1025. But I think it is worth noting that the packages that pull the u-boot image could probably be changed to recommend a specific bootloader versus a hard dependency on it. This would allow us to use APT with the --no-install-recommends (or alternatively --install-suggests if it was changed to a suggested dependency) to bypass which bootloader you use more easily.
Or... you know, just flash with an SD card like a normal person. It was a fun experiment and hopefully sorted the SSD boot issue.
Have a happy holidays everyone!