usual user
-
Posts
533 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
2 hours ago, eselarm said:
SBC/embedded Linux does not have GRUB bootmanager by default, otherwise that would be the way to select older kernel.
But I'm grateful that it also works for me with pure U-boot:
SpoilerU-Boot SPL 2025.01 (Jan 16 2025 - 00:00:00 +0000) Trying to boot from SPI ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK NOTICE: BL31: v2.12.0(release): NOTICE: BL31: Built : 00:00:00, Nov 27 2024 NOTICE: BL31: Rockchip release version: v1.0 U-Boot 2025.01 (Jan 16 2025 - 00:00:00 +0000) Model: Hardkernel ODROID-M1 SoC: RK3568B2 DRAM: 8 GiB (effective 7.7 GiB) PMIC: RK809 (on=0x80, off=0x08) Core: 324 devices, 37 uclasses, devicetree: separate MMC: mmc@fe2b0000: 1, mmc@fe310000: 0 Loading Environment from nowhere... OK In: serial,usbkbd Out: serial,vidconsole Err: serial,vidconsole Model: Hardkernel ODROID-M1 SoC: RK3568B2 Net: eth0: ethernet@fe2a0000 starting USB... Bus usb@fd000000: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@fd800000: USB EHCI 1.00 Bus usb@fd840000: USB OHCI 1.0 Bus usb@fd880000: USB EHCI 1.00 Bus usb@fd8c0000: USB OHCI 1.0 scanning bus usb@fd000000 for devices... 1 USB Device(s) found scanning bus usb@fd800000 for devices... 2 USB Device(s) found scanning bus usb@fd840000 for devices... 1 USB Device(s) found scanning bus usb@fd880000 for devices... 5 USB Device(s) found scanning bus usb@fd8c0000 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found scanning bus for devices... SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp fbss pio slum part ccc apst Card did not respond to voltage select! : -110 Card did not respond to voltage select! : -110 Cannot persist EFI variables without system partition *** U-Boot Boot Menu *** Press UP/DOWN to move, ENTER to select, ESC to quit Standard Boot NVME USB Mass Storage SCSI USB Mass Storage eMMC USB Mass Storage microSD USB Mass Storage Power Off usb 0 mmc 1 nvme 0 Exit Hit any key to stop autoboot: 2 Hit any key to stop autoboot: 1 Scanning for bootflows in all bootdevs Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- Scanning global bootmeth 'efi_mgr': 0 efi_mgr ready (none) 0 <NULL> ** Booting bootflow '<NULL>' with efi_mgr Loading Boot0000 'usb 0' failed Loading Boot0001 'mmc 1' failed Loading Boot0002 'nvme 0' failed EFI boot manager: Cannot load any image Boot failed (err=-14) Scanning bootdev 'mmc@fe2b0000.bootdev': 1 extlinux ready mmc 1 mmc@fe2b0000.bootdev.part /extlinux/extlinux.conf ** Booting bootflow 'mmc@fe2b0000.bootdev.part_1' with extlinux Boot Options 1: ODROID-M1 40000015-01 2: ODROID-M1 50000006-01 3: NanoPC-T4 40000015-01 4: NanoPC-T4 40000015-01 verbose 5: NanoPC-T4 40000015-01 previous 6: Odroid-N2+ 40000015-01 7: Odroid-N2+ 40000015-01 verbose 8: Odroid-N2+ 40000015-01 previous 9: Odroid-N2+ SPI NOR 40000015-01 10: ODROID-M1 40000015-01 verbose 11: ODROID-M1 40000015-01 previous 12: ODROID-M1 40000015-01 previous verbose Enter choice: 1: ODROID-M1 40000015-01 Retrieving file: /usr/lib/modules/linux/vmlinuz append: loglevel=4 root=PARTUUID=40000015-01 coherent_pool=2M console=ttyS02,1500000 console=tty0 rootwait Retrieving file: /usr/lib/modules/linux/dtb/rockchip/rk3568-odroid-m1.dtb Uncompressing Kernel Image to 0 ## Flattened Device Tree blob at 12000000 Booting using the fdt blob at 0x12000000 Working FDT set to 12000000 Loading Device Tree to 00000000eae82000, end 00000000eae94200 ... OK Working FDT set to eae82000 Starting kernel ...
-
I'm currently at:
# uname -a Linux micro-015 6.13.0-0.rc1.20241204gitfeffde684ac2.17.fc42.aarch64 #1 SMP PREEMPT_DYNAMIC Sat Dec 7 11:18:10 CET 2024 aarch64 GNU/LinuxAnd with better wired up in DTB I get:
Spoiler# iperf3 -c odroid-m1 Connecting to host odroid-m1, port 5201 [ 5] local odroid-n2+ port 34366 connected to odroid-m1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 0 461 KBytes [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 0 510 KBytes [ 5] 2.00-3.00 sec 113 MBytes 945 Mbits/sec 0 560 KBytes [ 5] 3.00-4.00 sec 111 MBytes 934 Mbits/sec 0 585 KBytes [ 5] 4.00-5.00 sec 112 MBytes 943 Mbits/sec 0 684 KBytes [ 5] 5.00-6.00 sec 111 MBytes 928 Mbits/sec 0 718 KBytes [ 5] 6.00-7.00 sec 112 MBytes 944 Mbits/sec 0 718 KBytes [ 5] 7.00-8.00 sec 112 MBytes 935 Mbits/sec 0 792 KBytes [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 0 830 KBytes [ 5] 9.00-10.02 sec 113 MBytes 928 Mbits/sec 0 830 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.02 sec 1.09 GBytes 938 Mbits/sec 0 sender [ 5] 0.00-10.02 sec 1.09 GBytes 937 Mbits/sec receiver iperf Done. # iperf3 -R -c odroid-m1 Connecting to host odroid-m1, port 5201 Reverse mode, remote host odroid-m1 is sending [ 5] local odroid-n2+ port 36326 connected to odroid-m1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 87.8 MBytes 735 Mbits/sec [ 5] 1.00-2.00 sec 73.6 MBytes 618 Mbits/sec [ 5] 2.00-3.00 sec 94.2 MBytes 791 Mbits/sec [ 5] 3.00-4.00 sec 90.2 MBytes 757 Mbits/sec [ 5] 4.00-5.00 sec 88.5 MBytes 742 Mbits/sec [ 5] 5.00-6.00 sec 86.0 MBytes 721 Mbits/sec [ 5] 6.00-7.00 sec 87.4 MBytes 733 Mbits/sec [ 5] 7.00-8.00 sec 83.2 MBytes 698 Mbits/sec [ 5] 8.00-9.00 sec 86.0 MBytes 721 Mbits/sec [ 5] 9.00-10.00 sec 79.4 MBytes 666 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 858 MBytes 720 Mbits/sec 196 sender [ 5] 0.00-10.00 sec 856 MBytes 718 Mbits/sec receiver iperf Done. -
Works for me as for @rmrf.
iperf3 -c ... [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender [ 5] 0.00-10.01 sec 1.09 GBytes 938 Mbits/sec receiver iperf3 -R -c ... [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 412 MBytes 345 Mbits/sec 485 sender [ 5] 0.00-10.00 sec 410 MBytes 344 Mbits/sec receiver -
On 10/1/2024 at 9:06 PM, Mickynuts said:
I don't need help anymore. As said. I used the uboot present in an earlier version.
Ok, then no further action needs to be taken and your solution can be used by others in the future.
I also don't need any other firmware because my current one works according to my needs.
And for an update, I know how to build and debug it if necessary.In the meantime, I've moved to 2025.01 with HDMI support enabled, so I no longer need the serial console to interact with the firmware.
And boot menus easily allow the free choice of which option should currently be booted. -
6 hours ago, Mickynuts said:
I tried to make a bug report form. But you have to provide an armbianmonitor -u output or something like that. And that doesn't match the fact. The card doesn't even boot.
To get help, you have to provide proper logs. In case of boot problems, these are serial console logs. https://debug.armbian.de
-
On 9/13/2024 at 8:16 PM, Ryzer said:
Please find attached the dts sources
Out of curiosity, I played around a bit with the sources offered.
The overlay compiled from the spi-ili9341-tft.dts source cannot be applied statically to the base DTB. It seems to have something to do with the externally used labels. Unfortunately, my DTC package is currently in FTBFS condition and I can't investigate the cause further at the moment.
I have therefore rewritten the overlay in absolute path notation. I used the given properties for this. I can't make a statement about their correctness, because I don't have a complete circuit diagram or any necessary data sheets at hand.
I'm not particularly familiar with the Allwinner devicetree binding documentation, but as far as I can tell, the properties, when applied to the base DTB statically, are compliant.
If you want, you can run the attached DTB with your device. All components are already statically applied, so you should disable any other dynamically applied overlays.
I would be interested in the "/sys/kernel/debug/gpio" content. -
-
9 hours ago, UmutU123 said:
Same output as in the first post.
This says that the necessary short circuit was not present when the MaskRom code scanned for boot devices.
The short circuit must be ensured before the power supply is switched on, and must be maintained until a few seconds later. The procedure is a three-handed job. One hand fixes the PCB, one hand holds the tweezers, and one hand switches on the power supply.
This can only be reliably ensured with a shelf holder who uses Pogo pinns.IMHO a bad board design for a tinker device. A push button or at least holes for a plug contact to connect a proper switch if necessary would be the better solution. Be grateful to your board designer.
-
19 hours ago, UmutU123 said:
So i got a dc charger but nothing I do gets me into the Maskrom mode.
Since the "upgrade button" is only software readable, and the firmware (U-Boot) that does it is corrupt, only this method remains.
19 hours ago, UmutU123 said:I am not even sure on how to flash the suitable firmware at this point.
In MaskRom_mode I would first delete the corrupt firmware in the eMMC, so that the firmware loading falls back to the microSD card. This allows different firmware variants to be tested without having to use the clunky method to get into the MaskRom_mode.
Then I would prepare a microSD card with supposedly suitable firmware and boot the device with it. The function can be verified looking at the serial console output.
Once a suitable firmware has been identified, I would add an OS image to the microSD card to evaluate the full functionality. It may be possible to speed up the procedure if a complete image with suitable integrated firmware is already available.
Finally, if necessary, the firmware can be placed in the eMMC again. -
18 hours ago, robertoj said:
Why is the row gpio-234 (RESET) not showing up in kernel 5.18.88, but it shows up in kernel 6.6.16?, and then it disappears again with your next experiment with updated libgpiod?
Since I don't even know which system component the supposed GPIO line is connected to, I could only speculate wildly. The appearance is certainly due to the wiring in the DT, but this is also a speculation to which I do not want to comment further, but leave it to qualified people. Alternatively, you could look in the exact DT sources from which the DTBs used at runtime were assembled, but I don't have access to that.
You could also add the line to the output with:gpioset --consumer=reset -c0 234=onbut it certainly won't give the same functionality as in the original case, as it's a completely different use case.
-
4 hours ago, UmutU123 said:
I guess nobody here knows whats wrong?
Your device stalls in early firmware not even the payload (U-Boot) is reached. Which OS is used is anything but important at this point.
Make sure that a suitable firmware is used before you worry about the userspace.
Devices with Rockchip SOCs are unbrickable, you can recover at any time by restoring a suitable firmware. -
On 9/6/2024 at 10:13 AM, robertoj said:
I can see my SBC's DTS with armbian-config > System > DTC ... is this what you meant?
Since there is no public link to the result, I suspect it.
On 9/6/2024 at 10:13 AM, robertoj said:It is almost identical to
Since a single false character in a DTS(O) can already lead to a malfunction in its consuming code, this is completely unsuitable for debugging.
If the DTB's build framework is added as a source of error, be my guest, but please don't expect any help from me in this case.
It's the same as asking an application developer to identify a bug in the compilation toolchain by disassembling their binary application code without having access to the exact sources from which the particular binay was built. -
7 hours ago, robertoj said:
I have a feeling that there's some difference between ili9341.ko (adafruit) and fb_ili9341.ko, in the way they handle GPIOs and SPI pins.
IMHO it is much more likely that the DT description is incorrect, but with the Armbian DT workflow there is not the slightest possibility to verify it automatically with the binding documentation.
But since not even the original DT sources are readily available, you can't even validate them manually.
And once sources are available, they are usually written in disassembler syntax, which does not make them easier to read.
In addition, there is the fact that many attempts are made to merge snippets of DTS from different devices by "copy & paste" in the hope of magically getting a working device. This is just as doomed to failure as the attempt to use arbitrary schematic snippets of various devices to describe a certain PCB for a specific device.
In the DT world it is even more challenging, because the DT layout is even use case dependent and runtime changeable. -
Ok, you have confirmed that the GPIO line can be properly acquired by a suitable process and the GPIO subsystem is working as expected.
The SPI subsystem does not seem to do this as desired for the CS line.
Whether this is due to a bug patched out of tree in the 5.15.88 kernel, or just a configuration error in the DT, I can't say, since you haven't published any DT sources on how your SPI controller is wired.
I'm interested in the original sources from which the DTB was created, and not any from some disassembled DTB, as this has lost valuable information that was striped out during the assembly of the DTB.
But I also know that it is very difficult to acquire them with an Armbian build system since they most probably only exist as build artifacts which get composed from various patches. -
5 hours ago, Ryzer said:
Another issue is that neither is 100% accurate as some listed gpio lines do not actually exist
"/sys/kernel/debug/gpio" represents what the kernel has instantiated. Its accuracy depends on the exact description (DT), as the layout cannot be probed.
But many people think they can copy DT fragments of similar devices together to get an exact description of a particular device without verification. But it's just like a device schematic, it will never accurately replicate the layout design of another device. DT is just one step further, as it can change the layout itself at runtime.5 hours ago, Ryzer said:That said if the mapping was incorrect then surely the dc pin and backlight pins woud not be correct either.
The test was intended to verify that the GPIO subsystem is correctly configured and that the GPIO line can be acquired from a native GPIO process.
This is because the line cannot be operated as a native CS line by the SPI IP but only emulated with the cooperation of the GPIO Subsystem.5 hours ago, Ryzer said:Are you sure this is right as it returns an error and gpioset -h does not list a -c option
Mine does:
Spoiler# gpioset --help Usage: gpioset [OPTIONS] <line=value>... Set values of GPIO lines. Lines are specified by name, or optionally by offset if the chip option is provided. Values may be '1' or '0', or equivalently 'active'/'inactive' or 'on'/'off'. The line output state is maintained until the process exits, but after that is not guaranteed. Options: --banner display a banner on successful startup -b, --bias <bias> specify the line bias Possible values: 'pull-down', 'pull-up', 'disabled'. (default is to leave bias unchanged) --by-names treat lines as names even if they would parse as an offset -c, --chip <chip> restrict scope to a particular chip -C, --consumer <name> consumer name applied to requested lines (default is 'gpioset') -d, --drive <drive> specify the line drive mode Possible values: 'push-pull', 'open-drain', 'open-source'. (default is 'push-pull') -h, --help display this help and exit -l, --active-low treat the line as active low -p, --hold-period <period> the minimum time period to hold lines at the requested values -s, --strict abort if requested line names are not unique -t, --toggle <period>[,period]... toggle the line(s) after the specified period(s) If the last period is non-zero then the sequence repeats. --unquoted don't quote line names -v, --version output version information and exit -z, --daemonize set values then detach from the controlling terminal # gpioset --version gpioset (libgpiod) v2.1.3 Copyright (C) 2017-2023 Bartosz Golaszewski License: GPL-2.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
-
3 hours ago, Ryzer said:
I did a bit of digging into previous commits to armbian build and found an interesting patch for the 5.15 kernel series:
Of course, I don't know which patches Armbian has applied at times, but what looks suspicious is the fact that the gpio line numbers used in the "/sys/kernel/debug/gpio" logs for the gpiochip1 differ. This shouldn't be caused by the DT, and if it is, it should be the same as using the 5.15.88 variant again.
To test the basic function of the GPIO subsystem in 6.6.16, post the state of "/sys/kernel/debug/gpio" whilegpioset -c0 34=onis running at the same time with root permissions.
-
11 hours ago, Ryzer said:
which location do I source the old dtb from as there is a pcduino2.dtb at /boot/dtb/ as well as /boot/dtb-5.15.88.
/boot/dtb/ is probably a symlink to the real /boot/dtb-5.15.88 dirctory with the version number in the name to hint the source version the DTBs are build from.
I usually have plenty of kernels installed at the same time, so that it only takes to adjust the symlink to refer to a different DTB set. But this doesn't work so easily in Armbian with its single kernel layout strategy, because it results in name and directory conflicts there.
But in your case, it should be sufficient to copy the /boot/dtb-5.15.88 directory alongside to the /boot/dtb-6.6.16 directory and adjust the symlink accordingly.
Oh, just to be clear, they're both mainline kernel builds and there's no legacy kernel fork involved, because in this case it won't work, because most likely incompatible out of tree hacks are involved.11 hours ago, Ryzer said:As another test I have tried using the spi-gpio module in place of spi-sun4i but have been unable to get that to work at all.
You can't mix binaries of kernel components of different versions, not even different builds of the same version, because you can't make sure that the ABI hasn't changed. For DTBs intermixing is possible because they describe hardware and are agnostic of the consumer binary code. The mainline kernel with its "no regression" policy ensures that earlier releases remain functional.
For a given userspace, you can use any kernel as long as it's build is configured with the same components, because it exposes a stable userspace-kernel API. -
To rule out that with the error prone Armbian DT workflow something got messed up, run the 6.6.16 kernel with the DTB and its related DTBOs created with the 5.15.88 build.
-
5 hours ago, Ryzer said:
A slight draw back with this approach is that it does not currently acknowledge when gpio are configured for spi.
Look at "/sys/kernel/debug/gpio", it will tell you wich gpio is in use by which driver.
-
-
12 minutes ago, hi-ko said:
the bootloader doesn't find a boot device
Bootstd is scanning for a valid bootflow at the partition where the bootflag is set. If none is set, the first partition is used as a fall-back default.
-
55 minutes ago, hi-ko said:
bootloader still boots into sdcard:
Mainline U-Boot scans at various locations for valid bootflows. Usually eMMC and microSD are scanned befor NVMe, so as long as an valid bootflow is found there, that one is used.
-
17 minutes ago, hi-ko said:
- used armbian-install: to boot from selected nve partition (btrfs) and install bootloader on sdcard
-
bootloader found the partition but faild to mount brfs partition:
[/sbin/fsck.ext4 (1) -- /dev/nvme0n1p2] fsck.ext4 -a -C0 /dev/nvme0n1p2
Looks like some partition format mixup, btrfs vs. ext4.
-
34 minutes ago, hi-ko said:
Here the console log from the failed boot
You are still using legacy firmware, the first step should be to switch to mainline.
Odroid M1: USB disk not detected after kernel upgrade 6.6.63->6.12.9
in Rockchip
Posted
For me USB works as expected:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=usb-storage, 480M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 002: Dev 003, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 002: Dev 003, If 2, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 003: Dev 004, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M |__ Port 004: Dev 005, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=ohci-platform/1p, 12MI don't have any usbstoragequirks in place because my storage devices have controllers with properly working UAS support.
I'm currently at 6.13-rc1 and will stay there at least for another two weeks.