Meestor_X
Members-
Posts
91 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by Meestor_X
-
Thank you for your reply. Do you know what the command is for installing the bootloader? I want to automate the process and armbian-install doesn't seem to have a way to be run via command line. Reading and following the operation of armbian-install is next to impossible.
-
Understood. I'm still on 24.x.x so I don't know if the later ones are better. I tried for a while without, but honestly, you gotta get yourself a TTL -> USB that works so you can follow the log. Once you do that, you'll see the errors clear as day as to why the overlays aren't being loaded. Not sure what country you're in, but in NA they're quite inexpensive. This is the one I got: https://www.amazon.com/Serial-Adapter-Signal-Prolific-Windows/dp/B08BLKBK1K
-
It's been a while, but I believe it was the prefix issue. Perhaps it's been fixed now? https://github.com/armbian/configng/issues/360#issuecomment-2573855215 A big part of getting to the bottom of overlay issues is to use a TTL->USB adapter to watch the boot process.
-
So, looking to create a CLI version of armbian-install. Only has to work with the rockpi-s and from the SD card to the eMMC. Looking at this script: If it works to clone the SD to eMMC (with some changes?) then I need to tell armbian to boot from the eMMC when the SD card isn't inserted, same way that armbian-install does. Do I simply change the UUID line in /boot/armbianEnv.txt to the UUID of the eMMC, or do I need to edit /etc/fstab or ??
-
Rockpi-S no longer boots with latest Armbian > 24.11.1
Meestor_X replied to Meestor_X's topic in Radxa Rock Pi S
The fix is in the first thread above. -
Apt Upgrade causes Rock Pi S not to boot [Armbian 24.11.1]
Meestor_X replied to Truenox's topic in Radxa Rock Pi S
Ok, I'll try again, perhaps I did something incorrectly. My fault. After the install it decided to change IP addresses. Rookie move. Now both the eMMC and SD card seem to be booting. Even upgraded to trixie and all still seems to be ok. TY for your help! Is this fixable so that these extra steps are not needed? -
Apt Upgrade causes Rock Pi S not to boot [Armbian 24.11.1]
Meestor_X replied to Truenox's topic in Radxa Rock Pi S
@ValdikSS Didn't work. Do I also need to apt update && apt upgrade before or after running the dpkg command? Do I need to do something regarding my eMMC? -
Apt Upgrade causes Rock Pi S not to boot [Armbian 24.11.1]
Meestor_X replied to Truenox's topic in Radxa Rock Pi S
Is there a TL;DR method now for updating the Rockpi-S past 24.11.1 so it will boot? Do I run the dpkg command that @ValdikSS suggested and then armbian-install/update boot loader? Tried that. Didn't work. -
Rockpi-S no longer boots with latest Armbian > 24.11.1
Meestor_X replied to Meestor_X's topic in Radxa Rock Pi S
Seems there were others with a similar problem. I can't tell if there's a clear solution contained within these threads? -
Been using 24.11.1 Bookworm for a while, but yesterday did an apt update && apt upgrade, only to find that the resulting image would no longer boot. No "activity" light at all on the front on reboot. Downloaded 25.5.0 Trixie "just to see", but it doesn't boot either. What happened after 24.11.4? Is there something different I should be doing if I want to run a later version of Armbian?
-
NB - evtest does not come with Armbian Bookworm. A quick "apt install evtest" and we're away! root@radxa-e20c:~# evtest /dev/input/event0 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "gpio-keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 185 (KEY_F15) Key repeat handling: Repeat type 20 (EV_REP) Repeat code 0 (REP_DELAY) Value 250 Repeat code 1 (REP_PERIOD) Value 33 Properties: Testing ... (interrupt to exit) Event: time 1739040710.916095, type 1 (EV_KEY), code 185 (KEY_F15), value 1 Event: time 1739040710.916095, -------------- SYN_REPORT ------------ Event: time 1739040711.050330, type 1 (EV_KEY), code 185 (KEY_F15), value 0 Event: time 1739040711.050330, -------------- SYN_REPORT ------------ Do you know where I can find information on how to change settings for this button?
-
Thank you so much, @Torte! I'll have to bookmark this as my next rabbithole. 🙂
-
Oh! I thought those commands were needed for your custom dts. What do you know! All I had to do was: echo enp1s0 > device_name echo 1 > rx And it "just works"! Also, this "just works": root@radxa-e20c:/dev/input# cat event0 To see when the user button is pressed. Although, I'm not sure what data is being produced from it! root@radxa-e20c:/dev/input# cat event0 | hexdump -C 00000000 8b 8a a7 67 00 00 00 00 5c 14 0f 00 00 00 00 00 |...g....\.......| 00000010 01 00 b9 00 01 00 00 00 8b 8a a7 67 00 00 00 00 |...........g....| 00000020 5c 14 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 |\...............| 00000030 8c 8a a7 67 00 00 00 00 3e 65 01 00 00 00 00 00 |...g....>e......| 00000040 01 00 b9 00 00 00 00 00 8c 8a a7 67 00 00 00 00 |...........g....| 00000050 3e 65 01 00 00 00 00 00 00 00 00 00 00 00 00 00 |>e..............| I had no idea it was that easy. Is this a Linux thing? Armbian thing? Radxa thing? Where can I read up on this kind of hardware control?
-
TY for your reply. They definitely can be controlled by echoing values to the `/sys/class/leds/` and even though the "trigger" is set to "netdev" and tx and rx files appear, I'm not seeing any activity on those LEDs with network activity. I can manually make the LEDs blink by doing something like echo heartbeat > /sys/class/leds/lan-led/trigger cat /sys/class/leds/lan-led/trigger will show the available triggers, and a [] around the currently selected one. cat trigger none usb-gadget usb-host rc-feedback bluetooth-power rfkill-any rfkill-none kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock mmc0 timer oneshot disk-activity disk-read disk-write ide-disk mtd nand-disk heartbeat backlight gpio cpu cpu0 cpu1 cpu2 cpu3 activity default-on transient flash torch panic [netdev] mmc1 It looks very configurable, just doesn't seem to be "automatically" working to show network activity.
-
How did you figure this out? I can't really understand anything that's in the dts file or what you've got going in that script... as per the info here: https://github.com/armbian/build/pull/7157 I should be able to get the LEDs working for the ethernet connection on the E20C. Not sure if I need an overlay, or a script like yours or both?
-
TY, I couldn't figure out where to post as the e20c doesn't have a tag. Did you just add it? NM, I was looking for e20c, didn't realize the tag was Radxa-E20C.
-
Seems like a great little box, but Radxa doesn't have much info about the hardware side of it. Simple stuff like accessing the LEDs and buttons when running Armbian. Posted on the Radxa website but no replies, so just curious if anyone has dug into it at all?
-
That tool is great for backing up, but not doing the UUID/boot change I need. I have to see if I can find some documentation on how to copy and change the boot info as staring at the source code of armbian-install (where this is solved) is making my eyes hurt. 😉
-
I see. The only reason I have to boot from µSD or USB is to update the eMMC, it's not a "regular thing", so if it's slow I don't mind. As I said earlier, with just the eMMC and µSD, it works exactly the way I want, I was simply hoping to add USB to the mix as an alternative to µSD since that would be easier for end users. If it can't work exactly the same as the way it works currently, then there's no point. (i.e. it doesn't matter if the eMMC is unbootable or even unformatted, the µSD will always boot first ATM). If the USB boot relies on the eMMC or µSD then it's not going to be useful in my case. TY for the detailed explanation.
-
Very cool. I didn't realize it could be that easy. Great (but potentially slow) for making backups. Here's the "tricky parts" that I'm still trying to figure out... - cloning a larger drive that only has part of it used to a smaller drive that has room for the used part. - changing the UUID/boot info so that you can clone a µSD to the eMMC and still have it boot from either one.
