(10-19-2020, 10:50 AM)sigmaris Wrote: (10-18-2020, 07:56 PM)voltagex Wrote: Am I completely missing where the binaries are for this? You've skipped the GitHub release for that branch.
Additionally, is it possible to increase u-boot's debug level? It might help me solve an unrelated issue.
The binaries are published as build artefacts, attached to the build in Azure Pipelines - click on the "3 published" link on the build page I linked to before, to download them. As I said above, when v2.4 of ARM Trusted Firmware is released, I'll tag a Github release.
If you want a debug build, look at the build pipeline script (reference for the pipeline syntax) and other guides to building U-Boot from source, modify the source code to set the debugging/logging you want, and build it according to the same process. The latest artifacts from 20201108 (yesterday) cannot be downloaded from Azure Pipelines as before.
There is a popup requesting account+password to login to Microsoft Azure.
Is this intentional?
Sorry for any mistakes. English is not my native language
1. Quartz64 Model B, 4GB RAM
2. Quartz64 Model A, 4GB RAM
3. RockPro64 v2.1
https://linux-nerds.org/
As TF-A 2.4 has been released, I've made a new U-Boot release based on U-Boot 2020.10 with TF-A 2.4:
https://github.com/sigmaris/u-boot/relea...ckpro64-ci
It's marked as a pre-release at the moment, but that's just due to only me having tested it - please test it out and let me know if there are any new issues (beyond the known issue of USB-3 boot being unreliable).
Hi @ sigmaris , i am testing your u-boot 2020.10. When i boot from PCIe NVMe SSD boot process stuck @ "Booting using the fdt blob at 0x1f0000".
Sorry for any mistakes. English is not my native language
1. Quartz64 Model B, 4GB RAM
2. Quartz64 Model A, 4GB RAM
3. RockPro64 v2.1
https://linux-nerds.org/
Hi @ sigmaris , first thanks for your work!
But I have a problem here and I would use some help.
- I have a RockPro64 (I guess rev 2.3)
- a 32Gb Samsung SD Card class 10
- one 120Gb SSD
- two 4Tb HDD
The SSD and the two HDDs are connected using a Ziyituod SATA Card (with a Marvell 88SE9215 chip).
I can install Armbian on the SD card, then use armbian-config to put the system on the SSD while keeping the bootloader on the SD Card.
But I would like to not rely on the SD Card and thus, use SPI to boot directly on the SATA SSD.
- I have downloaded your flash_spi.img.gz (from your 2020.10 release)
- I've extracted the img and wrote it on the SD Card
- I inserted the card into the RockPro64 and booted, then waited for the white led to stop blinking (following your guide : https://github.com/sigmaris/u-boot/wiki/...oot-to-SPI )
- I took the SD Card back, wrote the latest release of Armbian on it
- Booted in Armbian and apt update/upgrade
- I used armbian-config with the "Boot from SPI - Install on SATA" option, installed the system on the SATA SSD
- I accepted for armbian-config to update the bootloader
But when I reboot without the SD Card, the system just won't boot. The RockPro is lighting up as well as the SATA card, but no white LED and no SSH available, even after letting it boot for 20 minutes.
I have tried multiple times with variations (trying to flash_spi.img AFTER installing the system, not accepting armbian-config to update the bootloader, etc...) but to no avail.
Did I miss something or do something wrong?
12-16-2020, 12:21 PM
(This post was last modified: 12-16-2020, 12:23 PM by sigmaris.)
(11-23-2020, 03:22 PM)Bullet64 Wrote: Hi @sigmaris , i am testing your u-boot 2020.10. When i boot from PCIe NVMe SSD boot process stuck @ "Booting using the fdt blob at 0x1f0000".
I've seen a few similar reports of the kernel not booting with recent mainline U-Boot, not just this build. Are you loading the u-boot env from SPI? If so, you could try removing the "usb start" from the "preboot" env variable to avoid initialising USB, as I read that having USB initialised by U-Boot might be related with the kernel not booting.
(11-30-2020, 02:41 PM)Waryle Wrote: Hi @sigmaris , first thanks for your work!
But I have a problem here and I would use some help.
- I have a RockPro64 (I guess rev 2.3)
- a 32Gb Samsung SD Card class 10
- one 120Gb SSD
- two 4Tb HDD
The SSD and the two HDDs are connected using a Ziyituod SATA Card (with a Marvell 88SE9215 chip).
I can install Armbian on the SD card, then use armbian-config to put the system on the SSD while keeping the bootloader on the SD Card.
But I would like to not rely on the SD Card and thus, use SPI to boot directly on the SATA SSD.
- I have downloaded your flash_spi.img.gz (from your 2020.10 release)
- I've extracted the img and wrote it on the SD Card
- I inserted the card into the RockPro64 and booted, then waited for the white led to stop blinking (following your guide : https://github.com/sigmaris/u-boot/wiki/...oot-to-SPI )
- I took the SD Card back, wrote the latest release of Armbian on it
- Booted in Armbian and apt update/upgrade
- I used armbian-config with the "Boot from SPI - Install on SATA" option, installed the system on the SATA SSD
- I accepted for armbian-config to update the bootloader
But when I reboot without the SD Card, the system just won't boot. The RockPro is lighting up as well as the SATA card, but no white LED and no SSH available, even after letting it boot for 20 minutes.
I have tried multiple times with variations (trying to flash_spi.img AFTER installing the system, not accepting armbian-config to update the bootloader, etc...) but to no avail.
Did I miss something or do something wrong?
I'm not exactly sure, as I haven't tried armbian-config myself. Are you able to get logs of the boot process via the UART/serial console? Failing that, U-Boot does now have HDMI support and hopefully would display some messages on a connected HDMI display.
(12-16-2020, 12:21 PM)sigmaris Wrote: (11-23-2020, 03:22 PM)Bullet64 Wrote: Hi @sigmaris , i am testing your u-boot 2020.10. When i boot from PCIe NVMe SSD boot process stuck @ "Booting using the fdt blob at 0x1f0000".
I've seen a few similar reports of the kernel not booting with recent mainline U-Boot, not just this build. Are you loading the u-boot env from SPI? If so, you could try removing the "usb start" from the "preboot" env variable to avoid initialising USB, as I read that having USB initialised by U-Boot might be related with the kernel not booting.
Thanks for this - that's exactly what I had to do to get your latest uboot to... well, boot haha.
Additionally I had to disable the pci bus enumeration (forgot exactly how I did it, just poked around the env over serial) to make it so that the Rockpro64 doesn't insta-crash with a "synchronous abort" when I had my LSI 9211 card plugged in. Luckily Manjaro's 5.9.13 kernel properly initializes the card without crashing (needed to add the mpt3sas driver to initramfs); strangely the latest Arch kernel (5.8.x) hangs once u-boot hands off control no matter what I do which is why I'm "borrowing" Manjaro's kernel.
01-05-2021, 05:14 AM
(This post was last modified: 01-05-2021, 06:18 AM by jja2000.)
(12-16-2020, 12:21 PM)sigmaris Wrote: (11-23-2020, 03:22 PM)Bullet64 Wrote: Hi @sigmaris , i am testing your u-boot 2020.10. When i boot from PCIe NVMe SSD boot process stuck @ "Booting using the fdt blob at 0x1f0000".
I've seen a few similar reports of the kernel not booting with recent mainline U-Boot, not just this build. Are you loading the u-boot env from SPI? If so, you could try removing the "usb start" from the "preboot" env variable to avoid initialising USB, as I read that having USB initialised by U-Boot might be related with the kernel not booting.
I'm running into the same problem. How do I remove usb start from the preboot env variable? Booting timeout is on 0 so I don't have the chance to mash any keys.
(01-05-2021, 05:14 AM)jja2000 Wrote: (12-16-2020, 12:21 PM)sigmaris Wrote: (11-23-2020, 03:22 PM)Bullet64 Wrote: Hi @sigmaris , i am testing your u-boot 2020.10. When i boot from PCIe NVMe SSD boot process stuck @ "Booting using the fdt blob at 0x1f0000".
I've seen a few similar reports of the kernel not booting with recent mainline U-Boot, not just this build. Are you loading the u-boot env from SPI? If so, you could try removing the "usb start" from the "preboot" env variable to avoid initialising USB, as I read that having USB initialised by U-Boot might be related with the kernel not booting.
I'm running into the same problem. How do I remove usb start from the preboot env variable? Booting timeout is on 0 so I don't have the chance to mash any keys.
If I'm not mistaken, even with a timeout of 0 - there is a narrow window to stop the automatic boot process. Just had to mash keys in the UART console right as you turn your SBC on. At least that's how I was able to muck around in the uboot console.
(01-05-2021, 10:23 AM)amiraeva Wrote: (01-05-2021, 05:14 AM)jja2000 Wrote: (12-16-2020, 12:21 PM)sigmaris Wrote: (11-23-2020, 03:22 PM)Bullet64 Wrote: Hi @sigmaris , i am testing your u-boot 2020.10. When i boot from PCIe NVMe SSD boot process stuck @ "Booting using the fdt blob at 0x1f0000".
I've seen a few similar reports of the kernel not booting with recent mainline U-Boot, not just this build. Are you loading the u-boot env from SPI? If so, you could try removing the "usb start" from the "preboot" env variable to avoid initialising USB, as I read that having USB initialised by U-Boot might be related with the kernel not booting.
I'm running into the same problem. How do I remove usb start from the preboot env variable? Booting timeout is on 0 so I don't have the chance to mash any keys.
If I'm not mistaken, even with a timeout of 0 - there is a narrow window to stop the automatic boot process. Just had to mash keys in the UART console right as you turn your SBC on. At least that's how I was able to muck around in the uboot console. I read that you could use escape in UART yes, I was hoping that I could do it through the videoconsole too. Time to bust out the CP2102 then 
|
