valant

but it worked with Armbian 5.83. it even did support UEFI GOP. there were issues with storage reads, when using uboot's UEFI so I updated... finding no HDMI at all. could someone point the latest version (minimal, without desktop) of Armbian, where HDMI support in uboot is still there?

dudes, I am sorry for the intrusion, I see, you are having a hardcore debugging party with this, not willing to interfere with the question I am sick of on my own already. But nobody on their forum answers, and I cannot buy it not knowing the answer. Did someone of you run iozone test with a UHS-I capable SD card on Rockpro? please, show numbers. Added later. Finally it's confirmed. RockPro does support UHS-I (with SDR104 incl.) The maximum reached is about 66 MB/s, given the rockchip 150MHz limit. just as good as other rk3399 boards.

Oh well. "ROM code" is not a number, that points somewhere and this magically makes it "load" the next stages. It is instructions, the code, in the sense as an OS is the code... So, for adding to the ROM code other interfaces support to load from, you need to write that code and flash it into a CPU. And now, the most interesting part. Again, M.2 is a connector and nothing more. You attach either SATA/AHCI things to it or PCIe/NVMHCI things or USB3/xHCI/UASP to it. And now, imagine, - all those aren't the easiest pieces of hardware. ROM code runs in the most limited envinronment ever possible. Nothing works yet. It's something like a few of KBs worth. And that code needs to setup for example AHCI/SATA and try to do something with it. Even on PCs, this is not the case, since, I guess, x86 processors' "ROM code" only cares about NOR chips having BIOS/UEFI there. Basically, it strats up from the hardcoded address running some XIP code on the NOR chip. It's the easiest way. So, ARM ROM codes aren't the dumbest ones yet. Get it finally? Nobody will ever add AHCI/NVMHCI/xHCI support to the ROM code, it's technically impossible. So for you, here is the receipe: 1) you choose the board with the small NOR chip for the firmware (UEFI, uboot, if the latter could qualify for being called that ) flashed there. as well, the board should have ... what you dream about - M.2 connector. 2) you attach there your SSD and setup your firmware to boot the OS of your choice from there 3) finally, you happily desolder SD card slot and/or eMMC module. The "bloat" is gone, you are happy. Enjoy. I mean you need to become an SBC board vendor for satisfying such whims. No sane manufacturers will do that for their money.

Boot ROM doesn't "point" to anything, this is a tiny piece of code inside of the SoC, CPU executes first when starts. This code loads its payloads - next stages of the firmware - from one of those media into SRAM and hands off control there. And currently, no ROM codes of SBCs could use anything except SPI NOR, NAND, eMMC or SD. M.2 is just a connector - for either PCIe, SATA or USB3 interfaces. None of those are supported by current ROM codes. Except USB can be used for transfering payloads through some custom vendor defined protocol - not an ordinary mass storage use case. Why they aren't supported? Because neither SATA nor NVMe (that uses PCIe) nor USB mass storage devices were "ordinary" for mobile devices, from which SBCs' SoCs come. As of "why have so many devices/interfaces", well, who would decide the best choice? There are diferent needs and budgets. From many points of view - software components placement and board vendor/user perspective. For the firmware, the best places to have been put in are SPI NOR chips, boot areas, "partitions", of eMMC modules. for the OS - it depends on the price users are ready to pay. Will it be a cheap SD card, medium priced eMMC module or exteremely expensive NVMe SSD. Having SD cards or eMMC modules as main storage devices on these platforms doesn't make these not "PC" like. These are PCs but they are mini PCs and the mentioned interfaces fit well this defintion. For example, without them, and only with the M.2 SATA/NVMe SSD option, SBCs won't be "affordable" things for "tinkering" anymore. And why on the planet one can be bothered by having an SD card slot on the board?

Literally every current SBC SoC ROM code gets its payload from SPI NOR flash, eMMC, SD. Without these interfaces your M.2 paradise dream won't even start. And by the way, having a normal PCIe slot is way much better than everything else, with M.2 includingly. With the former you can attach M.2 expansion card and have what you want, but as well can upgrade it or attach something else. This is why I like how it's done with RockPro most. other rk3399 boards have screwed PCIe up.

Thank you! Oh my god, I feel so stupid - the post about exactly this is just on this very page!

