usual user
-
Posts
423 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
On 9/23/2023 at 1:52 PM, winnt5 said:
I know kernel 6.5 rc2 is released before this bug appears.
Moved on to 6.6.0.rc2 and can now confirm the mainline regression.
USB 3.0 keeps working on my M1, but haven't checked if the rk3568 uses the same USB IP. -
1 hour ago, winnt5 said:
Do you test it on NanoPC T4?
Not only with the NanoPC T4, I'm running the same generic kernel build on all devices with aarch64 architecture. The only thing that is device-specific is the DTB, which informs the kernel about device-specific components.
There is no Armbian build system involved for me, hence my claim about the build configuration. -
2 hours ago, winnt5 said:
I found this issue in NanoPC T4
FWIW, I've been running 6.3.0-0.rc1 for 154 days, just rebooted to switch to 6.5.0-0.rc2.
USB will continue to work as before:/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M |__ Port 4: Dev 4, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12MIssue must be blamed on the build configuration, the kernel source code does not seem to introduce regression.
-
I'm guessing you're configuring the rc only after XWindow is already started, that way the input event device can't be added as an XWindow input device at times.
Load the rc keymap during the boot process by adding it to /etc/rc_maps.cfg.E.g.:
* rc-empty your-config-name.tomlas last line added.
-
25 minutes ago, tizianomattei said:
if you need more information
Provide output of
ir-keytableand
ir-keytable -twhile pressing your mapped ir buttons.
-
3 hours ago, tizianomattei said:
nothing happens when I press the buttons
Since you haven't provided any details about what keycodes you've mapped and what desktop features are assigned to them, no one can tell if what you're seeing is what to expect.
-
On 8/19/2023 at 12:44 PM, rpardini said:
UMS mode works absolutely great.
UMS has not interested me much so far. However, the mention still inspired me to bring forward my rebase, which was planned after the v2023.10 GA release. Now my serial console boots up with a nice little boot menu:
*** U-Boot Boot Menu *** Standard Boot NVME USB Mass Storage eMMC USB Mass Storage microSD USB Mass Storage usb 0:3 nvme 0:1 nvme 0:3 nvme 0:4 mmc 1:2 U-Boot console Press UP/DOWN to move, ENTER to select, ESC to quitNow I don't even need to physically insert the SD card back and forth between the card reader and the M1 when I want to perform a firmware update from my host build system, because the M1 can now act as a card reader itself. And that even for NVME, SATA and eMMC storage. I rarely need this because I usually run updates directly from the M1, but it's still nice to have.
However, this only becomes really interesting when HDMI video is also available and the EXPO menu can also be used.I guess the day is approaching when I'll finally run this on the serial console:
run mmc-fw-to-sfIt will transfer my self-contained firmware image build into the SPI flash. I will then lose the possibility to use outdated legacy OS forks and can only use modern operating systems with current bootflows, but if I understand correctly, I have never used anything so unmaintained 😉 But the need to press the RCY button at system startup is starting to get annoying.
-
2 hours ago, AshieSlashy said:
you were able to replace Petitboot by U-Boot in SPI.
There are several tools to write SPI flash. Choose whatever you're familiar with, e.g.:
dd if=u-boot-meson.bin of=/dev/mtd0The tricky part is to wire the SPI flash up in devicetree. Hardkernel seems to have declared this information to be Top Secret. I extracted this information from Pettitboot, but I only got a very unstable functionality. It took me several tries before the data was error-free written, so I'm hesitant to publish my used values. Maybe there is someone out there who knows more reliably functioning binding values and can contribute them.
-
9 hours ago, emk2203 said:
late to the game, but for this we would need to be able to replicate your build.
With the release of U-Boot v2023.10, everyone will be able to create their own firmware on a stable basis.
The only difference to other firmware builds is amake odroid-m1-rk3568_defconfigto setup a suitable configuration for the ODROID-M1.
If you want to build beforehand, you need to dig mailing lists and patchwork for non-landed fixes and improvements to pick them up.9 hours ago, emk2203 said:It would also open the door for more variety in the distributions offered.
As you can see here this has already happened. They use distributions that are not in any way designed specifically for the ODROID-M1 and where Petitboot is not able to support the bootflow used. And this is possible because the rk3568 SOC has sufficient mainline kernel support.
-
10 hours ago, LluviaFria said:
the system boots fine
Judging by your following command excerpts, this time you did everything as required. You should now have my provided firmware build in use and it is working as expected. I.e. it is using distro-boot and should be able to boot various operating systems from USB, SD-card or eMMC as long as either a suitable legacy- (boot.scr), extlinux- (extlinux.conf) or EFI-bootflow is in place. And since it doesn't carry any OS artefacts on the firmware device and uses unmodified OS images for a single drive, OS updates should work much more reliably.
10 hours ago, LluviaFria said:for some reason when i use sudo reboot, the system doesn't boot
In order to determine the cause and possibly find a solution, the serial console logs are mandatory.
10 hours ago, LluviaFria said:i don't have the 4pin UART cable.
If you can't provide serial console logs, you're pretty much on your own. If it breaks for you, you have to keep the parts.
-
On 8/3/2023 at 4:44 AM, LluviaFria said:
I did all the steps as you said
Judging by your following command excerpts, you did not do this.
Since I don't know if your SD card to be prepared was really in a card reader listed as /dev/sda when you ran the command "root@odroidc4:/# dd if=/dev/zero of=/dev/sda1", I can't really tell if you chose the right device.
In any case, you didn't target the entire device for the dd commands as instructed, but only the first partition (dev/sda1). The correct one here would have been "/dev/sda".On 8/3/2023 at 4:44 AM, LluviaFria said:I didn't understand the last step " - boot the odroid c4 and post the serial console log"
Serial console logs are taken via the 4pin UART Connector for system console and are essential for proper debugging.
Because you wrote my firmware in the first partition, and not at the location where it is expected by the MASKROM code, I can't tell what exactly is going on without appropriate console logs. But you have apparently corrupted the contents of the first partition enough, so that the existing firmware also uses the bootflow in the USB storage. However, the original goal is to have an SD card that contains only the firmware and no other system artifacts.
-
On 7/19/2023 at 7:25 AM, LluviaFria said:
I am trying to boot my odroid c4 from a USB 3.0 storage, the steps I am following are the ones that appear in armbian-config
Out of curiosity, are you interested in a little experiment? If so,
- prepare an entire cleared SD card (dd if=/dev/zero of=/dev/${entire-SD-card})
- dd the unpacked firmware (tar -xzf uboot-meson.tgz) that is uploaded here in place with:dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-SD-card}- dd the unmodified Armbian_23.02.2_Odroidc4_jammy_current_6.1.11 image onto your USB 3.0 storage
- plug in the prepared SD card and your USB 3.0 storage into your odroid c4
- boot the odroid c4 and post the serial console log -
1 hour ago, Mohammed Alsayegh said:
What threw me off was the box and stock Android with a spec stating 2GB.
Software that lies about true hardware specifications is nothing new. Even in this forum there are many repetitive posts about this topic.
-
2 hours ago, Mohammed Alsayegh said:
There are four K4B2G0446D chips which from data sheet is 512MB each.
You ignored the organization, a byte is 8 bit hence 512Mx4 x 4 chips = 1 Giga Byte.
-
7 hours ago, pezmaker said:
I did have to add option " -B pull-down"
7 hours ago, pezmaker said:I also couldn't get it to register the button press immediately. I'd need to do more testing but it seemed I needed to hold it down for seconds before it'd register.
The necessity of the "-B" parameter with the observed gpio behavior is probably due to how the gpio is wired up in the DT and how its pin control is set up there.
7 hours ago, pezmaker said:I also wasn't sure how to get a wall message and 5 second wait in there, so in the end I went with a script that loads on startup.
Since I didn't know the exact use case, I only presented the basic command and left it to the user's imagination how it would ultimately be used. It's general shell usage, and if I understand the use case correctly, I'd have e.g. used something like this in a script that loads on startup:
gpiomon --num-events=1 -B pull-down -f gpiochip0 9 && wall power off initiated && sleep 5 && halt7 hours ago, pezmaker said:Thank you for the response!
You're welcome.
-
-
6 hours ago, Дмитрий Батин said:
how to obtain multimedia acceleration on our OPI 4 LTS ( 3\16 version)
To get multimedia acceleration, you'll need an OS with up-to-date mainline software releases and a DE based on Wayland. For applications based on the ffmpeg framework, you will need patched mainline ffmpeg because request-api support is not yet included in mainline out-of-the-box. In order to have HEVC decoder support for the rk3399, you still need the kernel patches, as there is still more development work to be done. For the OPI 4 LTS support you need a suitable DTB that obeys mainline bindings and a device specific firmware to boot the OS. As far as I can see, Armbian offers these two components. So all the necessary information is available to create an appropriate OS.
-
5 hours ago, Peter Andersson said:
could you give me some instruction
I asked you, as a first step, to upload the rk3399-rock-4c-plus.dtb, which is currently provided by the Armbian OS, to be able to check if the thermal zone is really not wired-up. There's no point in putting effort into fixing something that isn't broken.
-
8 hours ago, Peter Andersson said:
the needed drivers or configuration is missing
Exactly, either there is no thermal zone wired-up in the DT or the kernel build configuration lacks the necessary drivers enabled. To exclude the DTB, you can upload yours used in armbian and I can investigate accordingly.
-
-
15 hours ago, vinser said:
Sorry but I didn't get have you used KDE+Armbian on N2+ or any other SBC with S922X?
I didn't claim to use Armbian. I'm using an OS that is compiled for an entire architecture (aarch64) and not for a specific single device. It works for any SOC, provided that a kernel can be built that uses mainline APIs. I can use the same storage device that contains the OS with all my devices (NanoPC-T4, ODROID-N2+, ODROID-M1, HoneyComb, ...). OK, I have some media copies, as flipping back and forth when using multiple devices at the same time is very annoying and impractical. The only requirement for this to be possible is the presence of a firmware that can boot the OS. And here's where my dilemma begins. The OS is 100% FREE & OPEN SOURCE, i.e. it does not provide firmware based on binary blobs. Firmware with mainline U-Boot as payload fulfills all the necessary requirements to boot my OS from any storage media and I have learned over time how to build it for my own. Armbian has always been a great help here, whether it's with knowledge from their forum or with legacy firmware builds as a workaround for my device bring-up until I was able to switch to mainline firmware. And since I've shared my firmware builds here and in other places, I also have confirmations that builds also work for devices I don't own (ODROID-C4, ODROID-HC4, ODROID-N2, Radxa ROCK Pi 4B, Radxa ROCK Pi 4C, ...).
15 hours ago, vinser said:Do you suggest trying the Armbian Jammy Gnome desktop distribution or installing KDE on a Armbian minimal distribution for N2+?
I would suggest you choose the OS you are most familiar with, or the one that best suits your needs as long as it uses recent mainline software. IMHO debian based distributions are way to stable ... outdated. Or you can find someone to backport all mainline improvements and deploy them in the appropriate distribution.
-
2 hours ago, vinser said:
there is no wayland based desktop for Odroid N2+ SBC yet
It's a good thing that my distribution doesn't know about this rumor, otherwise it would probably have to stop working immediately. There are several Wayland implementations, e.g. the plasma-desktop or Gnome with Wayland backend. User space is not really device-specific and therefore no specific solution for a specific device is necessary. As long as there is sufficient mainline kernel support for the components of a device, this even works out-of-the-box, provided you choose suitable software programs. The operating system I'm using works unchanged according to the kernel support for all my devices comparably. The only solution that is not yet satisfactory is hardware-accelerated video decoding, as development for mainline support is still in full swing. But with a suitable SOC selection, there are solutions that leave almost nothing to be desired for comprehensive desktop operation. E.g. my rk3399 based device is feature complete for generic desktop usage. My rk3568-based device only lacks support for the rkvdec2 video decoder IP, the hantro support is already available. The worst is for the S922X, because there is currently no working video hardware acceleration in mainline. But with its CPU processing power, a video playback with moderate resolutions is still usable.
-
3 hours ago, vinser said:
Are there any suggestions to fix this?
To use mainline kernel hardware video acceleration in applications it requires basic support for V4L2-M2M hardware-accelerated video decode in the first place. E.g. firefox has just landed initial support for the h.264 decoder. The next showstopper would be the lack of V4L2-M2M support in the ffmpeg framework. There are some hack patches in the wild, but no out-of-the-box solution. The next showstopper would be the lack of kernel support for the SOC video decoder IP.
The lack of support in the application is a general problem for all devices that provide their decoders via V4L2-M2M. The lack of support in the ffmpeg framework is a problem for all applications that base on it. Gstreamer-based applications, on the other hand, offer out-of-the-box solutions, as the necessary support is already integrated into the mainline gstreamer framework.
When it comes to choosing a desktop environment, Xwindow is a bad choice. It was developed for x86 architecture and therefore cannot deal efficiently with V4L2-M2M requirements due to its design. Their developers at that time also recognized this and therefore developed Wayland from scratch. So when it comes to efficiently using a video pipeline in combination with a display pipeline, a desktop environment with Wayland backend is the first choice. -
6 hours ago, mhoffrogge said:
can you provide those changes
Since I haven't gotten any feedback on my build so far, I don't see much sense in it. In my experience, Armbian users tend to stick to legacy methods and my extensions only affect the upcomming U-Boot Standard Boot. In addition, the adoption of reviewed-by patches from the patchwork to the mainline tree seems to have stalled. So it may take some time until the general support is available out-of-the-box. And these are valuable improvements to the Rockchip platform, which also benefit ODROID-M1 support.
Since Armbian already has a working boot method, I don't see any reason for an underpaid Armbian developer to invest his valuable time in an unfinished solution that anyone can have for free when everything finally lands.
For me, it's different story because my preferred distro requires different prerequisites. I had made my build available so that others could save themselves the trouble of self-building, but there doesn't seem to be any particular interest.
How to check the temperature of Rock Pi S CPU?
in Radxa Rock Pi S
Posted
You're probably running the same DTB without a properly wired thermal-zones.