02-02-2020, 08:06 PM
(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.
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
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.