Hi, rk3288 has 4 SD/eMMC controllers, they are called SDMMC, SDIO (2 instances) and EMMC. The latter seems to be a newer IP, supporting more modes and newer versions of the specifications. Looks like SDMMC can't do SDR104, whereas EMMC can. The question is what of them the SD card slot is connetcted to? On Tinker Board. And on Tinker Board S, because unlike the former, the latter has eMMC module, so it may make difference (eMMC module's HS400 vs. SD card's SDR104). I know, it is written somewhere in the DT, but I forgot where in the linux/uboot dark forests those trees grow. Thank you for your replies.

does anybody here know if this has been implemented for RockPro64? I asked at the irc, but nobody seems to know. I suspect the answer is "no" (the same as with Rock64, that also should have a UHS-I capable SD host controller), but the certain answer would be better than guesses.

tkaiser, DDR50 is not the "slowest SD mode". It's a mandatory UHS-I mode, capable of delivering up to 50 MB/s. So it's fast, but it uses the lower frequency (50 MHz) giving power saving. SDR104 runs at 208 MHz. In the above quote, pre UHS-I are DS and HS 3.3V modes. DS is "the slowest". DDR50 is a thing in fact - fast and power saving at the same time. Unlike SD104 it should be supported by every UHS-I card. This UHS-I "problem" is really bugging me. How messy it is on SBCs. I am happy to finally hear that Odoroid does support UHS-I modes. And Tinkerboard - I actually suspected that Asus could not just f&ck up such a good feature as UHS-I, which is already there in the SoC, and just waits for the proper implementation on the board side. But what about RockPro64? Do you know of whether the board lets the SoC's SD controller to do UHS-I? Even Rock64's rk3328 should be able of doing so. Heck, even Allwinner's A20 (!), R40, A64, and I am sure H2/H3/H5 too all claim UHS-I support... But what boards have implemented it properly?

just to summarize. the second flashing of the same card still had issues with packaging system, this time dpkg complained about "crontab" group missing (or present ) in statoverride file or something. so, I gave up and flashed armbian on another card. everything is working so far. I did full format of the offending card with the SDA formatter, and it reported no problems with it. so yeah, not very clear but most probably it was a problem with the SD card. thanks evrybody for the help. Btw, have you noticed that attaching an HDMI monitor to the board adds to the SoC temperature ~9 C. Even if it's just a console output (no GUI). Having nothing attached except Ethernet, gives 43 C in the idle (heatsink mounted). With HDMI, it gives 52 C.

haha. fdisk is the finishing touch with shrinking. I meant what the size does resize2fs report. apparently it should be the whole FS volume size, but I needed to ensure after all these fails.)

I fear it's resizing the FS went wrong. Too bad I didn't check packages before doing it. I have a question. Let's assume I shrink 14.3GB ext4 volume to 8GB doing: resize2fs /dev/sda2 8G and the utility tells me that the FS now is N 4KB blocks length. Is N the number I should use for partition shrinking with fdisk (translated into number of sectors, of course)? Logically yes, but who knows. I mean is N the whole size of the volume with metadata and data (free space included)?

Yes I did, it reported corrupted packages, both times with -v, and with -c first time it detected corruption, the second time didn't. and exactly there were mostly perl related files. I showed this just removed file list, it was long.

yes, on Rock64. CardReader is USB2. I reproduced the same error with NetworkManager generated file inserted into that poor package list file. after typing several times apt-get with different commands (purge, clean, autoclean, install, update) and dpkg --configure -a, package list file got corrupted again with exactly the same NM stuff... every debian package system utility (apt-get, debconf-*) complained about syntax errors in Perl files. Mostly in File.pm. looking there showed something like this: nless(XXX){} } } } } 1; ^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@; with "nless" and mismatched curly braces. XXX - some C-macro looking thing, I forgot exact name of it. Could this kind of damage be a result of a FS corruption? Are these perl library files generated dynamically somehow, or are they just unpacked from zipped archives during the installation? Since it got quite psychedeIic, I just reinstalled Armbian on the same card and it worked well so far. And by the way the proper file File.pm even doesn't have "unless" keyword in it.

