usual user
-
Posts
423 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
20 hours ago, johmue said:
Is there an "official" way to get back my /dev/AML1 UART device which is sustainable?
meson-g12b-odroid-n2-plus.dtb is a base DTB with a static applied overlay.
In your mentioned thread at post 23 is a reference to a parallel thread where the overlay source is provided.
So prepare a PR so that the overlay can be included in Armbian.
You'll probably reap tons of grateful users who have been waiting for someone to make the effort. -
4 hours ago, mongoose said:
I did (edit boot.cmd), but to no success.
Some settings that were set at build time can't be modified at runtime.
This requires a new firmware build, e.g. to set the boot delay to 0, the build configuration has to be set to "CONFIG_BOOTDELAY=0".
4 hours ago, mongoose said:it uses the defaults, though this doesn't happen with u-boot on debian.
This is due to the build configuration. The build configuration determines the properties of a binary created from a certain source. These can be detail settings, or even decisive for which hardware it is usable.
Finally, U-Boot can be built for all devices from the same source of a given release version.
E.g. "make libretech-cc_defconfig" prepares a default configuration for LePotato.
You can use "make menuconfig" to fine tune it afterwards.4 hours ago, mongoose said:how I could integrate that into an existing armbian image
I don't know the details of Armbian's build framework, but I'm sure you can inject a patch that implements your desired change.
-
2 hours ago, ag123 said:
u-boot does the bulk of the 'black magic' dealing with memory initialization and sizing
This is not correct. Due to its size, U-Boot must be run from RAM. The RAM must therefore already be initialized before U-Boot can be loaded at all. This is usually done by Trusted Firmware-A (TF-A). U-Boot is only the payload (in TF-A terminology: BL33).
You might want to read TF-A's documentation to understand the boot flow, I think here is a good place to start. You're lucky if TF-A is open source for your SoC, but often only a binary BLOOB for BL2 and BL31 is provided by the SoC manufacturers. -
1 hour ago, mongoose said:
"save" doesn't exist.
Your firmware is build without persistent Environment.
On 4/12/2024 at 12:51 AM, mongoose said:16 Loading Environment from nowhere...
Only the compiled-in Environment is used, which can only be modified before build.
-
5 hours ago, bananapinas said:
And now it boots, monitor shows the startup and login does work
I'm glad you were able to solve your issue.
However, I will still stick with my firmware in SPI flash, because it gives me slightly more control over the boot process:SpoilerG12B:BL:6e7c85:2a3b91;FEAT:E0F83180:402000;POC:B;RCY:0;SPINOR:0;0. bl2_stage_init 0x01 bl2_stage_init 0x81 hw id: 0x0000 - pwm id 0x01 bl2_stage_init 0xc1 bl2_stage_init 0x02 L0:00000000 L1:00000703 L2:0000c067 L3:14000020 B2:00402000 B1:e0f83180 TE: 58167 BL2 Built : 06:17:13, Jun 28 2019. g12b gf0505d7-dirty - qi.duan@droid13 Board ID = 5 Set A53 clk to 24M Set A73 clk to 24M Set clk81 to 24M A53 clk: 1200 MHz A73 clk: 1200 MHz CLK81: 166.6M smccc: 00012b13 DDR driver_vesion: LPDDR4_PHY_V_0_1_14 build time: Jun 28 2019 06:17:09 board id: 5 Load FIP HDR from SPI, src: 0x00010000, des: 0xfffd0000, size: 0x00004000, part: 0 fw parse done Load ddrfw from SPI, src: 0x00060000, des: 0xfffd0000, size: 0x0000c000, part: 0 Load ddrfw from SPI, src: 0x00038000, des: 0xfffd0000, size: 0x00004000, part: 0 PIEI prepare done fastboot data load fastboot data verify verify result: 255 Cfg max: 2, cur: 1. Board id: 255. Force loop cfg DDR4 probe ddr clk to 1320MHz Load ddrfw from SPI, src: 0x00014000, des: 0xfffd0000, size: 0x0000c000, part: 0 Check phy result INFO : End of initialization INFO : End of read enable training INFO : End of fine write leveling INFO : End of read dq deskew training INFO : End of MPR read delay center optimization INFO : End of Write leveling coarse delay INFO : End of write delay center optimization INFO : End of read delay center optimization INFO : End of max read latency training INFO : Training has run successfully! 1D training succeed Load ddrfw from SPI, src: 0x00020000, des: 0xfffd0000, size: 0x0000c000, part: 0 Check phy result INFO : End of initialization INFO : End of 2D read delay Voltage center optimization INFO : End of 2D write delay Voltage center optimization INFO : Training has run successfully! R0_RxClkDly_Margin==82 ps 7 R0_TxDqDly_Margi==106 ps 9 R1_RxClkDly_Margin==0 ps 0 R1_TxDqDly_Margi==0 ps 0 dwc_ddrphy_apb_wr((0<<20)|(2<<16)|(0<<12)|(0xb0):0001. 2D training succeed auto size-- 65535DDR cs0 size: 2048MB DDR cs1 size: 2048MB DMC_DDR_CTRL: 00600024DDR size: 3928MB cs0 DataBus test pass cs1 DataBus test pass cs0 AddrBus test pass cs1 AddrBus test pass pre test bdlr_100_average==420 bdlr_100_min==420 bdlr_100_max==420 bdlr_100_cur==420 aft test bdlr_100_average==420 bdlr_100_min==420 bdlr_100_max==420 bdlr_100_cur==420 non-sec scramble use zero key ddr scramble enabled 100bdlr_step_size ps== 411 result report boot times 1Enable ddr reg access Load FIP HDR from SPI, src: 0x00010000, des: 0x01700000, size: 0x00004000, part: 0 Load BL3X from SPI, src: 0x0006c000, des: 0x0175c000, size: 0x000aa600, part: 0 0.0;M3 CHK:0;cm4_sp_mode 0 E30HDR MVN_1=0x00000000 MVN_2=0x00000000 [Image: g12b_v1.1.3375-8f9c8a7 2019-01-24 10:44:46 guotai.shen@droid11-sz] OPS=0x40 ring efuse init chipver efuse init 29 0c 40 00 01 13 20 00 00 0c 31 32 32 50 30 50. [3.748170 Inits done] secure task start! high task start! low task start! run into bl31 NOTICE: BL31: v1.3(release):ab8811b NOTICE: BL31: Built : 15:03:31, Feb 12 2019 NOTICE: BL31: G12A normal boot! NOTICE: BL31: BL33 decompress pass ERROR: Error initializing runtime service opteed_fast <debug_uart> U-Boot 2024.04-rc2-g8190a7d (Mar 01 2024 - 00:00:00 +0000) odroid-n2/n2-plus Model: Hardkernel ODROID-N2 SoC: Amlogic Meson G12B (S922X) Revision 29:c (40:2) DRAM: 1 GiB (effective 3.8 GiB) Core: 404 devices, 32 uclasses, devicetree: separate MMC: sd@ffe05000: 0, mmc@ffe07000: 1 Loading Environment from nowhere... OK In: usbkbd,serial Out: vidconsole,serial Err: vidconsole,serial Board variant: n2-plus Net: eth0: ethernet@ff3f0000 starting USB... Bus usb@ff500000: Register 3000140 NbrPorts 3 Starting the controller USB XHCI 1.10 scanning bus usb@ff500000 for devices... 5 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Card did not respond to voltage select! : -110 No EFI system partition No EFI system partition Failed to persist EFI variables No EFI system partition Failed to persist EFI variables No EFI system partition Failed to persist EFI variables *** U-Boot Boot Menu *** Press UP/DOWN to move, ENTER to select, ESC to quit Standard Boot eMMC USB Mass Storage microSD USB Mass Storage 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 'mmc 0' failed EFI boot manager: Cannot load any image Boot failed (err=-14) Scanning bootdev 'sd@ffe05000.bootdev': 1 extlinux ready mmc 2 sd@ffe05000.bootdev.part_ /extlinux/extlinux.conf ** Booting bootflow 'sd@ffe05000.bootdev.part_2' with extlinux Fedora-KDE-aarch64-Rawhide-20240301 Boot Options 1:<---->ODROID-M1 2:<---->ODROID-M1 previous 3:<---->ODROID-M1 verbose 4:<---->Odroid-N2+ 5:<---->Odroid-N2+ previous 6:<---->Odroid-N2+ verbose 7:<---->Fedora-KDE-aarch64-38 8:<---->Fedora-KDE-aarch64-38-20230401 9:<---->NanoPC-T4 10:<--->NanoPC-T4 previous 11:<--->NanoPC-T4 verbose Enter choice: 4 4:<---->Odroid-N2+ Retrieving file: /usr/lib/modules/linux-previous/vmlinuz append: loglevel=4 root=PARTUUID=679e3844-03 console=ttyAML0,115200 console=tty1 rootwait rootfstype=btrfs ro rootflags=subvol=root Retrieving file: /usr/lib/modules/linux-previous/dtb/amlogic/meson-g12b-odroid-n2-plus.dtb Uncompressing Kernel Image to 0 Moving Image from 0x8080000 to 0x8200000, end=c1c0000 ## Flattened Device Tree blob at 08008000 Booting using the fdt blob at 0x8008000 Working FDT set to 8008000 Loading Device Tree to 000000003ffef000, end 000000003ffff2d8 ... OK Working FDT set to 3ffef000 Starting kernel ...
-
2 hours ago, bananapinas said:
U-Boot 2015.01 (Aug 08 2021 - 16:09:39)
Since you're still using a nine-year-old firmware that was built almost three years ago, I'm assuming that you haven't transferred the firmware that came with the linux-u-boot-odroidn2-current package to the firmware area. As far as I know, this is a process to be initiated manually in Armbian.
The firmware used obviously can't handle the bootflow of the more advanced OS or maybe some old bootflow artifacts weren't cleaned up properly. -
12 hours ago, Jojo said:
What could be the next steps?
Since you have access to all the necessary components, grab an ODROID-M1 OS image of your choice, copy the components into it, and test.
If you install the OS image in the eMMC, be prepared to reinstall the original firmware. The ODROID-M1S does not have SPI flash and expects the firmware in the first instance in the eMMC. This means that the original firmware will be overwritten.
Alternatively, you can test with a microSD card, but you have to shortcircuit the MASK ROM pads each time at boot so that the firmware is loaded from there.
If you only transfer the firmware into the eMMC, you can also start the OS image of micrSD without MASK ROM intervention, this simplifies testing, because in the OS image only the DTB has to be added and the OS image can be transferred to a microSD card more easily.17 minutes ago, Jojo said:I think I will try to make a build for the OrangePi 3b
Nothing has to be build in the first step by yourself, try testing the already availabe components.
-
Just to demonstrate what such a concern would mean for the distribution of my choice:
The only thing in OS space that is really device-specific is the devicetree, which describes how the device is wired. For the linux kernel, it is only relevant that the corresponding drivers for the components listed in the devicetree are also built using the necessary options. Since the drivers for the rk3568 SoC are the same as for the rk3566 SoC (they are wired differently only through the devicetree), there is no need for any special action in this case.
So all I'm missing is a mainline binding compliant devicetree, and I'm done.
Now all that's missing is a firmware that can start the OS of choice. And this contains device-specific code that can't be copied from another device, and must be built specifically for this device.
Fortunately, everything necessary has already been posted on the U-Boot mailing list. The devicetree used still has shortcomings, but it is a start.
In order to verify the handling of different binary bloobs with my build system, I already build the firmware regularly. It's also included in my provided firmware uploads, but I haven't communicated it as I don't own an ODROID-M1S and therefore can't verify its functionality.
For me, the conlusion means:
- Install the firmwaredd bs=512 seek=64 conv=notrunc,fsync if=odroid-m1s-rk3566/u-boot-rockchip.bin of=/dev/${entire-device-to-be-used}- run the ODROID-M1S in UMS mode and tranfer my current image to a NVME
- Since there is no proper mainline devietree, I would use the one that falls off during the firmware build and copy it incp /somewhere/rk3566-odroid-m1s.dtb /usr/lib/modules/linux/dtb/rockchip/rk3566-odroid-m1s.dtbAnd I'm ready to rumble.
The same should be able to work with an Armbian ODROID-M1 image. -
If there is already firmware with U-Boot as a payload on the device, the UMS functionality is a possibility. In the meantime, all my firmware builds have easy access to this functionality, as long as the support requirements are met. I don't know the support status of the Allwinner H616 SoC, hence YMMV.
-
10 hours ago, Jojo said:
your workflow regarding creating an own OS image is definitely beyond my knowledge
Normally, I would have said: "With suitable firmware in SPI flash, a raw image on any storage device is sufficient". This is still true for FC38, but further development of the kernel has revealed a flaw in the support of the S922X SoC. This results in a kernel exception for operation with an ODROID N2/N2+. Of course, this means that it no longer works out-of-the-box for newer releases.
As far as I know, no one has yet provided a mainline acceptable solution, it is just a revert of the advancement. Of course, this is not a long-term solution and is not accepted in mainline.10 hours ago, Jojo said:I can not get clinfo to detect my GPU
Rusticl doesn't seem to be able to use the Mali GPU in your setup. I can't tell if the kernel doesn't make it available via the panfrost driver or if Mesa 22.3.6 doesn't even provide rusticl panfrost driver support yet.
For a quick test, I started FC38 again:
As you can see from the clinfo-02.log, Mesa 23.1.9 still lacks basic extensions for rusticl. So it's quite possible that mesa 22.3.6 isn't enough.
But it may also be that it is messed up by your additionally installed CL platforms. -
22 hours ago, Jojo said:
My system is Armbian bookworm on an ODROID N2+ (Mali-G52).
I'm currently running this:
since Debian based systems are for my taste way to stable - outdated.
22 hours ago, Jojo said:Do you have any idea about a workflow how to get OpenCL running properly?
At times, I grab a nightly image, rearrange it to my liking, drop in my personal configuration preferences and use it till the cycle restarts.
22 hours ago, Jojo said:What driver (ARM, HK...), what to copy, what to compile, where to copy...
Nothing special, the key is current mainline releases.
Panfrost has been very mature for a long time, so the kernel version may be a bit older.
But of course, the latest version comes with the latest fixes and improvements.
The same goes for Mesa, and that's where the current release is important, as the development of Rusticl is still quite vivid.To use a version that is more than a year old, and thus to forego any improvements that have taken place during this time, is quite courageous.
But nevertheless, I would be interested in the output result of this command:RUSTICL_ENABLE=panfrost clinfo -
1 hour ago, hjheins said:
do you mean the spi boot/petitboot on teh Odroid N2?
The device firmware is the only truly device-specific code that initializes the SoC and loads the OS. In the x86 architecture world, this is called BIOS. It often uses U-Boot as payload, but there are other ones as well. With its proprietary implementation, Petitboot can't even use the most common standard bootflows and will be therefore usually replaced by mainline firmware versions.
1 hour ago, hjheins said:How can I find more info on your firmware build please?
-
7 hours ago, Jojo said:
I tried a lot of thing like the default panfrost driver, self-compiled ARM driver, ARM userspace driver...
I haven't tried any of that. I only used the distribution of my choice. It is in no way designed specifically for a specific device. The only requirement to use it is a firmware that is capable of booting the system. But since there's mainline firmware support for many devices, and I've learned to build it from the sources according to my needs, the same OS image works the same way for me for every device.
To create the previously attached log file, I only had to use an environment variable to reveal the backend to be used with rusticl and was ready to go. The user space doesn't use anything device-specific, but is only built from current mainline releases. That's what the OS developers did for me, and they don't even know what devices I'm using it on. -
8 hours ago, hjheins said:
Does anyone know this behaviour
Something like this has happened in the past. The firmware is flaky to some eMMC variants. If you search the forum, you will find relevant posts. Some users have used my firmware build and been successful, but I don't think the true cause has really been figured out.
-
For me, unfortunately, only OpenCL 3.0.
-
3 hours ago, Celona said:
At this moment fails on ARM Cortex-A53 and Cortex-A55
Looks like I'm already equipped with it by upgrading behind my back.
Spoiler# dnf provides */libopus.so.0 Last metadata expiration check: 0:25:05 ago on Sun Mar 17 20:37:08 2024. opus-1.5.1-1.fc41.aarch64 : An audio codec for use in low-delay speech and audio communication Repo : @System Matched from: Filename : /usr/lib64/libopus.so.0 opus-1.5.1-1.fc41.aarch64 : An audio codec for use in low-delay speech and audio communication Repo : rawhide Matched from: Filename : /usr/lib64/libopus.so.0 -
1 hour ago, c0rnelius said:
My guess would be this patch
Quite possible, because due to my migration to bootstd, this entire code block no longer exists for me.
-
22 minutes ago, Christian Willemsen said:
it worked
OK, then you're now on this version and it's not a general issue, it's about how Armbian's firmware is built.
-
49 minutes ago, Christian Willemsen said:
What device ${entire-device-to-be-used}. Do i put here
If the microSD card in the microSD card slot is the one with the Armbian_24.2.1_Odroidn2_bookworm_current_6.6.16_cinnamon_desktop.img.xz then it is:
dd bs=512 seek=1 conv=notrunc,fsync if=odroid-n2-plus/u-boot-meson.bin of=/dev/mmcblk1It is always the NAME that lsblk enumerates with the TYPE "disk".
-
Out of curiosity, does it boot when you drop in my firmware build?
dd bs=512 seek=1 conv=notrunc,fsync if=odroid-n2-plus/u-boot-meson.bin of=/dev/${entire-device-to-be-used} -
8 hours ago, Maverick said:
I require assistance in utilizing WiringPi for Banana Pi CM4.
Read what the original author posted.
8 hours ago, Maverick said:Limited GPIO support on Banana Pi CM4
Banana Pi CM4 has full generic GPIO support in mainline kernel ready to use. With libgpiod, all the necessary Python 3 bindings are available, so start writing your planned application. Since you have even developed the board yourself, you also have the necessary knowledge of which of the approximately 100 GPIO-capable pins you have wired where.
-
10 hours ago, Igor said:
Should we install this by default?
I'm not sure who really needs the python bindings.
Users keep talking about WiringPi not working for their device, but they don't say what functionality they want to use with it. In the isolated cases where they do, it is such trivial applications that can be conveniently operated with the available command line tools. So no need to involve any programming activities.And the same is true for the Sysfs API fraction. The existing command line tools cover the entire Sysfs spectrum and even go beyond.
For example, I would like to see how someone implements this one-liner with the sysfs:
gpioset --toggle 100ms,100ms,100ms,100ms,100ms,300ms,300ms,100ms,300ms,100ms,300ms,300ms,100ms,100ms,100ms,100ms,100ms,700ms --consumer panic con1-08=activeI'm curious about the precise timing to generate such a blinking pattern.
Or retrieving a pin for three keystrokes and resulting script execution:
gpiomon --num-events=3 --edges=rising con1-08 && bash-scriptFor the users who actually need more complex implementations and have the necessary coding skills, I think they should also be able to install the bindings with:
sudo apt install python3-libgpiodAnd maybe someone wants to use C++ or Rust.
But first and foremost, people seeking help should learn to describe the basic problem they are trying to solve, rather than asking for help as they think it can be solved.
I don't usually respond to requests that don't match this, because nothing is more annoying than realizing that you have wasted unnecessary time on a solution when it could otherwise have been solved more appropriately.And look, what was the immediate response to my given reference in response to a direct question?
On 3/4/2024 at 10:50 AM, Maverick said:will it work with python?
In the case of such NOOBs, further engagement is usually not conducive.
-
The distribution of my choice offers me ready-made binary packages out-of-the-box. However, I have to install the Python 3 bindings separately. I know that the command line tools are apparently also available out-of-the-box in Armbian, but I don't know if the Python 3 bindings are also packaged separately.
-
RK3399: H.264 decoding not exposed in v4l2, only MPEG2 and VP8
in Orange Pi 4 LTS
Posted
Since userspace cannot sensibly select between two decoder instances of the same type, the H.264 hanto decoder is usually disabled for the rk3399 and the H.264 rkvdec is preferred.
videoX-infos-nanopc-t4.log