raidboy

Trying to download armbian for rockpi-4a, following the link https://redirect.armbian.com/rockpi-4a/ on https://www.armbian.com/rock-pi-4/ In one case, this resolves to https://mirrors.netix.net/armbian/dl/rockpi-4a/, which shows an empty directory except for an archive subdirectory that is empty too. clicking around through the armbian/dl folder, this seems to be only empty directories for any board. In another case, the redirect resolves to https://minio.k-space.ee/armbian which just returns XML gibberish.

ok. copied mmcblk1p1 partition file. copied fresh Armbian onto eMMC, booted from it. boot from SD again, resize mmcblk1p1 to former size (no change of 32768 start sector), copy back mmcblk1p1 saved partition. Boots fine. Also was able to add swap partition which automatically got used by armbian. Might be useful to consider some form of protective partition entry from 2048 to 32767 to avoid this type of mistake to happen...

actually even the SD installation image shows MBR and GPT in gdisk. Thanks for finding the 2048. No idea, i guess i must have messed um in gparted, didn't mean to move the start of the partition. So. There is nothing that should make bootstrap fail if i just change at the end of the disk and add partitions there ? Given how much i changed in my installation i guess i have to simply save the whole FW and restore to a fresh image copy... lets see.

Right. Not equally fast. But there can easily be other reasons for additional partitions. How do i get my eMMC bootable again ?

apologies for double posting.. how did that happen, strange.

RockPi4a. Installed busster current 5.8.6 armbian onto eMMC. Works fine. Now i figure out i need swap space (app needs more than the 1G mem i have). So i boot another image from SD an use gparted to shrink the first partition from the end to create 4GByte and create a swap partition in there. Now the board won't boot anymore (see attached file). Erased SPI, no difference. Partition table shows GPT and "MBR protective" (before and after resizing). so, whats the magic to create a bootable armbian disk if one needs different partitioning than just the "full disk one partition" layout ? Is this "uboot" hidden behind the only partition, there was a bunch of space unused after the partition that i used for the swap partition. Sorry if this was discussed before but uncle google and dr armbian search couldn't find anything for me ;-( armbian-failure.txt

Finally managed to verify the SPI assumption, and it is correct: Boot radxa debian, e.g.: from SSD % cat /proc/mtd dev: size erasesize name mtd0: 00400000 00001000 "loader" This shows that there is a partition? on SPI. When trying to do the same on Armbian, it will not show the partition. Erase: dd if=/dev/zero ob=/dev/mtdblock0 bs=512 Use first command to verify its erased. Afterwards, normal armbian image with only MBR partition table will boot fine from eMMC. The modified gpt partition image will still boot too.

Thanks This was booting from eMMC, not NVMe. Some commands to verify the version of the software on SPI would be helpfull before i erase it, so that i can try the workaround but reproduce (save/restore SPI).

Whatever is the image format that works on all rockpi variations with/without SPI and with least amount of work involved. Not changing what armbian does right now seems to depend on hoping that radxa fixes broken SPI code. Which i agree they should do, but not sure if they will.

I have added SPI workaround to the radxa eMMC install wiki page: https://wiki.radxa.com/Rockpi4/install/eMMC Btw: I am wondering why Armbian isn't using GUID partition table. Was GUID partition table not working on older Radxa ?

Are there any commands to show information that could tell me about the level of power consumption ? E.g.: energy saving state of CPU or the like ? On the SBC i am using, i think the power consumption is lower when running the same setup with kernel 5.4, and higher with legacy kernel 4.4. Alas, 5.4 has other problems, so i want to try to figure out what settings/features reduce power consumption in 5.4 and maybe i can then configure them equally in 4.4. This is rockpi4a rockchip3399. If there is nothing generic enough about the topic, i can ask on the forum for that chip.

But why shuold the current file format with MBR and phase 2/3 not continue to work whether SPI is or is not present ? Radxa would just have to fix up their SPI boot loader to recognize MBR and continue to boot from the phase 2/3 on the eMMC. Or for that matter, if there is really no benefit to execute the on-eMMC phase 2/3 (hence my question before) to boot directly into phase 4 on the eMMC as they seem to do now when they discover UEFI. I probably would prefer the latter, if the SPI boot code from radxa could try to find /boot on multiple partition and offer a menu on serial console or even graphics ;-) Then the OSs on those partitions wouldn't have to bother implementing that. Thats a typical platform firmware problem when they want to support multiple different OS simultaneously. Which at least for one partition linux, one partition android might be interesting to users. Expecting third parties like armbian to do additional install magic like explaining to users what SPI is, how they need to feed and fix is, doesn't sound like a viable way to make users happy.

Thanks, piter75. You are pointing me to good workarounds, but i think in the first place, radxa needs to explain what the forward going image format is that third party distributions like armbian should use and that will correctly bootstrap across all rockpi4 versions. Seems right now there is no such format and that would be a big pain for distros like armbian or others: you seem to require a standard rockchip setup for rockpi4a without SPI, and another one (UEFI, stage 2,3 on SPI) on v1.4 with som random new radxa code on the SPI. Just curious: Is there actually any benefit of having the u-boot stage 3 on the SD/eMMC card, e.g.: does it do any special cool things that the radxa u-boot wouldn't do ? Or is it just there because on rockpi4a without SPI its just mandatory to have _some_ u-boot version on the uSD/eMMC, but theres beside bug-fixes no real feature differences between those u-boot's. Thanks!

@igor: Are you telling me that the armbian images have stage 2 and stage 3 in the sectors before 32768 without showing them in the MBR partition table ? Looks to me as if what i am seeing on my rockpi4a looks more like what the documentation describes as boot from "u-disk" with armbian really being stage 4/5 from the single partition it has, and no stage 2/3 taken from the disk before. I don't even know what a u-disk is.

Boot from unchanged armbian image: http://ix.io/2bjY (trying to boot from ethernet at the end). Working boot after replacing MBR with EUFI: http://ix.io/2bk3 I have no clue about SPI. I just think to remember that booting from MBR on eMMC did work initially, but then i was experimenting with radxas debian installation, and when i installed something with "apt install ..." there was some dependency that took a long time, seemingly flashing something. Thats why i am thinking that i may now have some newer radxa firmware flashed than what the device was shipped with. But i couldn't find any webpage from where i could diagnose the situation ... I'll certainly ask on the radxa forum too. Took me already the better part of sunday to figure out how to get armbian booting again. *sigh*.