Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. I've found information on how to use your own IR remote controller from this site: https://forum.odroid.com/viewtopic.php?f=215&t=44671 In short: 1. Enable logging from the IR kernel module, enter in a terminal: sudo -i echo 1 > /sys/module/rockchip_pwm_remotectl/parameters/code_print dmesg -w 2. Check if your remote is supported by pressing the keys on your remote. It should give you info like: [ 3485.342354] USERCODE=0xfb04 [ 3485.369309] RMC_GETDATA=fd 3. Download the overlay file below and edit the usercode and the code for each key. So for like with the key above it'll be 0xfd 4. Place the header file "rk-input.h" in the same directory as the overlay file. In my case the location is "/usr/src/linux-headers-6.1.43-vendor-rk35xx/include/dt-bindings/input/rk-input.h" 5. Compile and install with: cpp -nostdinc remote.dts remote-precompiled.dts sudo armbian-add-overlay remote-precompiled.dts remote.dts
  3. Today
  4. Hello! I have [ Oprange Pi plus ]. I need Armbian_20.05.1_Orangepipc_buster_current_5.4.43_desktop.img Please help me! Yours sincerely Leonid
  5. Mmh, ok but how can I do that if it panic before reaching the login?
  6. just tried today build Armbian_community_24.5.0-trunk.306_Orangepipc2_bookworm_current_6.6.23_minimal still broken
  7. Description Two kernel branches have been added to 8250, as some of its features were compromised in 6. x, the latest branch is needed for testing Jira reference number [AR-9999] How Has This Been Tested? Both kernels were compiled on UMI and passed [x] Legacy [x] Edge Checklist: Please delete options that are not relevant. [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article
  8. I think that in the first step it is enough to compile only the kernel and install it into an existing OS. You have published a stack dump of the kernel panic. But to say something definite, I need to see this particular kernel source code.
  9. You mean to compile myself an Armbian image? Thanks! I'll give it a shot.
  10. Is there something I could do to help? I have several opi 5, and can set one up... Gullik
  11. I suspect it has to do with the devfreq driver for the MBUS/DRAM controller. https://lore.kernel.org/linux-arm-kernel/a48923b7-12f9-808e-1171-49b826bd5f1c@samsung.com/T/#ma00a3e07248dc7fb2d300b7c9c409f69ffa64c14 In my personal experience this introduces instability into the a64/h5. You could try blacklisting the driver and see if it solves the issue. I personally remove the entry from the DTS and create an overlay to add it back if for some reason I need it. The main issue you reported `Kernel panics with headless boot` in my mind points to it being the driver.
  12. Description Update shellcheck to version 0.10.0 which was released a few weeks ago. How Has This Been Tested? [x] sudo lib/tools/shellcheck.sh Output: Running shellcheck version: 0.10.0 against 308 config files, severity 'SEVERITY=error', please wait... Congrats, no error's detected in config/sources. Running shellcheck version: 0.10.0 against 'compile.sh' -- lib/ checks, severity 'SEVERITY=critical', please wait... All params: --check-sourced --color=always --external-sources --format=tty --shell=bash --severity=warning --exclude=SC2034 --exclude=SC2207 --exclude=SC2046 --exclude=SC2086 --exclude=SC2206 Congrats, no critical's detected in lib/ code. Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] My changes generate no new warnings View the full article
  13. The only way is to do the assembly yourself. First, it is necessary to check the correctness of applying patches to the kernel and u-boot.
  14. @dhlii I wish good health to the developer of embedded Linux. It will be very interesting for me to talk to you. I have a question. Do you use specialized build systems such as buildroot in your work? The first thing to do is add the target DTS to the u-boot. You can take this as a basis: u-boot> find ./arch/arm/dts/ -name '*nanopi-r1*' ./arch/arm/dts/sun8i-h3-nanopi-r1.dts ./arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts linux-stable> find ./arch/arm/boot/dts/ -name '*nanopi*' ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-duo2.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-m1-plus.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-m1.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-neo-air.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-neo.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-r1.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi.dtsi This DTS must match the wiring of the pins of the printed circuit board and match the brands of soldered chips. The second good step is if you add the default u-boot configuration file. This will allow you to repeat the loader assembly by changing only the dts You can take this as a basis: u-boot> find ./configs/ -name '*h3*' u-boot> find ./configs/ -name '*nanopi*' Special attention is paid to the CONFIG_DRAM_CLK parameter. Even on identical boards but from different series, different memory chips can be soldered. After u-boot has done its job and it loads the dtb of the kernel and the kernel itself, we will be able to dynamically change the dtb using overlays. I.e., the DTB in u-boot is hard-coded, the DTB for the kernel we can change dynamically. P.S. Here I have described my own development process.
  15. Looks like the CE (China Export NOT the EU CE) have "re branding" one RK to some HUW chop that was likely in one phone copy running one RK chip and (or more likely tablet).
  16. Two same boards but different cpu. Rockchip labeled works fine with armbian, multitool and libreelec. The board with huawei labeled cpu has the previously described problem, multitool and armbian stop working after a minute. Method of switching bootloaders suggested by @jock works.
  17. @fortdevv you're welcome and thanks for reporting 👍
  18. @IronIgel there's also a small paragraph in the first page about special hardware with a link to a guide on how to fix the issue.
  19. Description armsom-sige7: enable gpu rock-5a: enable gpu, fix poweroff, enable pcie2x1 for M.2 E slot hinlink-h88k: enable gpu How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] ./compile.sh kernel BOARD=armsom-sige7 BRANCH=edge DEB_COMPRESS=xz [x] Tested with armsom-sige7, rock-5a and hinlink-h88k Checklist: Please delete options that are not relevant. [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
  20. Yes, that will work unless there is some special weirdness in the R1S-H3 that needs custom drivers...which I doubt for now
  21. Ok it builds now for bullseye it seems it will be available on 24.5 Thanks all ! Cheers
  22. It appears that the nanopi-r1 image is working. I am an embdded linux developer. I am not expert in Armbian building. But I have built kernels from scratch, written drivers, and created complete linux installs from scratch - i.e. manually done what the Armbian build script does automatically. But I am not looking to do a huge amount of work to get a bunch of embedded linux systems up to use for other purposes. I have a very large collection of SBC's - probably half can run linux. I like Armbian, and it is pretty uptodate - though frankly I am just using these as network conneced devices to manage other systems I am developing on. Regardless they are laying arround collecting dust, they do not require much power and I do not need lots of horsepower. The bad news is that I am an embdded linux developer - so I have one or two of lots of different boards - not 10 BBB's. My 2nd question was if I choose a similar H3 device to the nanopi-r1s-h3 and I either find a nonopi-r1s-h3 device tree or I modify an H3 device tree to match the nanopi-r1s-h3 hardware and then substite that device tree in a different H3 image - that should work ? Though the question appears to be moot and the nanopi-r1 image appears to work for me.
  23. Hello, I'm new to this forum. I would like to know which recent version of ARMBIAN I can install on my X96 Max+ TV box (2GB ram and 16GB version). I've tried to install several recent 24.5 versions but it won't start. Here is the link to the versions I tried to install(Armbian_community_24.5.0-trunk.250_Aml-s9xx-box) I simply renamed the file corresponding to my S905X3.............. box to u-boot.ext https://github.com/armbian/community/releases/tag/24.5.0-trunk.250 The only version I managed to install is Armbian_20.10_Arm-64_focal_current_5.9.0_desktop. So I'd like to know which version is best suited to my box. The CPU in the box is an Amlogic S905X3 only, I followed a procedure that made me use an S905X2 with Armbian_20.10_Arm-64_focal_current_5.9.0_desktop. Here is the link https://www.youtube.com/watch?v=nETXagKHYGI Is it possible to have your help if possible by telling me the procedure for a perfect installation. Thank you in advance.
  24. Yesterday
  25. I noticed this thread, I had the same issue. And found the solution here: Pine A64-LTS not booting and [RESOLVED] PineA64LTS doesn't want to boot. Seems that in my dtb-file there was something missing what caused the root not being found or mounted??, the option: non-removable; meson-sm1-a95xf3-air.dtb has it also missing on mmc@ffe05000 from what I think is your root, the option: non-removable; Hope it helps It solved my UUID not found problem.
  26. Hello! Thank you jock for fixing the problems! I am just updated, and it's really working now. Thanks!
  1. Load more activity
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines