02-02-2020, 11:40 AM
(02-01-2020, 02:25 PM)Bullet64 Wrote:Everything that I tested before still works. I am able to boot a samsung t1 on USB3 (not C) (that's an SSD, but I thought it was SATA, I'll need to check the specs), but I did before. Thanks for the "erase" image.(02-01-2020, 11:06 AM)sigmaris Wrote: I have updated the OP with info about a new release, based on mainline U-Boot v2020.01, and now with PCIe SATA drive boot support as well as NVMe.
There are also patches on the U-Boot mailing list which get HDMI output working from U-Boot. I've tested this and it works as expected, but I've not included it in the current build becauseIn any case, if anyone is interested, you can see the changes required for HDMI and USB keyboard support in this branch.
- Using HDMI output from U-Boot seems to break HDMI output from mainline Linux until a Linux app runs that changes the video mode, which resets HDMI and gets it working again.
- to be properly useful to interact with U-Boot, it'd require a USB keyboard, but starting U-Boot's USB support (required before any keyboard is recognised) takes several seconds, and it doesn't seem worthwhile to slow down every boot with the "usb start" command when normally it's not required.
Will test this later. Thank you!
Edit: sata boot works as expected
People have started to build mainline u-boot for the Pinebook-pro, I'd like to try with a more robust dts than is being used (something based more on the manjaro one). People are going through all kins of trouble writing to spi_flash with rkpdeveloptools to write the current mainline, but I'd love to be able to provide them with a bootable flashing image like yours. Sometimes the connections with rkdevelptools are a bit problematic.
The one thing I don't understand (I'm a linux newbie) is how to write the flashable image to get the correct "padding" between the idbloader.image and u-boot.itb. Is it just a dd command? thnx
Also, Is it possible to just (through the serial console) stop u-boot, probe, load the spi image (from whatever you are running u-boot), and sf update? I guess I don't understand why one would have to disable the other devices to do that. OF course once the flash was written, you'd have to stop u-boot and reboot, I guess. Just curious...