• Content Count

  • Joined

  • Last visited

About valant

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Interests
    system programming

Recent Profile Visitors

1906 profile views
  1. 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?
  2. It's hard for an OS to do SDRAM test, at least because it resides there. The best way would be the firmware, while running in SRAM yet, right after SDRAM initialization, to do that, then recording info about bad pages and passing it to the OS through the memory map. what I did was a quick hack (see the snippet below) - I inserted a simple loop inside the code, that runs after uboot, and ran it. It wouldn't be of a much usefulness overall, it just let understand loosely what amount of RAM is damaged in this particular case. The fact, it threw exception on the same address gives a hope, it'
  3. well, I added writing into the second gigabyte in my loader and it showed this result: first, the code has been writing into every 8-byte word, starting at the 2nd gigabyte. and it failed at the 37th 8-byte word inside of the 129th page or passing ~512KB. I ran it twice and it failed at the same position. The fail is "synchronous abort" exception. second, the code has been changed to write first 8-byte word on every 4KB page starting from the 2nd gigabyte up to the last page (bffff000). I run this code twice and it passed it successfully both times. After the loop, the code read ba
  4. I used an old legacy image until now (the screenshot on top of the page), there uboot reported 2GB but passed 1GB in the dtb. I'll try something else.
  5. val@pine:~$ free total used free shared buff/cache available Mem: 1017160 57956 850320 2956 108884 889600 Swap: 508576 0 508576
  6. downloaded yesterday, armbian stretch 9 (mainline based kernel 4.19.y).
  7. @Igor, you know, I just installed the newest image (stretch) and it's the same! moreover, now even uboot reports 1GB.
  8. Hi. I have a 2GB Pine64+ and have armbian on it. Yes, it's not new, but I noticed the problem only now. It's because my use - in short, I use these boards for hobbyistic low level programming - say an OS loader writing, so it's flash and test, never been looking into linux too deep - only needed utilities. staring at the top is not of that set. Now, when reached the DT parsing, passed by uboot, on this board, my loader, noticed 1GB of RAM... Basically, 1GB, as I see, is a default value set in the dts for pine64-plus yet. The DT is not updated on the fly by uboot, as it
  9. 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.
  10. 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.
  11. 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 su
  12. 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.
  13. Thank you! Oh my god, I feel so stupid - the post about exactly this is just on this very page!
  14. 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 you