03-11-2017, 12:39 PM
(This post was last modified: 03-11-2017, 12:45 PM by kenneth558.)
I own a Pine64 in service as my home thermostat, among other things. Point is that my Pine64 stays in my house for the winter, I don't take it out of service for any kind of development purposes. I don't live in my home much, so for development purposes, I check out a Pine64 SBC from a tech library nearby where my wife lives with me much of the time (long story).
I ran longsleep's script line (below) on the public SBC:
Code: bash <(curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh)
Note that this tech library has their own image which they expect to function in their Pine64, but I am testing MY image in their board. (My image might be DietPi or whatever with a goal of getting to a nice looking, user-friendly GUI front end. OpenHAB is on my radar.)
After I ran the uboot updating script line while testing a Pine 64 image, the library's Pine 64 board will no longer boot into their image. Can someone please explain: Does longsleep's aforementioned uboot script line forever afterwards render a Pine64 board dependent on specifically configured boot partitions/files that this tech library doesn't use? Have I virtually bricked their property if they won't change their image to match what I did to their board?
U-Boot is on the sdcard and updating it cannot render another image on another sdcard unbootable. It does not change anything on the Pine64 hardware - everything is on the sdcard (including bootloader and u-boot).
03-11-2017, 08:37 PM
(This post was last modified: 03-11-2017, 08:40 PM by kenneth558.)
(03-11-2017, 12:48 PM)longsleep Wrote: U-Boot is on the sdcard and updating it cannot render another image on another sdcard unbootable. It does not change anything on the Pine64 hardware - everything is on the sdcard (including bootloader and u-boot). Thank you. What had me confused was that apritzel included u-boot in his description of the board's firmware ( https://github.com/apritzel/pine64). In my thinking, "firmware" technically would never be found stored on removable media.
Your confusion maybe comes from the fact that APritzel U-Boot is now supporting SPI-NOR with FIT image, which allows to have Pine64 booting from external SPI Flash along with USB drive without any SDCard inserted.
03-12-2017, 11:44 AM
(This post was last modified: 03-12-2017, 12:34 PM by kenneth558.)
(03-12-2017, 09:17 AM)martinayotte Wrote: Your confusion maybe comes from the fact that APritzel U-Boot is now supporting SPI-NOR with FIT image, which allows to have Pine64 booting from external SPI Flash along with USB drive without any SDCard inserted. My confusion is because back in the day, the term "firmware" meant on-board code. I've lost track of the changing meaning over the years because I got out of the field about 15 years ago.
I certainly am fascinated with the SPI-NOR/FIT notion. I'd like to learn enough about it to implement it. I worked a an electronics technician, soldering and all, for plenty of years that I have no problem with putting the hardware together. I have plenty of script coding experience as well, so I am up for all of it. It is just the terminology being used for everything, trying to conceptualize where all the software pieces reside, that slows me down.
(03-12-2017, 11:44 AM)kenneth558 Wrote: (03-12-2017, 09:17 AM)martinayotte Wrote: Your confusion maybe comes from the fact that APritzel U-Boot is now supporting SPI-NOR with FIT image, which allows to have Pine64 booting from external SPI Flash along with USB drive without any SDCard inserted. My confusion is because back in the day, the term "firmware" meant on-board code. I've lost track of the changing meaning over the years because I got out of the field about 15 years ago.
I certainly am fascinated with the SPI-NOR/FIT notion. I'd like to learn enough about it to implement it. I worked a an electronics technician, soldering and all, for plenty of years that I have no problem with putting the hardware together. I have plenty of script coding experience as well, so I am up for all of it. It is just the terminology being used for everything, trying to conceptualize it where all the software pieces reside, that slows me down. it's not even relegated to a "back in the day" situation for some sbc [minnowboard max/turbot for example] still are updated via the flashrom utility which flashes updates to the "firmware" via onboard IC. so it's better noted as based on board design and that those ancient designs are still in use today depending on which board is in use. i realize the discussion here is based on pine64 i just wanted to toss out that those who long for "the day" can still find it if desired. i admit it's fun taking out the spi flashing board every once in a while.
Over the years, "firmware" probably just outgrew it's original meaning ;-)
On the A64, you still have a fixed BROM (BootROM) in the chip, but that is just there to load further stages of 'firmware' like the first stage loader (boot0/spl) and what ARM introduced with the ARMv8 architecture and calls the "ARM Trusted Platform Firmware" (ATF) which takes care of several things like security, power management, etc. and then u-boot which in turn loads the linux kernel... where those different 'firmwares' are stored varies a lot between different SoC...
(03-12-2017, 12:38 PM)xalius Wrote: Over the years, "firmware" probably just outgrew it's original meaning ;-)
On the A64, you still have a fixed BROM (BootROM) in the chip, but that is just there to load further stages of 'firmware' like the first stage loader (boot0/spl) and what ARM introduced with the ARMv8 architecture and calls the "ARM Trusted Platform Firmware" (ATF) which takes care of several things like security, power management, etc. and then u-boot which in turn loads the linux kernel... where those different 'firmwares' are stored varies a lot between different SoC... and where would the SPI-NOR, when present, come in to play in this sequence?
I'd like a diagram of that SPT-NOR - FIT wiring and boot process for my troubleshooting purposes when I go there.
03-12-2017, 12:52 PM
(This post was last modified: 03-12-2017, 12:53 PM by xalius.)
The SPI flash has to be attached to SPI0 and comes last in the boot priority list, so it is only booted if you do not have valid boot0 on the sdcard or eMMC. The new SOPine modules have a SPI Flash on board, but you can add one via the expansion headers to regular pine boards as well.
More Info: http://linux-sunxi.org/Bootable_SPI_flash
A64 boot sequence:
Code: boot-> check fel key pressed (yes)--> FEL mode (boot from USB OTG)
\
(no) \
\-------> 1) try to boot from SMHC0 (SD card)
2) try to boot from SMHC2 (eMMC)
3) try to boot from SPI0 (SPI NOR Flash)
4) FEL mode (boot from USB OTG)
03-12-2017, 01:03 PM
(This post was last modified: 03-12-2017, 01:22 PM by kenneth558.)
(03-12-2017, 12:52 PM)xalius Wrote: The SPI flash has to be attached to SPI0 and comes last in the boot priority list, so it is only booted if you do not have valid boot0 on the sdcard or eMMC. The new SOPine modules have a SPI Flash on board, but you can add one via the expansion headers to regular pine boards as well.
More Info: http://linux-sunxi.org/Bootable_SPI_flash
A64 boot sequence:
Code: boot-> check fel key pressed (yes)--> FEL mode (boot from USB OTG)
\
(no) \
\-------> 1) try to boot from SMHC0 (SD card)
2) try to boot from SMHC2 (eMMC)
3) try to boot from SPI0 (SPI NOR Flash)
4) FEL mode (boot from USB OTG)
ABSOLUTELY PRICELESS !!
SD card boot with the rootfs on thumbdrive or other USB-connected drive is included in 1 somehow, I assume?
Is USB/OTG booting here now? Or is it future? Those search terms are too short to do a forum search for them.
|
