Compilation runs without any errors, just most important files are being not generated.
Only option what I changed is C library to glibc, because I need it for one program (https://github.com/loki-project/loki-network) that I want to run on Banana Pi.
Reason why I trying to use other build tools for Banana Pi is that lokinet needs glibc 2.29 to run, so I need to compile toolchain with that version of glibc.
I trying now to use external toolchain. Maybe this is topic to separated thread, but in crosstool-ng I experiencing erros (https://github.com/crosstool-ng/crosstool-ng/issues/963)
But, anyway, frank-w can you point me how to make ext4 rootfs partiion?
I had only tried to compile the repo as it is…had not changed anything in menuconfig…and i got the ext4-image which contains a ext4-partition for rootfs
So try first without modifying anything and then change 1 by 1 till the images are not created/updated
It is a HUGE change - you’re changing the main C library used for the image. I hadn’t tested if this works at all and upstream (i.e. original OpenWRT) also does not provide glibc-base builds by default. Expect all kinds of problems. It might work, it might not - be prepared to dig a lot resolving various problems.
Well… with the attitude like this your best bet would be to use ubuntu-based or armbian-based image for this board and free yourself from all the complation-related hassle - after all building software is not a thing expected to be done by a generic standard person out there :-).
If you would change your mind and would like to check what’s going on and what’s the problem is and want people on this forum to be able to help you - please provide more details.
Important are:
Output of git branch command when executed at the same dir you execute make at.
Full build log output. To gather it execute build like this: make clean && make V=s | tee build.log; bzip2 build.log. Attach resulting build.log.bz2 file here.
Contents of your .config. Again, create an archive with it like this: cat .config | bzip2 -9 - > .config.bz2 and attach .config.bz2 here.
Also of a great help would be to provide us with the exact details of the things you did to clone repo and prepare it for the build. Devil usually is in details, you know.
In general you cat put the image to the SD card and then use any partition manager tool you like to do the task. gparted is a best choice under linux, google for “Partition Master” or “Partition Manager” or “Partition Wizard” to find suitable utility for Windows.
There’s a catch though that makes gparted the best for this task: windows-based tools in general don’t know how to handle ext4 partitions. Then, when resizing be sure not to move first partition, you may break bootloader-related magic otherwise. It is OK to resize first partition and it is OK to resize/move other partitions or to add additional partitions. Beware squashfs-based images - they can’t be resized easily.
Fortunately images are being generated. I really can’t figure out what I missed before.
I’m on Arch Linux so I used gparted for resize rootfs partition and this also works fine.
Additionally I founded way to make this system starting from EMMC.
Solution brings me this post: Which preloader image to use?
You, @LeXa2, pointed me which preloader I must use and @frank-w pointed where I must flash.
I partitioned emmcblk0 for boot and rootfs partition, copied content and flash preloader to mmcblk0boot0. Now I can start system from EMMC. Looks like uEnv.txt is not needed because bootargs are hardcoded in preloader. I tried, just-for-fun, to boot Arch Linux ARM from /dev/sda1 (SSD) but bootargs in uEnv.txt have no effect, it’s always booting from mmcblk0 or mmcblk1.
Anyway thak you guys @LeXa2@frank-w for help.
Now I have what I wanted.
Welcome. Glad that it had worked for you after all. Ping back here if any new troubles, chances are we might be able to help. Upd. Out of curiosity, so am I correct that your image is built with glibc instead of musl? If that’s the case it is nice to know that it works too - you’re the first person to test it then.
Yes, I built it with glibc.
I need glibc to run Lokinet router (https://github.com/loki-project/loki-network) but unfortunately it needs glibc 2.29 so i’m not able to start it yet. I tried to compile with external toolchain (crosstool-ng, glibc 2.29) but with no success.
For OpenWRT better luck might be to try patching/porting 2.29 to it. Take a look at toolchain/glibc folder and files underneath. Who knows, it might be porting would be as easy as changing PKG_VERSION to 2.29 and fixing resp checksums and commit ids.
You may try it other way around then: build image with stock openwrt glibc first but also select in menuconfig an option to create a toolchain tarball. Then use this toolchain to self-build glibc 2.29 and then overwrite existing glibc-related files with what you had built directly in the image on the SD card. Or you may want to try building glibc 2.29 with a separate prefix, like, /opt/glibc2.29/, and then use this prefix and LD_LIBRARY_PATH/RUNPATH to build/link/run Lokinet with. This way you’d be having your desired 2.29 glibc existing alongside original image glibc.
Upd. Ah, and are you sure Lokinet has a hard dependency on glibc 2.29+? I don’t see this req stated on its github page.
Ah, that’s why you’ve got this req on 2.29 , I see. I’d suggest to recompile it yet again on the board itself or - if you want to use openwrt as a target - enable creation of cross-toolchain tarball in openwrt’s make menuconfig and use this cross-toolchain to recompile Lokinet. My experience tells that it is generally a good idea to use the same toolchain that was used to build OS for building userland software - this way chances are minimal to hit some obscure incompatibilities.
P.S. Or you may try to use Arch Linux armhf image as your OS. Download any recent Debian image for BPi-R2, preserve anything under /lib/modules/ but replace all other contents of rootfs with Arch Linux rootfs contents.
after a long search I found your manual and image for the bpi-r2. I build one on my own and it’s working - as I see it - very good. One thing is left: How can get the Wifi working?
I found lots of manuals for Debian/Ubuntu but none for OpenWrt, maybe you or frank-w do have an answer or hint?
At least you need wifi-driver in your kernel. Look in my kernelrepo for your kernel-version and apply commits with [wifi] to your kernel-source. Add options to your config (see my defconfig) and build kernel. You need same wmt-tools/config as on debian and you can also use my wifi.sh
, I see. I’d suggest to recompile it yet again on the board itself or - if you want to use openwrt as a target - enable creation of cross-toolchain tarball in openwrt’s