Converting 'slot' based setup to uboot overlay?

[snhi...@gmail.com]

I'm having no success at all running an old mfmemu setup on a current version of Debian.  It seems the 'slot' pseudo-files are gone.  I tried disabling the overlays, but that also renders Wifi inoperative.  I looked for a tutorial on converting slot-based setup to overlay, but find nothing but handwaving.

Has anyone made this leap yet?

[Joan Touzet]

I spent a couple of very frantic weeks doing this to try and get the
BBGW working with the cape. Ultimately, I backported the BBGW config to
the version on the MFME.

If the community is interested in my notes & work, which includes
modernizing the toolchain for the current TI workflow, let me know. It's
not complete.

-Joan

> --
> You received this message because you are subscribed to the Google
> Groups "MFM Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mfm-discuss...@googlegroups.com
> <mailto:mfm-discuss...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mfm-discuss/11a499f9-fc57-48af-b236-fd60483752ebn%40googlegroups.com
> <https://groups.google.com/d/msgid/mfm-discuss/11a499f9-fc57-48af-b236-fd60483752ebn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Steven Hirsch]

On Fri, 23 Apr 2021, Joan Touzet wrote:

> I spent a couple of very frantic weeks doing this to try and get the
> BBGW working with the cape. Ultimately, I backported the BBGW config to
> the version on the MFME.
>
> If the community is interested in my notes & work, which includes
> modernizing the toolchain for the current TI workflow, let me know. It's
> not complete.

Do I understand that you have a correct overlay that can work with my
BBBW? I'm not sure I'm parsing your message correctly. In particular,
what does MFME stand for?

Thanks!

Steve

>
> -Joan
>
> On 23/04/2021 10:51, snhi...@gmail.com wrote:
>> I'm having no success at all running an old mfmemu setup on a current
>> version of Debian.  It seems the 'slot' pseudo-files are gone.  I tried
>> disabling the overlays, but that also renders Wifi inoperative.  I
>> looked for a tutorial on converting slot-based setup to overlay, but
>> find nothing but handwaving.
>>
>> Has anyone made this leap yet?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "MFM Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to mfm-discuss...@googlegroups.com
>> <mailto:mfm-discuss...@googlegroups.com>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mfm-discuss/11a499f9-fc57-48af-b236-fd60483752ebn%40googlegroups.com
>> <https://groups.google.com/d/msgid/mfm-discuss/11a499f9-fc57-48af-b236-fd60483752ebn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
> --

> You received this message because you are subscribed to a topic in the Google Groups "MFM Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/mfm-discuss/7KdKseKvHTI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to mfm-discuss...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/d59a9689-1f02-65d9-dce9-28663df953a5%40gmail.com.
>

--

[Joan Touzet]

Hi Steve, sorry about the confusion.

The changes I made make the BeagleBone *Green* Wireless (BBGW) work with
the MFM Emulator (MFME) cape. Because the BBGW re-used header pins for
the wireless, I had to disable wireless functionality to make the
emulator work. So all it does is allow the image David has made to boot.

It would probably not do much for your BeagleBone Black Wireless,
especially if you are expecting to use the wireless functionality.

The work I put aside might be a jumpstart in updating the image to the
newer images, though.

-Joan

[Steven Hirsch]

I added these to uEnv.txt:

uboot_overlay_addr0=/lib/firmware/emu-00A0.dtbo
disable_uboot_overlay_addr0=1

and commented out commands to the now-nonexistent slots file.

if [ -e /sys/devices/platform/bone_capemgr/slots ]
then
CAPE=/sys/devices/platform/bone_capemgr/slots
else
CAPE=/sys/devices/bone_capemgr.*/slots
# Enable A/D
#echo cape-bone-iio > $CAPE
fi
# echo emu:00A0 > $CAPE

I'm getting bit further. mfm_emu segfaults when started by systemd at
boot, but if I try again manually it appears to run (haven't tried it in
the client machine yet).

