After attaching power, the Green and Red LEDs should light up. This indicates that the board is powered. Nothing will show up on HDMI or CVBS yet.
At no point after attaching power should the Red LED blink or turn off. If this happens, it means that your power supply is inadequate. Please make sure that you are using a 5V power supply capable of supplying at least 1.5A (1500mA). Not having enough power could cause spontaneous reboots or software errors.
The board will try to read the bootloader from the eMMC and then the MicroSD card from sector 64 (32KB). If the correct signed bootloader is detected, the board will begin loading it.
After 30 seconds, Linux should be loaded and the Green LED should begin to heartbeat. You should see video on your HDMI display. Certain types of displays with odd resolutions are not supported at this stage and it might not display anything during this step and the next steps. If the Green LED turns green and nothing shows on your screen, please post your screen brand, model, and EDID here.
The bootloader will attempt to EFI boot from a list of block devices:
eMMC
MicroSD
USB Flash Drive
It looks for an FAT/EFI partition with /boot/bootaa64.efi, loads the file into memory, and executes the it. On our images, bootaa64.efi is GRUB.
I can confirm by testing my 4 libre boards that ā¦ if you install the ubuntu image ā¦ this is correct and that the red LED will be constant if powered correctly, and the green LED will double flash a heartbeat every second.
However if you install raspbian or the armbian images. the green led will not be illuminated (it is on boot but only for a few seconds then it goes off) and the red led will instead flash the same double heartbeat pattern every second.
This documentation had me very confused so I am just posting this to try and clarify that some images act differently than others with respect to the LEDās. I apologise in advance if I am mistaken but this is what my testing over the last 3 days has bore out.
Also there is very little info on the small recovery button available, so all i can learn about that is that it is a recovery button and not a reset/power button
Have you tried using the libretech-flash-tool to re-image the bootloader on your Renegades? In a thread I started in November of last year regarding a different topic ( [Vdd_arm: ramp_delay not set kernel messages on Renegade]) it was recommended that I do so on my Renegade pair and it not only fixed my ramp_delay issue but it also set the LEDs to work in the way described in the documentation. Both of mine have been running the Libre Raspbian 11 image since December and the LEDs are RED on when running correctly and green pulsing heartbeat. YMMV of course!
Thanks man!, I didnāt even know about that flash tool!. Okay so for clarification, I flashed my images using the raspberry pi imager in all cases where it didnāt work properly and the the lights flashed incorrectly. once i switched to balena etcher then things worked. so I think you are correct there!
Do you think using this flash tool will also fix my issues with 2 of my 4 not automatically coming back on after issuing reboot commands? seems unlikely as they all have the same sd cards, same peripherals same power sources & cables etc. I will try it and find out - thanks for pointing that out!
You should probably head to the libretech-flash-tool git site at GitHub - libre-computer-project/libretech-flash-tool and read how it works. This tool doesnāt work like the Raspberry Pi imager (which is what I also used for my installations) as it only updates the bootloader on an already imaged SD card.
The process that I used, which worked, was using the Raspberry Pi imager to install Raspbian on my pair of Renegades, shutdown the pair after I set them up (while the LEDs were still acting wrong), placed the SD cards into the card reader of one of my Ubuntu machines where I downloaded the tool to and ran this utility on both SD cards. Then when I put the cards back into the Renegades the LEDs worked correctly and my original problem from November were both fixed.
Regarding your rebooting issue, I canāt really speak to that. I have only encountered issues with my Raspberry Piās where issuing āshutdown -r nowā resulted in them powering down instead. That was back in buster/Raspbian 10 and it was resolved in bullseye/Raspbian 11, but again that was just on some of my Piās, not my Renegades.
libretech-flash-tool is not for the purpose of fixing Armbian LEDs. It is to update the bootloader on existing images to the latest. There are some rare MicroSD card compatibility issues we are still investigating on ROC-RK3328-CC.
Do you know if itās possible to use the libretech-flash-tool on wsl for windows? Or do I need an Ubuntu environment outside of the libre board itself?
Not sure if WSL has access to raw devices and if it shows them under the normal /dev/{mmc,sd} naming. If WSL does not, then libretech-flash-tool will not work.
Iāve been having issues using the libretech-flash-tool for PXE booting my ROC-RK3328-CC. When I use the tool as the instructions state nothing happens on my board after plugging in the board with the MicroSD card in. Nothing on the screen, solid green and red light
You can change the green and red leds by echoing a value to their triggers.
You can see all the valid values when you run the command: # cat /sys/class/leds/librecomputer\:green/trigger
You can change the led by the following command: # echo none > /sys/class/leds/librecomputer\:green/trigger
and replace ānoneā with any valid value.
No doubt that Armbian is doing this in the boot process.
ROC-RK3328-CCās bootloader does not support HDMI output yet. But this will be supported as soon as upstream fixes some IOMMU bugs. You have to connect UART. By default, our bootloaders disable networking to both expedite boot time and reduce attack vector so PXE will not be supported out of the box. You have to compile your own bootloader with our libretech-builder-simple.
Hi. I encounter strange behavior using latest linux images (both ubuntu and raspbian). They do not boot at all if HDMI is connected. Even ubuntu base which is without GUI. After power on only red led is constantly on and nothing else happens even after few minutes (network led also not blinking, system not accessible via ssh). If I plug off HDMI cable then after few seconds green led starts blinking and system loads and is fully-functional. If I connect HDMI after that it works. It happens only on images with EFI and GRUB. Images based on extlinux (i.e. LibreElec or old ubuntu from firefly website) works perfectly and boot with HDMI connected, so I assume it is some kind of software problem.
Tried another monitor - Lenovo ThinkVision P27h-20, on first moments it show message āInput signal out of range. Please change to 2560x1440@60Hzā, but then booted successfully. By the way it has lower maximum resolution than previous two devices which are 4K.
ROC-RK3328-CC u-boot has new video code that is not very robust yet. Weāll have engineering consultants take a look. Also if you have an UART cable with the logs for these monitors, it would help expedite.
Thank you. Unfortunately currently I have no UART cable, but I ordered one, as soon as it will arrive Iāll try to get logs, if they will be still relevant.
Hi, Iām having a similar issue with HDMI, hereās what I see on the UART during the initial boot process (I can only see the GRUB menu on the UART, never on HDMI):
MIC: RK8050 (on=0x40, off=0x00)
DDR4, 800MHz
BW=32 Col=10 Bk=4 BG=2 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
Trying to boot from BOOTROM
Returning to boot ROMā¦
Trying to boot from MMC2
lz4 image
NOTICE: BL31: v2.9(release):v2.8-1351-g8929dffc0
NOTICE: BL31: Built : 02:49:07, Jul 31 2023
NOTICE: BL31:Rockchip release version: v1.2
DRAM: 4 GiB
PMIC: RK8050 (on=0x40, off=0x00)
Core: 244 devices, 31 uclasses, devicetree: separate
MMC: mmc@ff500000: 1, mmc@ff520000: 0
Loading Environment from FATā¦ Unable to read āuboot.envā from mmc0:1ā¦
Error (-2): cannot determine file size
unsupported rate 18446744073709551615
TMDS clock is zero!
inno_hdmi_phy phy@ff430000: PHY: Failed to power on phy@ff430000: -22.
failed to on hdmi phy (ret=-22)
unsupported rate 18446744073709551615
TMDS clock is zero!
inno_hdmi_phy phy@ff430000: PHY: Failed to power on phy@ff430000: -22.
failed to on hdmi phy (ret=-22)
unsupported rate 18446744073709551615
TMDS clock is zero!
inno_hdmi_phy phy@ff430000: PHY: Failed to power on phy@ff430000: -22.
failed to on hdmi phy (ret=-22)
U-Boot 2023.07+ (Jul 31 2023 - 02:49:10 -0400) Libre Computer ROC-RK3328-CC
Model: Libre Computer ROC-RK3328-CC
starting USBā¦
Bus usb@ff5c0000: USB EHCI 1.00
Bus usb@ff5d0000: USB OHCI 1.0
Bus usb@ff600000: generic_phy_get_bulk : no phys property
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@ff580000: USB DWC2
scanning bus usb@ff5c0000 for devicesā¦ 1 USB Device(s) found
scanning bus usb@ff5d0000 for devicesā¦ 2 USB Device(s) found
scanning bus usb@ff600000 for devicesā¦ 1 USB Device(s) found
scanning bus usb@ff580000 for devicesā¦ 2 USB Device(s) found
scanning usb for storage devicesā¦ 0 Storage Device(s) found
Hit any key to stop autoboot: 0
Scanning for bootflows in all bootdevs
Seq Method State Uclass Part Name Filename
Scanning global bootmeth āefi_mgrā:
Scanning bootdev āmmc@ff520000.bootdevā:
0 efi ready mmc 1 mmc@ff520000.bootdev.part efi/boot/bootaa64.efi
** Booting bootflow āmmc@ff520000.bootdev.part_1ā with efi
unsupported rate 18446744073709551615
TMDS clock is zero!
inno_hdmi_phy phy@ff430000: PHY: Failed to power on phy@ff430000: -22.
failed to on hdmi phy (ret=-22)
Booting /efi\boot\bootaa64.efi
GNU GRUB version 2.06
(Iām using a Belkin HDMI to VGA adapter )
Hereās my Raspbian xrandr output:
Screen 0: minimum 320 x 200, current 1280 x 720, maximum 4096 x 4096
HDMI-1 connected primary 1280x720+0+0 (normal left inverted right x axis y axis) 410mm x 230mm
1280x720 60.00* 50.00
1024x768 60.00
800x600 60.32
720x480 59.94
These boards only support HDMI based displays. Thereās no VGA signal unless you use an active adapter and even then the timings will not work since those DVI/VGA displays do not use HDMI standard timings.
)