For people who have am335x computers - e.g. beagle device

[summers]

Yes [url]https://github.com/beagleboard/BeagleBoard-DeviceTrees/[/url] is the more modern device tree overlays from am335x devices. There are tag commits e.g. I'm going off [url]https://github.com/beagleboard/BeagleBoard-DeviceTrees/tree/v7.1.x[/url] and I use the Robert makefile - as it includes the -@ that has the links need (e.g. symbols) in the device tree for simple ways of referencing nodes.

[summers]

Are there any users of the chlli board still using arch arm linux? Do you use the lcd panel? E.g. do my updates of the the am335x terr need to support you?

In particular the device tree for am335x was a mess and non functioning. As main target is beagle devices, I changed to using the beagle board device tree github, as its maintained and up to date. However chilli board isn't in the beagle family, and so not in the beagle github. Hence my current am335x device trees I think don't have the chilli board in, and certainly don't have the lcd panel.

I really just need to know if anyone cares any more?

[summers]

@graysky has just merged the 7.1 kernel - so when its compiled on their side it should hit the archive.

[summers]

And the kernel was compiled today (Kevin IIRC has a far faster arm v7 machine - so compiles are far quicker than on the beagle board.) This means you can get the new kernel by just doing an update.

[graysky]

Side note - are you cross compiling? The kernel is one of the few packages that you can build on your x86-64 machine. I just updated the needed packages for armv7h (aarch64 is packaged by Arch Linux in [extra]). Note that if you need the headers package dkms will not work properly when compiled in this fashion. To try it, see: https:// aur.archlinux.org/packages?O=0&K=armv7l

To build:
CARCH=armv7h ARCH=arm CROSS_COMPILE=armv7l-unknown-linux-gnueabihf- makepkg -sCAfd

Alternatively, and for all other packages, you can use distcc if you were unaware with our toolchains.

https:// aur.archlinux.org/packages?O=0&SeB=nd&K=distccd-alarm

[graysky]

I stood up a mirror of these packages if anyone cares to use them.

Add to pacman.conf on your x86_64 box:
[graysky]
Server = https:// pkgmirror.sametimetomorrow.net/public/repo/os/$arch

Add my gpg signing key:
curl -L "https://keys.openpgp.org/vks/v1/by-fingerprint/7307D88DBDD27F406535147F7D48D04DF625E34A" -o key.asc
pacman-key --add key.asc
pacman-key --lsign-key 7307D88DBDD27F406535147F7D48D04DF625E34A

[summers]

That would make some sense - especially for my armv5 NAS. That is very limited (Marvel kirkwood with 400 BogoMips) vs my Gen 12 i7 desk top (3000BogoMips - and something like 10 CPUs).

I'm usually only install cross compilers if I have to - my desk top already has too many on it. I've a cross compiler for Arm M boards, arm-none-eabi that comes direct from arch. My msp430 board have a cross compiler (msp430-elf) that IIRC is linked to newlibc. Then I have an armv7l-linux-musleabihf - a cryptic combo for a board out of china.

Hassle with full OS cross compilers is that C++ compiler need to be build against the C library you are using - that means you need at least the headers from that C library to even start the compilation. Thats gets tricky. I usually use the musl cross compiler script for doing an inital build with the right triplet. Then I recompile a modern gcc and glibc against the initial file structure for that target.

With Arch problem then need to the the package builder working against an arm target - I suspect that isn't too bad to do, but have never done it.

Think its only on the armv5 that I'm all that motivated, just creating a build environment and I've had to install something like 15 bits of software is /usr/local/bin - gcc (that I need for modern glibc) has been compiling for 3 or 4 days so far - I just leave it going in a detached screen.