I was just struggling with formatting on the forum to post it not an ugly way, so it took some time (almost as much as the test did). fsck said "everything is clean". there was yet another fail. I inserted another SD card through USB-SD adapter into USB3 port, it's a good adapter it worked well before, and it was recognized by linux. but resizing the FS and partition went wrong at all. fdisk wrote zeros in the MBR instead of what I typed. and the USBCUV signature at the beginning of MBR. fdisk task succeeded only on the second time. fsck, resize2fs makefs.ext4 didn't behave properly. resize2fs reported it has done successfully but fsck couldn't find ext4 volume. makefs just exited in between the process without reporting success/fail. after inserting the adapter in the USB2 port it worked out. now I think what if really it's RAM is damaged in some way. would be so not cool... the link is http://ix.io/1i7t the info on SD I'll try SD formatter later and tell. The second run of the armbianmonitor -c check was OK.

but the check revealed corruption of a FS block (8 sectors). isn't it too often for RAM bit flops? I mean it should be a very rare event. here, we have package list file corruption, and now test discovers yet another FS corruption. This card hasn't been used extensively. Almost new. A CentOS installation for Banana PI M2 Ultra was there and everything worked. But I used it a couple of hours in total. so.

thanks for your responses. To Myy, yes, that sequence made it work.) well, apt-get now doesn't complain about being unable to parse that file. still it seems the card is the problem. because I did the check, tkaiser suggested. It reports 1 corrupted block (8 sectors). well, sd cards... but it's still funny how in the middle of package list file the output from networkmanager occured.

here is the quote from the command line. If you know how to repair it without reflashing the card, please tell me. I need the FAT partition and resizing it all over again would be so frustrating.

I was faced with a very weird erroneous behavior. The distribution and board are the same. the board is 4GB. the oddity is in that apt-get cannot do anything complaining that it is "unable to parse package list file" /var/lib/apt/armbian.com_dists_InRelease. sorry the name of the file could be written not 100% precise, but you probably get what the file is. You know what I found inside the file where looked into it? In the middle of it there were some bullshit network configuration related and inserted by NetworkManager (there was a comment inside - "inserted/merged by network manager")! I very doubt it is normal. Removing that didn't help, because apparently it's not enough to recover the file. I barely could imagine what the thing could happen for that infamous networkmanager to corrupt this file, how? Anyway, any ideas on how I could recover the packaging system to make it "great again"? Has anyone encountered this before? I almost didn't anything with the board before noticing that. what I did: set up static IP uninstalled unattended-upgrades resized (offline) ext4 volume where the root resides and the appropriate partition. namely shrank them. But, everything worked after that just fine. hardly that bug could be from this?

yes, I saw that on the armbian for pine64. it both uses booti and sets up bootargs. bootm works for sure. in that sense it switches into aarch64 state, masks out interrupts as well as booti does, and successfully loads and transfers control to "legacy linux image". but that image wasn't actually linux. As I've said, without arguments to it, it passes zeros into 4 argument registers. It's hard to check what it would do with DT loaded and passed to it, when the code cannot do anything with DT by its own yet. Of course, for bootm, a so called arm64 linux image format isn't a thing (mkimage wrapping needed). Added. I found the answer. "bootargs" goes into "/chosen" node.

Thanks. How about command line hand off? Do you know how it's passed in case of using DT (thus no ATAGs)?

By the way, a while ago i had been faced with the fact, that uboot on Allwinner's 64 bit capable CPUs runs in the aarch32 state (because brom starts in aarch32) and only bootm and booti commands do a warm reset for the a64 linux kernel, basically a quirk. How it is with H6? I mean it's a newer allwinner SoC with a lot of changes, maybe their brom finally taught itself to work in aarch64? And yet. I am not into uboot that much, but I need to know this and you know uboot "documentation" is a joke. How the linux command line (bootargs content) is passed to linux for the case of using DT? I did a check with cb2 (their images), bpi m2u (their images) and pine64+ (armbian). 1) uses ATAGs with bootm (at least if the latter used without arguments), 2) uses DT that obviuosly is embedded into uboot itself, 3) passes all zeros into x0, x1, x2, x3 if the command (bootm) is used without arguments. apparently it would pass DT in x0 should it have it passed to it before by the user. But I see, armbian sets up bootargs variable, so the question is how DT variants of uboot pass the command line to linux? some DT node added on the fly? Thanks.

Ah, you are right, they claim 1.8 V support for only SDIO (at SDMHC1), not SD cards. Thank you.

By the way, Xalius, don't you know, what the situation is with Pine H64 with this respect? I see H6 supports UHS-I I/O voltages/speed modes. Does the board provide the support (on the harware level, not linux support)?