![]() |
Mainline U-Boot with SPI, NVMe and SATA boot support - Printable Version +- PINE64 (https://forum.pine64.org) +-- Forum: ROCKPRO64 (https://forum.pine64.org/forumdisplay.php?fid=98) +--- Forum: General Discussion on ROCKPRO64 (https://forum.pine64.org/forumdisplay.php?fid=99) +--- Thread: Mainline U-Boot with SPI, NVMe and SATA boot support (/showthread.php?tid=8685) |
RE: Mainline U-Boot with SPI and NVMe support (alpha/pre-release version for testing) - themyshop - 01-07-2020 Hi, I ported simply the latest Ayufan U-Boot Aug 26 2019 version (http://github.com/ayufan-rock64/linux-u-boot) to support of boot only from nvme (I added PCIe support from http://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts and I enabled the NVMe and PCIe in defconfig: CONFIG_NVME, CONFIG_PCIE_ROCKCHIP). Linux boot perfectly only from NVMe, but unfortunately Android not. I tried already all Android version from http://wiki.pine64.org/index.php/ROCKPro64_Software_Release#Android_Images. And I parted the SSD as SD card (same name, type and begin/size sectors of partitions, etc.). But nothing. Code: ... Moreover, the Android doesn't start from the SD card with the original latest Ayufan U-Boot 2017.09-rockchip-ayufan-1065-g95f6152134 (Aug 26 2019 - 12:41:34 +0000) (http://github.com/ayufan-rock64/linux-u-boot/releases/tag/2017.09-rockchip-ayufan-1065-g95f6152134) either! Code: ... Maybe does anyone have an bootable Android version? Or compiled Android with PCIe and NVME support? Thank you for your help! Or possible boot the Android from extlinux? My suggestions yet for the NVME port: 1. increase the SPL size (prevent of .sram size error in compile) in include\configs\rk3399_common.h: Code: //#define CONFIG_SPL_MAX_SIZE 0x10000 2. I needed to decrease (1 MB => 512 kB) the Maximum Data Transfer Size (MDTS) for my Samsung 970 PRO M.2 512GB NVMe SSD in drivers\nvme\nvme.c: Code: static int nvme_get_info_from_identify(struct nvme_dev *dev) RE: Mainline U-Boot with SPI and NVMe support (alpha/pre-release version for testing) - belfastraven - 01-12-2020 (01-07-2020, 03:27 PM)belfastraven Wrote:@Bullet64,@sigmaris(01-04-2020, 04:04 AM)sigmaris Wrote:I now have armbian booting from SPI flash u-boot, its great to be booting from SPI running 5.4.8 kernel with current u-boot. I have booted sdcard, emmc and pcie NVME. I haven't tried with USB ports yet. I had gone back to ext4.(01-03-2020, 07:52 PM)belfastraven Wrote: ... @Bullet64,@sigmaris,Running the same self-built armbian image (5.4.8 kernel, ubuntu bionic) booting from SPI flash, I can boot sd, emmc, nvme, USB3 sandisk extreme stick on esb2 ports, but not on usb3 ports, Samsung t1 portable SSD USb3 on USB3 ports, and an old usb2 datatraveler stick on the usb3 ports. I don't understand why the usb3 stick won't boot from the USB3 port, and have a feeling it might be a timing issue, since the system will boot from slower devices on that port...I'm not good at hardware debugging, but perhaps one of you will have an idea? The way the "not booting" manifests itself is that I will get the "Starting kernel" message, and then nothing... which makes it hard to debug. Sorry I had forgotten to turn the kernel log level up-- with log level at 7, I can now see that the one USB3 stick that wouldn't boot on the USB 3 port was not being recognized as a USB3 device. usb 7-1: new full-speed USB device number 2 using xhci-hcd [ 4.040775] usb 7-1: device descriptor read/64, error -71 [ 4.276738] usb 7-1: device descriptor read/64, error -71 [ 4.512670] usb 7-1: new full-speed USB device number 3 using xhci-hcd [ 4.640722] usb 7-1: device descriptor read/64, error -71 [ 4.876677] usb 7-1: device descriptor read/64, error -71 [ 4.984926] usb usb7-port1: attempt power cycle [ 5.636665] usb 7-1: new full-speed USB device number 4 using xhci-hcd [ 5.637366] usb 7-1: Device not responding to setup address. [ 5.844773] usb 7-1: Device not responding to setup address. [ 6.052665] usb 7-1: device not accepting address 4, error -71 [ 6.180668] usb 7-1: new full-speed USB device number 5 using xhci-hcd [ 6.181370] usb 7-1: Device not responding to setup address. [ 6.388747] usb 7-1: Device not responding to setup address. [ 6.596665] usb 7-1: device not accepting address 5, error -71 [ 6.597479] usb usb7-port1: unable to enumerate USB device [ 10.364793] phy phy-ff770000.syscon:usb2-phy@e450.2: charger = USB_DCP_CHARGER whereas a different USB3 stick was properly recognize and booted: 3.602830] hub 8-0:1.0: 1 port detected [ 4.692711] usb 8-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd [ 4.713725] usb 8-1: New USB device found, idVendor=0781, idProduct=558a, bcdDevice= 1.00 [ 4.714490] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4.715152] usb 8-1: Product: Ultra [ 4.715488] usb 8-1: Manufacturer: SanDisk [ 4.715879] usb 8-1: SerialNumber: 4C530001241105113443 [ 4.718156] usb-storage 8-1:1.0: USB Mass Storage device detected [ 4.719355] scsi host0: usb-storage 8-1:1.0 [ 4.725283] usbcore: registered new interface driver uas [ 5.729461] scsi 0:0:0:0: Direct-Access SanDisk Ultra 1.00 PQ: 0 ANSI: 6 [ 5.731615] sd 0:0:0:0: [sda] 240254976 512-byte logical blocks: (123 GB/115 GiB) [ 5.733312] sd 0:0:0:0: [sda] Write Protect is off [ 5.734191] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 5.775435] sda: sda1 [ 5.778568] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 5.974332] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) Probably there was something wrong with the stick tisellf..... So all seems good here. RE: Mainline U-Boot with SPI and NVMe support (alpha/pre-release version for testing) - sigmaris - 01-25-2020 On the topic of USB boot, I've managed to get a USB-3 Samsung M3 Portable hard drive and done some testing. With this mainline U-Boot build: - USB 2.0 flash drive SanDisk Cruzer Blade
With U-Boot 2017.09-rockchip-ayufan-1065-g95f6152134: - USB 2.0 flash drive SanDisk Cruzer Blade
Quote:Only support usb2.0 currently for we have not enable the usb3.0 phy driver and PD(fusb302) driver. So USB 3.0 devices will probably only work if they are forced to work in USB 2.0 mode, e.g. by being plugged into the USB 2.0 ports. RE: Mainline U-Boot with SPI and NVMe support (alpha/pre-release version for testing) - sigmaris - 02-01-2020 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 because
RE: Mainline U-Boot with SPI and NVMe support (alpha/pre-release version for testing) - Bullet64 - 02-01-2020 (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. ![]() Edit: sata boot works as expected ![]() RE: Mainline U-Boot with SPI and NVMe support (alpha/pre-release version for testing) - belfastraven - 02-02-2020 (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. 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... RE: Mainline U-Boot with SPI and NVMe support (alpha/pre-release version for testing) - sigmaris - 02-02-2020 (02-02-2020, 11:40 AM)belfastraven Wrote: 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.It would be cool to see a similar mainline U-Boot project for Pinebook Pro. I don't have a PBP, otherwise I would work on it, but if someone who has a PBP can take my work and adapt it that'd be great. If you're asking about how to create spi_combined.img, it can be done using a dd command. On RK3399 the idbloader.img is always read first from a fixed location, SPI offset 0, by the boot ROM. Then, u-boot.itb is loaded by the code inside idbloader.img, from a configurable offset, set at U-Boot build time using CONFIG_SYS_SPI_U_BOOT_OFFS - you can see in that linked file it's set to 0x60000 for this build. So, assuming idbloader.img is less than 0x60000 bytes long, we want to include padding after it so that u-boot.itb starts at 0x60000. This is done here in the build script, in particular this line: Code: dd if=/dev/zero of=$(img1name) conv=notrunc bs=1 count=1 seek=$padsize pads the file $(img1name) to $padsize+1 (by seeking to offset $padsize and writing a single zero byte). $padsize is set to (0x60000 - 1) a few lines above. Then the u-boot.itb can just be concatenated on the end, using the cat command, to make spi_combined.img. Then the flash script just loads that image to the address where a kernel would normally be loaded (${kernel_addr_r}) and then uses the "sf update" command to write it to SPI flash. (02-02-2020, 11:40 AM)belfastraven Wrote: 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...Yes, it is possible to boot from any medium, stop autoboot, enable the SPI flash (if disabled) then run the commands in the flash script at the U-boot prompt to achieve the same effect as booting from a SD-card containing the flash_spi.img. Omitting the "run blink_work" commands, of course, since they just blink the white LED. The only reason to need to disable SPI to do this is if somehow the code currently in your SPI won't boot up correctly as far as U-Boot proper, and you need to stop the Boot ROM trying to load it at all, to be able to do this. RE: Mainline U-Boot with SPI and NVMe support (alpha/pre-release version for testing) - belfastraven - 02-02-2020 (02-02-2020, 03:59 PM)sigmaris Wrote:Thank you for your help/explanation. I am going to try to implement this, but I believe that Bluerise (Patrick Wildt) whose pcie driver you are now using , might have a PinebookPro, too, and if he tries, it will probably happen faster :-)(02-02-2020, 11:40 AM)belfastraven Wrote: 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.It would be cool to see a similar mainline U-Boot project for Pinebook Pro. I don't have a PBP, otherwise I would work on it, but if someone who has a PBP can take my work and adapt it that'd be great. RE: Mainline U-Boot with SPI, NVMe and SATA boot support - Thovthe - 02-20-2020 Looking forward to seeing this come to the PBP RE: Mainline U-Boot with SPI, NVMe and SATA boot support - hunderteins - 03-10-2020 Wow! Thank you for your work. My RockPro64 boots directly from SPI into "scsi" without mmc. Well done! I have two "problems" identified on v2020.01ci: (1) reboot from linux will not longer work. The machine just stands. Kernel 4.4 (2) is this huge (16384 sectors) offset on mmc-u_boot.itb really necessary? mmc_idbloader.img is about 148kB. Do you wanted to go for 0x80000 (1024 sectors) and got 0x800000? Keep on hacking, hunderteins |