But, I really need it to start automatically! Looks like the overlay is
getting brought in too early in the boot process and I'm not sure what to
do about that.

Steve


--

[Steven Hirsch]

On Fri, 23 Apr 2021, Joan Touzet wrote:

> Hi Steve, sorry about the confusion.
>
> The changes I made make the BeagleBone *Green* Wireless (BBGW) work with
> the MFM Emulator (MFME) cape. Because the BBGW re-used header pins for
> the wireless, I had to disable wireless functionality to make the
> emulator work. So all it does is allow the image David has made to boot.
>
> It would probably not do much for your BeagleBone Black Wireless,
> especially if you are expecting to use the wireless functionality.

Oh, blast. Sounds like a fundamental incompatibility between mfmemu and
the wireless. That really hoses me, since I purchased this specifically
to allow the emulator to be used remotely.

> The work I put aside might be a jumpstart in updating the image to the
> newer images, though.

If the pin assignments are not compatible then I'm not sure what more can
be done without hardware redesign.

And, I cannot find any coherent explanation of the new cape manager
approach. There are plenty of writeups, but they all assume a level of
familiarity that I lack.

That was a good waste of $90...

Steve

> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/fde3851b-da64-9b26-f8d5-baafb95557dc%40gmail.com.
>

--

[Joan Touzet]

On 23/04/2021 14:34, Steven Hirsch wrote:
> On Fri, 23 Apr 2021, Joan Touzet wrote:
>
>> Hi Steve, sorry about the confusion.
>>
>> The changes I made make the BeagleBone *Green* Wireless (BBGW) work with
>> the MFM Emulator (MFME) cape. Because the BBGW re-used header pins for
>> the wireless, I had to disable wireless functionality to make the
>> emulator work. So all it does is allow the image David has made to boot.
>>
>> It would probably not do much for your BeagleBone Black Wireless,
>> especially if you are expecting to use the wireless functionality.
>
> Oh, blast.  Sounds like a fundamental incompatibility between mfmemu and
> the wireless.  That really hoses me, since I purchased this specifically
> to allow the emulator to be used remotely.

On the *Green*, yes. I believe the *Black* doesn't reuse cape header
pins. You'll want to check that.

>> The work I put aside might be a jumpstart in updating the image to the
>> newer images, though.
>
> If the pin assignments are not compatible then I'm not sure what more
> can be done without hardware redesign.
>
> And, I cannot find any coherent explanation of the new cape manager
> approach.  There are plenty of writeups, but they all assume a level of
> familiarity that I lack.

It took me a few days to wrap my head around things. You're on the right
track in your other email with uEnv.txt, but I think you need:

dtb_overlay=/boot/dtbs/mfm-emu-00C0.dtbo

instead of uboot_overlay_addr0, and you want -00C0 unless you have an
old RevA one.

Further you need to restructure the device tree overlay .dts file for
the newer kernel support, you can't just put the old 3.18 kernel one in
place and expect it to work. I rewrote the one I had to use the C
preprocessor to avoid having to maintain multiple files for each
revision, but I never did get it 100% working correctly. The commands I
used were:

cpp -nostdinc -I/opt/source/bb.org-overlays/include -I. -undef -D__DTS__
-DREVC -x assembler-with-cpp -o .bb-mfm-emu-00C0.dtbo.dts.tmp mfm-emu.dts

dtc -O dtb -o mfm-emu-00C0.dtbo -b 0 -@ -Wno-unit_address_vs_reg
-Wno-chosen_node_is_root -Wno-alias_paths
-Wno-avoid_unnecessary_addr_size .bb-mfm-emu-00C0.dtbo.dts.tmp
rm .bb-mfm-emu-00C0*.tmp

[Steven Hirsch]

On Fri, 23 Apr 2021, Joan Touzet wrote:

>> Oh, blast.  Sounds like a fundamental incompatibility between mfmemu and
>> the wireless.  That really hoses me, since I purchased this specifically
>> to allow the emulator to be used remotely.

