• Content Count

  • Joined

  • Last visited

About valant

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Interests
    system programming

Recent Profile Visitors

984 profile views
  1. 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's a very insignificant defect inside memory chip. But again, for proper handling such situations, memory testing functionality should be included inside firmware. PutString("DEBUG: checking 8 bytes of every page beginning at the 2nd GB.\r\n"); p = (PUINT64)0x0080000000; for(i = 0; i < 0x40000; i++){ if(!(i % 0x50))PutString("\r\n"); *(p + (i<<9)) = 0xb16b00b5cafebabe; PutString("."); } PutString("\r\nDEBUG: reading back: "); PrintUintn(*p); PutString("\r\n");
  2. 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 back the starting word and it matched. So, I suppose, it's not that bad as a bad soldered bank. instead, there are some bad pages, maybe even just 1. Too bad uboot doesn't do any testing or at least doesn't report bad pages as for example UEFI does, passing this for an OS. Basically because of some broken bits, maybe not more than occupying just one page, entire gigabyte is cut off... that sucks. Well, thanks @Igor and @martinayotte for your advices.
  3. 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.
  4. val@pine:~$ free total used free shared buff/cache available Mem: 1017160 57956 850320 2956 108884 889600 Swap: 508576 0 508576
  5. downloaded yesterday, armbian stretch 9 (mainline based kernel 4.19.y).
  6. @Igor, you know, I just installed the newest image (stretch) and it's the same! moreover, now even uboot reports 1GB.
  7. 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 looks should be. and when I went to Linux, I saw the same - it sees it as 1GB! I don't see different downloads for variants of this board, so how does armbian distinguish between them? Is that discrimination being done right? I saw in the output, that uboot does see 2GB of RAM, still passes stale information in the DT. What is this, how do you think, is it my miserable fault, a known problem, got it fixed now? Maybe a lot of people keep using their 2GB models not even suspecting linux sees only 1GB?
  8. 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.
  9. 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.
  10. 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?
  11. 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.
  12. Thank you! Oh my god, I feel so stupid - the post about exactly this is just on this very page!
  13. 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.
  14. 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.