Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. @going Thanks for the DT information. I did get my nanopi-r1s-h3 working with a nanopi-r1 armbian build. I am not sure why but it did not work the first time I tried. Regardless it is now. That reduces my motivation to start modifying things. But I will look into getting the Device Tree correct later and your directions will be useful. The nanopi-r1 is an H3 device so what I would have to address is the differences between the r1 and the r1s.
  3. @going The short answer is yes, I have used buildroot, but no, not in a long time. In 2003 I ported Linux to the Pico E12 - this is an embedded system on a CF card - I wrote an article in Linux Journal about that project. Linux on the E12 was so tiny that Buildroot which I do not think existed at the time would have been a nuclear weapon. I had a very rudimentary installation - beyond the kernel. I beleive that I used Busybox at the time. I have used Buildroot - and similar tools in the past. Over the last 20 years my embedded linux work gets less embedded each year. That is not my choice, that is determined by the demands of my clients. Most recent embedded Linux projects are something like - We have a custom board that is basically a Beagle Bone Black - or some similar common reference design. with a couple of additional sensors. So pretty much all I end up doing is writing and testing an app - usually on a laptop, that then runs on their "embedded" device. Plus some device tree mods for their hardware differences and MAYBE modifying a device driver to support custom hardware. I have not needed to use buildroot in years. I am doing less and less embedded linux work and more and more deeply embedded work - that is not a choice - though I have no problem with it. It is driven by the market. People hire me more frequently for IoT work on STM32's or ESP32's or similar devices. That work more closely resembles the Linux work I did for the E12 in 2003 - except that the E12 was far more difficult, there were no debuggers, and getting the transition to virtual memory working totally blind as pretty difficult. My resurgent interest in Armbian is less driven by Customers - I have used Armbian on products for Clients. And more as a tool for IoT development. I have several concurrent projects and increasingly I am using some BBB or Hummingboard or OPI as the computer that it connected to the embedded IoT device I am working on. So I write software on my desktop or laptop. SSH into an OrangePiOne that is connected to a IoT device, used the OPI1 to flash the IoT device as well as to lot serial output and in some cases to simulate inputs. Sometimes when I do not care about build times - I will even build the software on the Armbian host. I have a post install script that I run that sets up very similar environments on most of my linux devices - so that If I move from my laptop to my desktop to my router, to my servers, to the array of embedded linux devices - I have the same environment. I use Debian on all my large systems - and that means Armbian is suitable for the embeded linux devices. I develop almost entirely from the command line - because that process is the nearly same everywhere. So I am here asking questions about my nanopi-r1s-h3, Because I am re-purposing a device bought for a forgotten project into a host for an ESP32 project I am currently working on. It is either that or add another Dell R415 into my Rack - and that uses far more power, and cant be directly connected to a device that is in the ceiling or behind a wall.
  4. 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
  5. Today
  6. 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
  7. Mmh, ok but how can I do that if it panic before reaching the login?
  8. just tried today build Armbian_community_24.5.0-trunk.306_Orangepipc2_bookworm_current_6.6.23_minimal still broken
  9. 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
  10. 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.
  11. You mean to compile myself an Armbian image? Thanks! I'll give it a shot.
  12. Is there something I could do to help? I have several opi 5, and can set one up... Gullik
  13. 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.
  14. 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
  15. 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.
  16. @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.
  17. 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).
  18. 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.
  19. @fortdevv you're welcome and thanks for reporting 👍
  20. @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.
  21. 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
  22. Yes, that will work unless there is some special weirdness in the R1S-H3 that needs custom drivers...which I doubt for now
  23. Ok it builds now for bullseye it seems it will be available on 24.5 Thanks all ! Cheers
  24. 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.
  25. 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.
  26. Yesterday
  27. 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.
  1. Load more activity
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines