valant

Members
  • Content Count

    67
  • Joined

  • Last visited

About valant

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Interests
    system programming

Recent Profile Visitors

867 profile views
  1. valant

    Rock64pro

    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.
  2. valant

    eliminating hardware bloat

    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.
  3. valant

    eliminating hardware bloat

    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?
  4. valant

    eliminating hardware bloat

    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.
  5. valant

    Asus Tinkerboard

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

    Asus Tinkerboard

    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.
  7. valant

    SD card performance

    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.
  8. valant

    SD card performance

    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?
  9. 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.
  10. 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.)
  11. 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)?
  12. 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.
  13. 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.
  14. 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.