> On the *Green*, yes. I believe the *Black* doesn't reuse cape header
> pins. You'll want to check that.

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.

> It took me a few days to wrap my head around things. You're on the right
> track in your other email with uEnv.txt, but I think you need:
>
> dtb_overlay=/boot/dtbs/mfm-emu-00C0.dtbo
>
> instead of uboot_overlay_addr0, and you want -00C0 unless you have an
> old RevA one.

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).

> Further you need to restructure the device tree overlay .dts file for
> the newer kernel support, you can't just put the old 3.18 kernel one in
> place and expect it to work. I rewrote the one I had to use the C
> preprocessor to avoid having to maintain multiple files for each
> revision, but I never did get it 100% working correctly. The commands I
> used were:

> cpp -nostdinc -I/opt/source/bb.org-overlays/include -I. -undef -D__DTS__
> -DREVC -x assembler-with-cpp -o .bb-mfm-emu-00C0.dtbo.dts.tmp mfm-emu.dts

> dtc -O dtb -o mfm-emu-00C0.dtbo -b 0 -@ -Wno-unit_address_vs_reg
> -Wno-chosen_node_is_root -Wno-alias_paths
> -Wno-avoid_unnecessary_addr_size .bb-mfm-emu-00C0.dtbo.dts.tmp
> rm .bb-mfm-emu-00C0*.tmp

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.

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.

Steve

> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/951151dc-9189-b592-2604-53d438ab18da%40gmail.com.
>

--

[Joan Touzet]

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

[David Gesswein]

On Fri, Apr 23, 2021 at 06:50:51PM -0400, Steven Hirsch wrote:
> On Fri, 23 Apr 2021, Joan Touzet wrote:
>
> > > Oh, blast.  Sounds like a fundamental incompatibility between mfmemu and
> > > the wireless.  That really hoses me, since I purchased this specifically
> > > to allow the emulator to be used remotely.
>
> > On the *Green*, yes. I believe the *Black* doesn't reuse cape header
> > pins. You'll want to check that.
>
> 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.
>

I took a quick peek at the black schematic and it looks like they aren't
shared.

I had tried to update the image a while ago after they added
back support for UIO. I think I got it so my code loaded and possible mfm_read
worked but mfm_emu didn't. The DMA I used wouldn't work properly.
At that point I decided the benefit of newer image wasn't worth the trouble.
Its now too old to be useful other than possible seeing what I did.
Dec 25 2016 BBB-mfm-emu-4.x_8gig.xz

Attached are my notes on the update attempt.

If you get an image working other than the emu DMA I can see if I can take
another shot at getting DMA working assuming I can load it on a non wireless
board.

I did get my existing image working with a USB wireless device a long time ago.
Only some wireless USB were supported then. No idea on if any currently sold
ones work.

Rev B & C are in silkscreen on the board. Rev A doesn't seem to be labled.
A & B use one device tree file and C another. Current code support all
revisions.

[Steven Hirsch]

On Fri, 23 Apr 2021, David Gesswein wrote:

> I took a quick peek at the black schematic and it looks like they aren't
> shared.
>
> I had tried to update the image a while ago after they added
> back support for UIO. I think I got it so my code loaded and possible mfm_read
> worked but mfm_emu didn't. The DMA I used wouldn't work properly.
> At that point I decided the benefit of newer image wasn't worth the trouble.
> Its now too old to be useful other than possible seeing what I did.
> Dec 25 2016 BBB-mfm-emu-4.x_8gig.xz
>
> Attached are my notes on the update attempt.
>
> If you get an image working other than the emu DMA I can see if I can take
> another shot at getting DMA working assuming I can load it on a non wireless
> board.
>
> I did get my existing image working with a USB wireless device a long time ago.
> Only some wireless USB were supported then. No idea on if any currently sold
> ones work.
>
> Rev B & C are in silkscreen on the board. Rev A doesn't seem to be labled.
> A & B use one device tree file and C another. Current code support all
> revisions.

