usual user
-
Posts
423 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
-
1 hour ago, Rodrigo Elizei said:
I tried but I could do it.
The necessary command has already been given before:
ir-keytable -s rc1 -tp allIt can be used to collect the scancodes to create the MXQ-PRO-4K.toml. The link has been provided to look up the meaning of the specified parameters and to obtain further background information. This command shows what the contents of the MXQ-PRO-4K.toml should look like:
man rc_keymapFor reference see the *.toml files that come with v4l-utils.
With your provided information, the /etc/rc_maps.cfg entry must look like this:
* rc-rktvbox MXQ-PRO-4K.toml -
9 hours ago, Rodrigo Elizei said:
gpio_ir_recv
The hard work is already done, the kernel enumerates your IR device. Basically, only a suitable keymap is missing to emit the key codes you want. Each IR remote control sends different scan codes and each user expects different keycodes that are triggered at the touch of a button, so it is up to each user to create a corresponding keymap. Use ir-keytable -s rc1 -tp all from the v4l-utils ackage to determine the scan codes and assign them a keycode in e.g. a MXQ-PRO-4K.toml (man rc_keymap). If the MXQ-PRO-4K.toml located in the /etc/rc_keymaps directory is also registered in /etc/rc_maps.cfg, it will be loaded at system startup and the remote control will work out-of-the-box, e.g.:
* rc-empty MXQ-PRO-4K.toml -
9 hours ago, jock said:
Do you know if it is sufficient to install packaged falkon, qt and gstream packages on Ubuntu Jammy/Debian bullseye to get thing working or there is the need to compile something by hand?
When I am asked about Debian and its derivatives, I usually jokingly answer "IMHO Debian is stable ... outdated". I say this because Debian targets x86 as the main architecture. Because the x86 architecture has been feature complete for decades, you can also use older stable program releases with full functionality and it takes time till new releases trickle in. But we play with the ARM architecture and there the development is still at the bleeding edge. Program releases can therefore not be up-to-date enough, and usually still require pending patches. Fedora is tracking mainline quite close.
To check what the current status is, I recently conducted a small experiment. My current system is based on fedora FC34 and is due to WIP patches and current release versions on a well-functioning state. Many of the components I added manually have recently landed in recent mainline versions. I have now copied a rootfs with the content from the upcoming fedora FC37 KDE Plasma Desktop Spin into a free partition of my NVME and added my current kernel build. After I also added a boot stanza to the extlinux.conf to start this new system, I restarted my device. After the obligatory first start configuration, I then had an equally functioning system as with my old FC34 but without further modifications to any userspace component.
Hence my claim: with current pure mainline userspace releases you can have out-of-the-box support.
Unfortunately, I can't say to what extent this experience can be transferred to Debian and its derivatives. It depends on the releases it currently carries.
The firmware and kernel will still need some out of tree components for a while, but this is easy to handle. And I am sure that one or the other userspace program sooner or later will also be rebuilt with some patches for early adaptation of new features. Development will never end. -
3 hours ago, multiblitz said:
So, is there an alrernative path ?
Maybe this approach can serve as a poorman solution until a real solution is available:
Create your kernel packages of the same variant in separate directories. In any case, the directory name must be different from the ${kernelversion} component. Now create a sym link whose name corresponds to the ${kernelversion} component and which points to a kernel package directory. With a single boot stanza in extlinux.conf for the ${kernelversion}, the kernel can now be booted and the kernel can find its associated modules to load. With a simple change of the sym link you can now change the kernel package used. Although you lose the possibility to decide at boot which kernel package is used, this should not play a role in the planned access with ssh anyway.Spoilerlrwxrwxrwx 1 root root 24 Okt 16 18:13 5.19.14-rockchip64 -> 5.19.14-rockchip64-100Hz drwxr-xr-x 2 root root 40 Okt 16 18:12 5.19.14-rockchip64-1000Hz drwxr-xr-x 2 root root 40 Okt 16 18:12 5.19.14-rockchip64-100Hz drwxr-xr-x 2 root root 40 Okt 16 18:12 5.19.14-rockchip64-250Hz ln --symbolic --no-dereference --force 5.19.14-rockchip64-250Hz 5.19.14-rockchip64 lrwxrwxrwx 1 root root 25 Okt 16 18:47 5.19.14-rockchip64 -> 5.19.14-rockchip64-250Hz drwxr-xr-x 2 root root 40 Okt 16 18:12 5.19.14-rockchip64-1000Hz drwxr-xr-x 2 root root 40 Okt 16 18:44 5.19.14-rockchip64-100Hz drwxr-xr-x 2 root root 40 Okt 16 18:47 5.19.14-rockchip64-250Hz -
2 hours ago, multiblitz said:
when I look onto the conf file, there is a default entry which has some more entries
This is a boot stanza that is set up for use with my kernel builds. They are generic mainline builds, i.e. they are suitable for all devices with aarch architecture for which sufficient mainline support is available. It is called "default" because a symbolic link (linux) pointing to ${kernelversion} controls which kernel is currently in use, and therefore no explicit name can be specified. Label naming has no functional consequences.2 hours ago, multiblitz said:And I dont have a /usr/lib/modules/linux/dtb/:
If you had followed the instructions of the second important post (First step: prepare kernel package (copy files around)), you would have everything. This is necessary because the same file names cannot be hosted multiple times in /boot and would overwrite each other.
2 hours ago, multiblitz said:As I will always use only SSH with the NPiNeo3, the default is important for switching...
Without uboot console access, you won't have a way to choose which kernel to boot with when booting. You will get always the one of the first bootable stanza.
2 hours ago, multiblitz said:I changed the name of the new copied content of the 100HZ Kernel as you see
This will not work, you cannot change the ${kernelversion} component arbitrarily, because it is compiled into the kernel binary and is used, for example, for the localization of the modules to be loaded.
2 hours ago, multiblitz said:if there is a way how to give a custom configure kernel its own name without messing up sd card image creatiin, please let me know
Sorry, but here is a point reached where Armbian knowledge is required, which I do not have. Here you need to read the Armbian documentation or motivate an Armbian maintainer to help you.
-
43 minutes ago, jock said:
kernel interface for codecs has been made "stable" very recently (I guess in kernel 5.19).
Even better, 6.1.0.
45 minutes ago, jock said:I don't know what is the current status
Browsers that are using the qt5-qtwebengine backend in a wayland environment (e.g. Falkon) are working flawless. The Qt Multimedia module uses the gstreamer framework and wayland uses proper KMS/DRM support.
-
6 hours ago, multiblitz said:
Now, the first question is how to get the second Kernel with 100 HZ Timer onto it
The main problem with kernel.deb packages is that not all noteworthy kernel artifacts are included, but are generated by the installation routine. E.g. the initramfs or depmod results. If the system installation routine also removes other installed kernels from the system, this is not helpful.
I therefore prefer the method of extracting the installed kernel artifacts from a full image. To do this, I loop-mount the image and then copy the components over to /usr/lib/modules/${kernelversion}.
6 hours ago, multiblitz said:which Kernel package do you mean in my example ?
This procedure applies to all kernels that you want to install. With my method, a kernel installation consists of instantiating the /usr/lib/modules/${kernelversion} directory branch.
6 hours ago, multiblitz said:but than did not know how to teach "uboot" that its there now
To be able to make distro-boot aware of a new kernel, dublicate a boot stanza in extlinux.conf and adjust the ${kernelversion} part. The same concept as with grub.
6 hours ago, multiblitz said:So, the current infos are:
With this information, a boot stanza should look something like this:
Spoilerlabel 5.19.14-rockchip64 fdtdir /usr/lib/modules/5.19.14-rockchip64/dtb/ kernel /usr/lib/modules/5.19.14-rockchip64/Image initrd /usr/lib/modules/5.19.14-rockchip64/initrd.img-5.19.14-rockchip64 append root=PARTUUID=59d35469-01 rootwait rootfstype=ext4 splash=verbose console=ttyS2,1500000 consoleblank=0 loglevel=1 ubootpart=59d35469-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u consoleblank=0 quiet irqaffinity=0 nosoftlockup nmi_watchdog=0 nohz=on isolcpus=nohz,domain,1-3 nohz_full=1-3 rcu_nocbs=1-3 no_balance_cores=1-3 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 -
It are basically two posts that matter. This to collect the necessary information for the implementation, and this to make the preparations on the basis of the collected information and to compile an extlinux.conf. Of course, you have to adjust the deviations from your system accordingly.
1 hour ago, multiblitz said:can you give me a command-line type of tutorial what to do ?
The commands for the command-line are already given there.
-
-
-
4 hours ago, armband said:
My question was regarding the possibility of downloading armbian via the Orange Pi to the SD Card.
I don't know Android and can't therefor help here, but I'm sure an experienced Android user can also use it to transfer an image to an sd card. However, if you are able to write an image to a USB flash drive, use a micro SD to USB adapter with a device whose system you are familiar with to write to an SD card. It is then the same procedure that you already know.
-
On 10/9/2022 at 6:11 PM, rpardini said:
Don't hesitate to send me an -rc tag number and the patchset / .config and I'll drop it in there asap
I just used tobetter's tree at the beginning to learn what components are needed for the M1. But then very quickly I started to get the patches directly from the mailing lists (patchwork) to have the last improvements. I just made preparations to build my 6.1.0-rc1 kernel package with these out-of-tree patches next week:
Spoilerlinux-0020-drm-from-list.patch linux-1000-drm-rockchip.patch linux-1001-v4l2-rockchip.patch linux-2001-v4l2-wip-iep-driver.patchIf I'm not completely wrong, Armbinan also applies these patches in one way or another. But they are not M1 specific either. Now add this set and that's it. I didn't check it, but with "linux-0001-rockchip-from-6.1.patch" it should also work with 6.0.0 sources. There's a lot of unnecessary stuff in it, but with 6.1.0-rc1, the set is no longer necessary anyway.
When it comes to the .config, it becomes difficult, my kernel package is built as a generic kernel, i.e. one build for all supported devices of the same architecture. I'm happy to provide my .config, but it fluctuates a lot and is therefore a snapshot. For the M1 support I only changed four config options from "m" to "y" to get my personal preferences and additionally built the module for the SPI controller. Everything else is like I use it for all my other devices.Board DTS is in flight.
-
-
11 hours ago, rpardini said:
Damn it, I can't get even one right.
No reason to regret, I do not expect any significant new development in the legacy firmware and there is therefore no need to rebuild it again and again.
11 hours ago, rpardini said:I just got no time to work it, and it's very messy not ready for release (eg is amd64 only).
That was the reason why I appreciated your work, I could go the lazy way and take what you provided without having to build it myself.
11 hours ago, rpardini said:Hopefully we can then move the 5.19 edge to current and add 6.1-rcX as edge, with a single patch?
You can have it already with 6.0.0 with only a few backport patches. See here for reference. But 6.1.0-rc1 is only round about a week away.
On 10/7/2022 at 10:41 PM, rpardini said:I have NOT verified skip_spiboot = false can be set from Armbian yet.
Out of curiosity I looked at your rk3568-odroid-m1.dtb. You still carry all the shortcomings and missing improvements that tobetter has not yet backported (like e.g. broken USB, missing SPI flash support, ...). with the posted "Add support for the Hardkernel ODROID-M1 board" series there is nothing left you need from tobetters tree. If you insist on using an outdated kernel version, all necessary backport patches can be inherited from the mainline tree. Generic mainline support is currently already more advanced than what the manufacturer offers.
-
8 hours ago, rpardini said:
It does not carry an u-boot anymore
You've removed the only part I used from your image, but don't worry, if the rumors come true that Rockchip is releasing ATF sources, I'll create my own firmware and replace petitboot completely.
6 hours ago, Cornelius said:Last I heard everything worked but the eMMC, but that was "fixed" in V3. So hopefully that's fine now.
For 6.1.0-rc1 you only need this patch set for the board dts, everything else has landed. It also configures the hardkernel SPI flash partition layout, so fw_setenv is working for petitboot to set "skip_spiboot = false".
-
All outstanding DT patches just landed. Thus, the essential rk3568 SOC support is available out-of-the-box with the release of 6.1.0-rc1. With the exception, of course, of the board DT. The board manufacturer has no plans for mainline support in the near future. There are some efforts by the community to take the initiative, but this is only second-hand support. Only the board developer can be the authoritative source because only he knows all the details of the design. For proper mainline support, it is the obligation of the board designer to deliver a board DT as an absolute minimum requirement. Everything else can then be taken over by the community, because it is no longer board-specific and can benefit from similar development of similar boards. This fact is demonstrated with this SBC, although no mainline SOC support has been contributed by the board manufacturer, my desktop OS deployment works perfectly.
11 hours ago, Ricargr said:Any advance porting armbiam to the M1
For the time being, you have to provide your own board DT, wait for the community support to land in mainline and trickle down into distributions, or underpaid Armbian developers provide it for free.
-
5 hours ago, mfreudenberg said:
this solution didn't work out on my Rock-PI
This is quite possible because your uboot is built with other features. E.g. you have no usbkbd support as can be seen from the coninfo output. You could have used nulldev, but bootdelay is even the better solution for your situation.
5 hours ago, mfreudenberg said:Interestingly, after reflashing a different U-Boot without the bootdelay mod, i wasn't able get back to the u-boot console.
Saved uboot environment is usually not cleared by a firmware update and yours is even maintained in SPI flash as can be seen by:
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...doneTo reach the console again, I would use a completely deleted SD card (dd if=/dev/zero of=/dev/${entire-card-device-to-be-used}) and then install a firmware (dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.bin of=/dev/${entire-card-device-to-be-used}). If you boot with this prepared SD card and removed eMMC module, you should finally reach the console after all unsuccessful boot attempts. Be patient, there will be some. If you had used nulldev, this would not work, but deleting the SPI flash should definitely let the environment fall back to the uboot built-in default.
-
And off topic, after reading out of curiosity of u-boot-2022.07/doc/README.iomux, I would do this in my device's uboot console and forget about the build of uboot:
Spoiler=> coninfo List of available devices: serial@3000 00000007 IO serial 00000003 IO stdin stdout stderr nulldev 00000003 IO vidconsole 00000002 .O usbkbd 00000001 I. => printenv stdin stdin=usbkbd,serial => setenv stdin usbkbd => saveenv -
On 9/16/2022 at 3:14 PM, mfreudenberg said:
That's not a patch. That's the config file i am extracting from the compiled u-boot*.deb to chek if the patch was applied.
Sure, but mainline "make rock-pi-4-rk3399_defconfig" sets BOOTDELAY=2, so the Armbian build system has to cause this change.
Maybe that's what you should be looking for:[ o.k. ] * [l][c] u-boot-rk3399-set-bootdelay.patchOn 9/16/2022 at 3:14 PM, mfreudenberg said:I don't understand why?
Sorry, but we have here reached a point where Armbian knowledge is required, which I do not have. You now need an Armbian maintainer to help you. You now know which uboot modification is necessary to fix your issue and if you do not find a solution to build uboot yourself you still have my firmware. As I can see from your script log, my version is even more up-to-date, but that doesn't really matter.
-
4 hours ago, mfreudenberg said:
Did you just replaced the local source folders of your armbian-build-framework repo?
Not at all, I run fedora on all my SBCs and build on target. I simply built the 2022.07 RPM source version I had already handy. The source references should only serve to let you know what you have received from me. Which specific version is ultimately used is not really important.
4 hours ago, mfreudenberg said:Any idea, what that means?
Not sure, but did you pulled in ATF properly, the BL31=.../bl31.elf clause of your referenced mainline documentation?
But since we have proven that the BOOTDELAY setting is all you need, you can also use the Armbian version.
From you previous rock-pi-4-rk3399_defconfig sniplet I see this:On 9/12/2022 at 3:32 PM, mfreudenberg said:CONFIG_BOOTDELAY=0
This is not present in the mainline sources, i.e. it is added by an Armbian patch.
So you just have to locate the Armbian patch in the Armbian build system and replace 0 with -2 and you are ready to go. -
10 hours ago, mfreudenberg said:
mmcblk1boot*
These are special emmc devices and are read only by default, as can be seen in the RO column of the lsblk output. As far as I know, the rk3399 MASKROM code has no support to use them as a boot device, therefore useless in terms of a firmware location.
9 hours ago, mfreudenberg said:So my question would be, which parameter did you set to get the serial console not to react on my "random" keys?
My provided firmware is a build from this release tar ball. It pulls in the ATF binary build from this release tar ball and has only applied this modification:
Spoilerdiff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index 4d534c3..13d9d18 100644 --- a/configs/rock-pi-4-rk3399_defconfig 2022-07-11 15:42:58.000000000 +0200 +++ b/configs/rock-pi-4-rk3399_defconfig 2022-09-12 18:31:31.038651852 +0200 @@ -12,6 +12,7 @@ CONFIG_DEBUG_UART_BASE=0xFF1A0000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 CONFIG_DEBUG_UART=y +CONFIG_BOOTDELAY=-2 # CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock-pi-4b.dtb" CONFIG_DISPLAY_BOARDINFO_LATE=y -
5 hours ago, mfreudenberg said:
I used the fourth of the /dev/mmcblk devices ... labeled with BOOT
Looks like you choose the wrong device name. The firmware area resides between MBR and the first partition. You probably used the boot partition and the original firmware remained intact. Therfor you have corrupted the data in the boot partition which has rewarded your original firmware with a boot failure. The desired device name is the one marked with type "disk" in an lsblk output. That's the entire device or raw device I've called entire-card-device-to-be-used because I don't know how your storage is connected and will show up.
Example lsblk output:
SpoilerNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 29,8G 0 disk ├─sda1 8:1 1 512M 0 part └─sda2 8:2 1 28,9G 0 part sdb 8:16 0 931,5G 0 disk ├─sdb1 8:17 0 2G 0 part ├─sdb2 8:18 0 6G 0 part └─sdb3 8:19 0 900G 0 part /mnt/sdb3 sdc 8:32 1 29,3G 0 disk └─sdc1 8:33 1 29,3G 0 part /mnt/sdc1 mmcblk2 179:0 0 14,6G 0 disk mmcblk2boot0 179:8 0 4M 1 disk mmcblk2boot1 179:16 0 4M 1 disk mmcblk1 179:24 0 29,7G 0 disk └─mmcblk1p1 179:25 0 20G 0 part / zram0 252:0 0 2,8G 0 disk [SWAP] nvme0n1 259:0 0 931,5G 0 disk ├─nvme0n1p1 259:1 0 2G 0 part ├─nvme0n1p2 259:2 0 6G 0 part └─nvme0n1p3 259:3 0 900G 0 part /mnt/nvme3 -
3 hours ago, mfreudenberg said:
See also my logs and patches
Sorry, I'm confused what you're really doing. Before we sort this apart, let's do a quick test.
I built a firmware for you and uploaded it here. Please download the archive and copy it unpacked into the firmware area of your SD card as follows:dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.bin of=/dev/${entire-card-device-to-be-used}This is doing what nand-sata-installer is doing behind the curtains.
Please test and report if the boot process still stalls.
Odroid N2: Issues with recent firmware and emmc modules
in Odroid N2/N2+/HC4
Posted · Edited by usual user
Since I have already uploaded 2022.10 GA at the request of someone else, it can be downloaded here if there is still a need.
The u-boot GitLab is here. But I am building from the release tar ball with a fedora toolchain.
In any case, you only get the u-boot.bin, which still has to be signed with the binary-only tools from the vendor u-boot tree and combined with the binary-blob artefacts to the FIP.
In the case of Armbian, surely the better solution is for someone to adjust the Armbian building system to a more recent version and issue a pull request so that the change can be integrated into Armbian. He will certainly reap the thanks of many happy Armbian users.
By the way, for another occasion I just verified that UEFI boot also works.
See console.log for reference.