dhlii Posted March 27 Share Posted March 27 I am trying to build an armbian image for a nanopi R1S-H3 this used to be possible in the past. Now when I build and select the extended board list the R1S-H5 is present but not the R1S-H3. Should I build using another H3 board, or is the R1S-H5 close enought o get it to boot. 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted March 27 Share Posted March 27 Image for H5 certainly won't work. Different SoC, even different architecture (32 vs 64 bit). You can give R1 image a try, doesn't look that much different besides the ugly yellow case. No idea how you built r1s images from Armbian since there is no dedicated config for this board in our build system. Maybe you used some sort of fork? Btw. if you don't mind please shorten your signature, like by removing the gaps between the lines. Thanks 0 Quote Link to comment Share on other sites More sharing options...
dhlii Posted March 27 Author Share Posted March 27 Would I be correct in assuming that the biggest difference between images for the same architecture would be the device tree ? 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted March 27 Share Posted March 27 Yes. However there are various SoC manufacturs for arm64 SoCs like Allwinner, Rockchip, Amlogic and so on and they require custom patching for often both uboot and kernel. So while saying the device tree is indeed the biggest difference it does not boil down to just that. 0 Quote Link to comment Share on other sites More sharing options...
dhlii Posted March 28 Author Share Posted March 28 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. 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted March 28 Share Posted March 28 2 hours ago, dhlii said: 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 ? Yes, that will work unless there is some special weirdness in the R1S-H3 that needs custom drivers...which I doubt for now 1 Quote Link to comment Share on other sites More sharing options...
going Posted March 28 Share Posted March 28 (edited) 9 часов назад, dhlii сказал: I am an embdded linux developer. @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? 9 часов назад, dhlii сказал: 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 ? 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. Edited March 28 by going Add P.S. 1 Quote Link to comment Share on other sites More sharing options...
dhlii Posted March 28 Author Share Posted March 28 @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. 0 Quote Link to comment Share on other sites More sharing options...
dhlii Posted March 28 Author Share Posted March 28 @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. 0 Quote Link to comment Share on other sites More sharing options...
going Posted March 28 Share Posted March 28 @dhlii Thank you so much for the detailed answer. Now I see that you are a much more experienced developer than me. The H3 and H5 processors are pin-to-pin compatible. Theoretically, it is possible to solder one and solder another processor. And it should work.😁Of course it's a joke. Therefore, comparing the DTS sun50i-h5-nanopi-r1s-h5.dts and sun8i-h3-nanopi-r1.dts, I can see many identical nodes of the same name. This comparison will not be difficult for you. I wrote buildroot as an example. There are several such build systems for embedded operating systems. From my point of view, buildroot is not the most convenient to use. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.