Fred St-Pierre

  • Content Count

  • Joined

  • Last visited

About Fred St-Pierre

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You have more info on how to achieve this? I'd love to be able to use the SPI chip on this board...
  2. I knew it wouldn't boot, but I attempted anyway... It does not indeed boot, as it's probably just built for SD/EMMC and does not have SPI configs... However, I'm massively intrigued at how they pad their u-boot image. I'll have to dig through their makefile to see how they piece everything together. I might be able to make a proper image that boots off SPI with nvme support.
  3. Ah. And have you tried booting that u-boot image from SPI? I'll have to see how the armbian build system pads its u-boot image...
  4. I'd really like to know if you compiled that yourself (uboot) or just pulled that from the amarula forum?
  5. Nope, but potentially a next step, if firefly doesn't get back to me.
  6. For the kernel and OS, but what about u-boot support? This is what matters to me, using this board with its intended purpose: u-boot off SPI with nvme support and I am unable to get this going.
  7. Thanks for the info, but it's not compiling the image that's an issue, it's getting a functional u-boot off the SPI NOR with nvme support... I have most of the parts in place, it just does not boot when flashed to SPI. I built an Armbian build just fine and it works on SD, that's not an issue... There's a lot of info in this thread about progress, as in I'm able to compile a u-boot version with mainline code, I'm able to patch with the files supplied to add nvme support, but none of those u-boot compiled versions end up working when flashed on SPI. There's conflicting information as to what offsets to flash. For example, the package supplied by loverpi flashed idbloader.img at offset 0x00, which is over 900k as opposed to the compiled one which is 236k. Then the package flashes the u-boot.itb at offset 0x4000. I've seen references of offset 0x40000 and 0x200, but none of those combinations work. Then there's the latest doc supplied by loverpi, which offers NO help whatsoever, as their codebase is almost identical to mainline, which just doesn't work. They do provide an image which covers the entire SPI's 16MB with initramfs and boots. However, it gives little hindsight about what is required to make a bootable image from mainline, just their fork of the u-boot code. So again, Libre/loverpi/firefly provides little to no support to get this hardware working with mainline, which is what they keep saying they were aiming to do. This board has INSANE potential if only mainline code could be easily used with ALL their hardware without jumping through hoops. The biggest missing part/irritant right now is nvme support for the mezzanine board and SPI NOR booting. If someone, anyone, is able to figure that part out, then this board will have all that's necessary to serve its intended purpose and we won't ever need support from the board designers/supporters. This is my goal, as they are in no way helpful. **edit** upon hex viewing roc-rk3399-pc-spinor.img from the package supplied by Loverpi, seems like u-boot.itb is in the image at 0x40000 as recommended earlier in the thread. Where it gets complicated is flashing idbloader.img so it works. The image seems to have a bunch of padding I can't make sense of.
  8. And still can't boot their image... Nor is any of their text helpful, except the fact they supply a prebuilt image which boots, but goes nowhere and ends up just not working. Am I the problem? It seems so... Guess I'll make another build environment than on WSL2.
  9. Loverpi FINALLY answered me. Here is the documentation to compile u-boot for SPI:
  10. Tried a debian distro and an ubuntu distro, same result. I did see in the thread some people mentioning you needed an image with SPL and TPL, noticed TPL doesn't get compiled in mainline. Also saw some other reference about image padding being required for SPI like in this example below. Tried to use that to build a custom idbloader with no success. Otherwise, I noticed idbloader is purely built with SPL with the mkimage command: cmd_idbloader.img := ./tools/mkimage -n "rk3399" -T rkspi -d spl/u-boot-spl.bin idbloader.img >/dev/null However, in the spoiler example below and on - They seem to build the image quite differently. I've contacted loverpi, they just don't answer back. Firefly is my next option to stop trying to figure out their design.
  11. I built BL31 from scratch and tried, I used the one supplied by rkbin's git repo and tried... So that's been explored. And hexdump gives me the same info for 0x1000. I'm really at a loss, honestly. Thanks for the help, I appreciate it, but I think this thing is going back in the drawer for now... Just wondering if I'm gonna sell it.
  12. Yeah, resetting the SPI NOR isn't an issue, I've become skilled at that in the last months. I did remove all bootable drives, SD and NVMe... I'll check if SPL is loaded through lsusb and try and debug to see... Might be my build environment also, who knows. Where are you building u-boot from? Are you using any cross compilers? If ever you can share your compiled u-boot and loader, I'd be curious to see if it works on my board. Thanks! **edit** Ok, I can confirm spl is not loaded properly, so clearly there's something wrong with how I compile... I'll have to troubleshoot.
  13. I managed to compile the image and flash according to your specs, but still doesn't work... I can't load the loader in rkdeveloptool for some reason, so I used the flash tool supplied by loverpi. If I flash u-boot.itb to any offset (0x200, 0x4000 or 0x40000), it just doesn't post on HDMI (No signal). Is it supposed to post? Because loverpi's mainline u-boot posts when there's no bootable disk (SD/EMMC/NVMe)
  14. GREAT news! I was getting annoyed with messing around with this Thanks for the files!
  15. Yeah, there's clearly something not working to boot it from SPI... If I look at the mainline compiled by Loverpi, the mainline files that they use are: idbload_spi.img sized 980992, the other one is u-boot.itb sized 940856. The fact the idbload_spi.img is almost as big as u-boot.itb makes me believe they are manipulating it in a specific way, as my idbloader is 151754 or 81920 depending on my compilation scenarios. Sigh... I hate the support from this board's manufacturer. W