On 23/04/2021 18:50, Steven Hirsch wrote:
> I'll try to make sense of all the information floating around. There
> seem to be at least a dozen sites with pin listings on them and
> sometimes it's not clear which unit they're referring to.
Yup, it's a real dog's breakfast of an ecosystem, and it doesn't help
that TI have changed the tooling for the chip/boards and kernel at least
3 times since the image that David ships with the units.
> Ah - ok. As I mentioned, this is an OLD installation I'm trying to
> bring up and it didn't have the *C0* source or logic for it in the setup
> file. This raises the question of whether my older binaries will even
> work with a newer overlay (even assuming it's ported to the new kernel).
Probably not. Your best bet is to pull David's repo from github and
start over:
https://github.com/dgesswein/mfm
One approach is:
```
cd ~root
git clone
https://github.com/dgesswein/mfm
cd mfm/emu && make
cd ../mfm && make
```
>> Further you need to restructure the device tree overlay .dts file for
[snip]
> The key to this, I assume, is that one needs the updated sources - correct?
>
> In this arena - once again - I'm overloaded with the amount of
> information on overlays and not clear which tutorial applies to 4.x vs.
> 3.x kernels.
Most, if not all, of the tutorials are outdated, I'm afraid. A *high*
number of projects have simply stayed on the older releases; the only
serious casualty, as you've found out, is wireless support, which got a
lot better in Linux 4.x + associated distros.
In fact, in one of the very last commits to the 3.8 kernel for
BeagleBone, they completely disabled the wireless MAC for both the Black
and Green Wireless boards:
https://github.com/beagleboard/linux/commit/e9c8a8a542d1f0b1ea1cdd24f3473903ea0f46b5
So if you are determined to make your wireless work with the cape, you
have a fairly steep hill to climb, based on my experiences last September.
That said, I have gotten at least one brand of USB Wireless adapter to
work with the 3.8.13 device. It is an older 802.11n device that has
kernel support back in the 3.x series.
> It would be good to see the work you did if you'd be interested in
> sharing it. If you contact me privately I can give you a Dropbox upload
> link.
It will take me some time to get my files in order, I have some other
pressing priorities for the next few days. I won't need a Dropbox folder
- I'll post it on GitHub once it's in a usable state, as a fork of
David's repo.
Here's some short notes on what I did:
* Rework the assembly code to use the modern compiler. The pasm tool
David uses in his image is obsolete and not shipped in current
images, nor are packages for it built any longer. The porting
required changes to the assembly files for the new format, creation of
external mapping files for the linker, and a new Makefile.
* Rework the assembly build process, which is more complex since the
one-line `pasm` tool was replaced by a separate compiler `clpru`
and linker `lnkpru`, plus a `hexpru` that converts to `.bin` file
format. (The default linker output is an ELF binary, suitable only
for loading through the new remoteproc interface. I ran out of steam
before getting that working.)
There is also a new `abspru` program through which the ELF binary must
be passed, then recompiled with the generated header via `clpru` a
second time to produce the absolute listing.
* Rework the cape's Device Tree Overlay for the latest kernels. The
theory was to use the universal cape manager for GPIOs, but steal the
PRUs for ourselves. This did NOT work on the first try. Instead, I
used bone-pinmux-helpers that allowed for multiple pin type settings.
That I believe was compatible with the `config-pin` utility.
* Rework the DTO compilation as shown in the last email.
* I noticed that in the 5.x kernel series, the entire `/sys/class/gpio`
hierarchy was tagged for removal, meaning the new `/sys/class/leds`
and `/sys/class/keypads` endpoints for GPIOs may need to be used
instead. This would require changes to the bootstrapping code in the
C/C++ code.
More to come...
-Joan