This particular emu is a Rev. A that I built with one of your earliest
boards (has EC wires and resistor soldered on the rear).

What is the newest debian version that works with the existing software?
I'm hoping there's an intersection between being new enough to supply the
Wifi and old enough to cooperate with the mfm setup script and overlay.

Steve


--

[Joan Touzet]

The last 7.x image from beaglebone.org, patched with the latest kernel
from the repo I linked, should do it. You'll need to pick the right dto
for uboot for the board you're running.

[David Gesswein]

On Fri, Apr 23, 2021 at 08:21:54PM -0400, Steven Hirsch wrote:
>
> What is the newest debian version that works with the existing software? I'm
> hoping there's an intersection between being new enough to supply the Wifi
> and old enough to cooperate with the mfm setup script and overlay.
>

Don't know. Would need to be 3.8 kernel.

The image I currently provide is
Linux beaglebone 3.8.13-bone81 #1 SMP Fri Oct 14 16:04:10 UTC 2016 armv7l GNU/Linux

[Steven Hirsch]

On Fri, 23 Apr 2021, Joan Touzet wrote:

> 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.

Glad it's not just me...

>> 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
> ```

I believe that's the best plan, yes. This particular installation has
some code modifications to fiddle start-time after index for Northstar HDD
emulation. For some reason, converting from a Northstar sector image to
emulation gets something wrong that requires a tweak to the emu code.
It's been a number of years, so the details are fuzzy. Probably easy
enough to find the diff.

>> 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

Oh.. no. So there truly is no intersection in this Venn diagram? The
kernel is either too old for reliable built-in wireless or too new to
support the emulation?

> 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.

You bring up an interesting point. At present, the BBB Wifi is useless
for this application. But, I have a Linksys USB<-->Ethernet adapter that
might at least allow me to use the BBB with an older kernel.

>> 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:

(snip)

Thanks. I would like to see that. David mentions a problem with DMA and
I assume this is for transfer between the CPU address space and PRU,
correct (again, been a while since I've been in the internals)?

Thanks to you and David for the input!

Steve


--

[David Gesswein]

On Fri, Apr 23, 2021 at 08:32:57PM -0400, Steven Hirsch wrote:
> Thanks. I would like to see that. David mentions a problem with DMA and I
> assume this is for transfer between the CPU address space and PRU, correct
> (again, been a while since I've been in the internals)?
>

Correct. A track is 20k and the largest PRU memory is 12k so the PRU
pulls data from CPU memory as needed. Directly accessing CPU memory
has large latency tail which was causing problems.

[Steven Hirsch]

On Fri, 23 Apr 2021, Joan Touzet wrote:

> The last 7.x image from beaglebone.org, patched with the latest kernel
> from the repo I linked, should do it. You'll need to pick the right dto
> for uboot for the board you're running.

According to the Google machine, Debian Jessie (8.x) uses a 3.8 kernel.
Would that not work?

> --
> You received this message because you are subscribed to a topic in the Google Groups "MFM Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/mfm-discuss/7KdKseKvHTI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to mfm-discuss...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/f799b131-fb58-a651-0019-4309bc372e39%40gmail.com.
>

--

[David Gesswein]

On Fri, Apr 23, 2021 at 08:44:33PM -0400, Steven Hirsch wrote:
> On Fri, 23 Apr 2021, Joan Touzet wrote:
>
> > The last 7.x image from beaglebone.org, patched with the latest kernel
> > from the repo I linked, should do it. You'll need to pick the right dto
> > for uboot for the board you're running.
>
> According to the Google machine, Debian Jessie (8.x) uses a 3.8 kernel.
> Would that not work?
>

I don't think there is any good summary of changes so would just have to
try.

This is about what I did to make my image. I started with the small console
version.
http://www.pdp8online.com/mfm/revb/software_install.shtml