Support 5.10 kernel / Debian bullseye

[wohali]

Hi David,

The following changes make it possible to run a newer Linux kernel and Debian distribution on the BeagleBone Black, Green, and Green Wireless with the MFM Emulator cape.

Updating the image provides many advantages, including but not limited to: better USB device support (including USB and microSD card hotplug functionality, and newer wireless drivers), better desktop support (USB Ethernet and serial support under modern macOS, Windows and Linux), faster file system performance (I have measured a 30% speed increase using fio(1), modern versions of user utilities, updated SSL/SSH encryption ciphers/root certificates, etc.

The commits in this PR are structured to make the changes easier to understand, or to allow reversion of any specific change if requested. The overall changes include, roughly in order of commits in this PR:

• The kernel-based cape manager is no longer available in Linux 4.x and forward. Instead, a proper MFM Emulator overlay now replaces it, one that supports runtime configuration using the universal overlay's pin-config command. This has the added advantage of allowing reconfiguration of the device as reader or emulator, without requiring a reboot.
• The overlay reserves the expected DMA channel and associated PaRAM blocks to prevent conflicts with Linux's eDMA driver.
• DCHMAP_# is no longer set correctly by the system for the expected DMA/PaRAM blocks. PRU initialisation code has been updated to include initialisation. These changes are backwards-compatible, effectively acting as a NOP on startup, and have been verified under the existing (3.8-based) image.
• The setup_emu and setup_mfm_read scripts have been updated to support both the original 3.8.x release as well as newer kernels. For newer kernels, .bbio files are provided that configure the pin matrix appropriately. These scripts also correctly set all pins such that switching modes without a reboot is supported on BBB and BBG.
• A write barrier is added to pru_write_word to handle the gcc -Ofast option, which in turn enables -fallow-store-data-races, thus no longer ensuring the write ordering as expected in pru_exec_cmd of PRU0_CMD_DATA prior to PRU0_CMD. This would occasionally prevent mfm_read from correctly advancing from RPM detection to drive seek, as the PRU_CMD would be written before the parameter, forcing the PRU incorrectly to seek hundreds of thousands of cylinders. (This can sometimes be seen as an unusually long delay in buffered seek testing.)
• The cape device tree overlay is enhanced to support to mmap(2) the shared DDR memory without requiring root access. This takes advantage of the Linux Kernel Userspace I/O driver and udev(7) rules to creates a new device at /dev/uio/prcm on boot and set permissions accordingly. Additionally the cap_sys_nice=eip capabiliity is set on the mfm_emu binary at build time to allow re-nicing threads to the real time priority.
• A bug fix to powerfail is made to prevent a boot loop should emulation-on-boot be enabled, and the BB is powered, but the cape is not powered (e.g., if the BB powered by mini/micro-USB).
• A new, optional --sync flag is added to mfm_emu; when specified, this sets O_DSYNC on the emulation file, requiring all write operations to the file to complete a full data write (as if a call to fdatasync(2) follows every call to write(2) to hardware before returning success. This is intended for future experimentation, though early tests show no appreciable performance penalty under moderate load.
• Finally, the util/ subdirectory includes the necessary files and support to compile and install the overlay, mandatory modprobe(8) options, udev(7) settings for the UIO devices, and a Debian-specific script to ensure the overlay is rebuilt and installed after any kernel updates via the apt(8) subsystem.

A microSD card image based on the official BeagleBoard Debian image with these changes applied is available for testing here:

https://archive.decromancer.ca/mfm/bb_mfm_bullseye_2023-07-11.dd.xz

To test:

• Burn this image (using dd, Balena Etcher, etc.) to a 4GB or larger microSD card, and insert it into a BBB/BBG/BBGW.
• Hold the User button down while powering up. This requires using a chopstick, pencil, or other non-conductive rod to hold the button down while applying power. The button can be released after all 4 LEDs light, then extinguish.
• Login to the image is debian with password temppwd. (Root remote login is disabled by default.)
• The software resides in /opt/mfm (so, /opt/mfm/emu/mfm_emu or /opt/mfm/mfm/mfm_read).
• Run the programs as the debian user; root access is no longer necessary.

This image has been tested by a few people using real hardware, including a PDP-11/23 (RQDX3), an IRIS 2400, and a TI Explorer (custom MFM-SCSI bridge). So far, there are no issues, and performance is improved in some cases.

Please let me know if you have any questions or would like any changes.

[dgesswein]

What is the purpose of this change? I don't see pin 15 used and 14 is used. Also 15 isn't in exclusive-use section but 14 is. mfm/mfm_read-00C0.dts.

Did you find any real documentation on config-pin? Trying to understand your .bbio files. Has similar pin 15 usage.

For setup_mfm_read did they get rid of the ability to set direction and level at the same time? echo high > /sys/class/gpio/gpio$pin/direction

What was the purpose of adding pins_out to set to output without setting level? pins_out="22 23" Are these your LED pins?

Who's initials should I put on for these changes to the log I keep at the top of each file?

[wohali]

Hi David, thanks for reviewing my pull request.

What is the purpose of this change? I don't see pin 15 used and 14 is used. Also 15 isn't in exclusive-use section but 14 is. mfm/mfm_read-00C0.dts.

The hex value you have there, 0x040, is actually P9_15, not P9_14. The comment is wrong.

I double checked by looking at the device tree/Linux kernel source. See include/dt-bindings/board/am335x-bone-pins.h:

#define P9_15(mode) AM33XX_IOPAD(0x0840, mode)  /* R13: gpmc_a0 */

You can also find this value using show-pins -vv or -vvv (I forget which). This utility is in the old and the new images both.

The additional 0x800 was previously automatically added in device trees; see am33xx.h:

#define AM335X_PIN_OFFSET_MIN           0x0800U

So the comment must have been wrong. I lost quite some time tracking this down! ;-)

Did you find any real documentation on config-pin? Trying to understand your .bbio files. Has similar pin 15 usage.

The original shell script-based config-pin is easier to read, since it has all of the pin modes hardcoded in it, but the rewrite in C is what's actually being maintained and shipped now. It determines the valid modes for each pin by querying the /sys tree, which in turn was populated by the device tree overlays loaded by U-Boot at system initialisation.

As an example:

https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v5.10.x-ti-unified/src/arm/am335x-bone-common-univ.dtsi#L402-L407 :

    /* P9_15 (ZCZ ball R13) gpmc_a0 (gpio1_16) */
    BONE_PIN(P9_15, default, P9_15(PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE7))
    BONE_PIN(P9_15, gpio, P9_15(PIN_OUTPUT | INPUT_EN | MUX_MODE7))
    BONE_PIN(P9_15, gpio_pu, P9_15(PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE7))
    BONE_PIN(P9_15, gpio_pd, P9_15(PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE7))
    BONE_PIN(P9_15, pwm, P9_15(PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE6))

The ALL-CAPS macros are defined in am33xx.h:

#define PULL_DISABLE        (1 << 3)
#define INPUT_EN        (1 << 5)
#define SLEWCTRL_SLOW       (1 << 6)
#define SLEWCTRL_FAST       0

...

#define PIN_OUTPUT      (PULL_DISABLE)
#define PIN_OUTPUT_PULLUP   (PULL_UP)
#define PIN_OUTPUT_PULLDOWN 0
#define PIN_INPUT       (INPUT_EN | PULL_DISABLE)
#define PIN_INPUT_PULLUP    (INPUT_EN | PULL_UP)
#define PIN_INPUT_PULLDOWN  (INPUT_EN)

and omap.h for the rest:

#define MUX_MODE0   0
#define MUX_MODE1   1
#define MUX_MODE2   2
#define MUX_MODE3   3
#define MUX_MODE4   4
#define MUX_MODE5   5
#define MUX_MODE6   6
#define MUX_MODE7   7

#define PULL_UP         (1 << 4)

The .bbio files are just a space delimited file of the form pin_name mode, where pin_name can be of the form P9_15 or P9.15, and modes must be a valid mode as specified in the device tree overlays. Most of these come from the universal overlay, and the mfm-specific ones from the contributed file.

Unfortunately, the new C-based version no longer supports setting the output high/low, see this thread for details.

For setup_mfm_read did they get rid of the ability to set direction and level at the same time? echo high > /sys/class/gpio/gpio$pin/direction

Yes, see the thread above; the official approach is to set direction first, then value. As of the 6.x kernel, we lose the ability to do this through /sys/class/gpio/*; we'll have to use libgpiod or similar.

What was the purpose of adding pins_out to set to output without setting level? pins_out="22 23" Are these your LED pins?

No, I didn't change any hardware at all in this exercise - same LED pins as always. If you scroll down in setup_mfm_read you'll see these feed into a for-loop used to set direction. I believe I did this to get around your "you must reboot between changing modes" check here, in drive.c.

Who's initials should I put on for these changes to the log I keep at the top of each file?

JST is fine, thank you. I wasn't sure if those were still being updated!

[dgesswein]

On Mon, Jul 31, 2023 at 10:19:59AM -0700, Joan Touzet wrote:

Hi David, thanks for reviewing my pull request.

What is the purpose of this change? I don't see pin 15 used and 14 is used. Also 15 isn't in exclusive-use section but 14 is. mfm/mfm_read-00C0.dts.

The hex value you have there, 0x040, is actually P9_15, not P9_14. The comment is wrong.

The schematic says that P9.14 is used and P9.15 isn't so its the hex value that was wrong and the comment was right. Looks like it really should be 0x048 0x0f // OUT P9_14 = gpio1_18

http://www.pdp8online.com/mfm/board/mfm_revc_pcb/pdf/top.pdf

Do you agree? If so your .bbio will also need to be updated.

Not that it seems to really matter. Assume GPIO is the default anyway.

Did you find any real documentation on config-pin? Trying to understand your .bbio files. Has similar pin 15 usage.

The original shell script-based config-pin is easier to read, since it has all of the pin modes hardcoded in it, but the rewrite in C is what's actually being maintained and shipped now. It determines the valid modes for each pin by querying the /sys tree, which in turn was populated by the device tree overlays loaded by U-Boot at system initialisation.

Unfortunately, the new C-based version no longer supports setting the output high/low, see this thread for details.

Ah, new and improved and less capapable. Now you can get a glitch on the pin.

Yes, see the thread above; the official approach is to set direction first, then value. As of the 6.x kernel, we lose the ability to do this through /sys/class/gpio/*; we'll have to use libgpiod or similar.

What was the purpose of adding pins_out to set to output without setting level? pins_out="22 23" Are these your LED pins?

No, I didn't change any hardware at all in this exercise - same LED pins as always. If you scroll down in setup_mfm_read you'll see these feed into a for-loop used to set direction. I believe I did this to get around your "you must reboot between changing modes" check here, in drive.c.

I had those in pins_low. Does it not work if they are still in pins_low?

I think the reboot was needed since for mfm_read some pins were configured as GPIO but for mfm_emu they were configured for PRU access. I didn't think it liked reloading the device tree but don't really remember what the issue was. Will need to do some testing.

[wohali]

HI David, this week has gotten away from me, not the least bit because I'm adopting a new cat. I'll hope to give this better attention over the next few days.

[dgesswein]

Hope your new cat is working out well.

I've merged your code and working on testing it. I noticed with your new OS image that if I unplug the Ethernet cable and plug it back in Ethernet doesn't come back (no lights). Do you see the same thing?

[wohali]

Hi David, sorry for the delay. The last two weeks both of my cats have been in the hospital and things have been rough here.

I have not seen that Ethernet behaviour, but will let you know.

I don't see this code on your master branch - do you mean you merged it locally?

[dgesswein]

On Fri, Sep 15, 2023 at 10:48:30PM -0700, Joan Touzet wrote:

Hi David, sorry for the delay. The last two weeks both of my cats have been in the hospital and things have been rough here.

Sorry to hear.

I don't see this code on your master branch - do you mean you merged it locally?

Correct. I do changes and testing locally then push.

[dgesswein]

ifconfig down and up manually gets the Ethernet going.

I noticed your image used much more of the flash than mine. I think you started with the normal image. I used the minimal. Do you know of anything in the full image that was useful to have over the minimal?

FYI: Systemd logs were taking 377M. I set in /etc/systemd/journald.conf SystemMaxUse=40M to reduce that.

[wohali]

I definitely used the minimal image, but had to install enough buildchain to be able to compile the kernel. Thanks for the info about systemd logs, was that the main culprit?

Systemd should have handled getting Ethernet running again, but that's interesting news. do you mean with the kernel patch that's supposed to allow the rev C boards to boot correctly? or something else?

[wohali]

The full image has X and so on, I'm pretty sure the image I used doesn't have any of that. If I'm wrong I apologise!

How do you intend to merge this code? If you're not going to be technically merging this PR should I close it? If I have changes to make should I update this PR or email you a diff? You can also edit this PR directly through GitHub if you prefer.

[dgesswein]

On Sat, Sep 16, 2023 at 08:33:06AM -0700, Joan Touzet wrote:

I definitely used the minimal image, but had to install enough buildchain to be able to compile the kernel. Thanks for the info about systemd logs, was that the main culprit?

No. My old image uses 18% of the flash. Your image was 5x% and after change is now 45% of the flash. Wasn't going to worry much about the size until after verifying everything looks good.

Systemd should have handled getting Ethernet running again, but that's interesting news. do you mean with the kernel patch that's supposed to allow the rev C boards to boot correctly? or something else?

This is just copying your image to a uSD card and booting it. Ethernet works if its plugged in at start or if you plug it in later but for me if I unplug it and plug it back in I need to manually bring it down and up for it to work again. Google didn't show people complaining about this so don't know. Haven't looked at it much.

The full image has X and so on, I'm pretty sure the image I used doesn't have any of that. If I'm wrong I apologise!

No its me that is wrong. I was just guessing based on size and what I remember when I last played with images. I don't see X.

How do you intend to merge this code? If you're not going to be technically merging this PR should I close it? If I have changes to make should I update this PR or email you a diff? You can also edit this PR directly through GitHub if you prefer.

I tend to do things more manually. I pulled down your code to a local copy and used meld to merge in each change while I looked at it. If their is any advantage for the history I can merge the pull request then drop my updates on top of it or we can close it.

I do the same for my updates. I work in a copy them merge back in to avoid accidental checking in changes I made for testing. Suspect their are better ways but this code is small enough that it doesn't really matter.

I did create a branch testing with my current code. When I finish testing I'll post here with why I changed some of your update.

-- Reply to this email directly or view it on GitHub: https://github.com/dgesswein/mfm/pull/40#issuecomment-1722254594 You are receiving this because you commented.

Message ID: @.***>

[dgesswein]

I reflashed my uSD card with your image without any changes. I then did debian@BeagleBone:~$ cd /opt/mfm/emu/ debian@BeagleBone:/opt/mfm/emu$ ./setup_emu Rev C Board ERROR: write() to /sys/devices/platform/ocp/ocp:P8_11_pinmux/state failed, No such device

What is the proper procedure to start the emulator on the new OS?

I had done a make install in util also but that didn't change anything. I didn't see in the makefile how MFM-EMU-1.dts gets used.

[dgesswein]

Ethernet issues is not the OS image. It reproduced with my image. Varied with switch and particular beaglebone on if it occurred. I'm always suspicious about no clean fluxes. Their is a lot of residue on the back of the board. I cleaned that off and issue went away. You can see it in attached picture. This isn't of the board I cleaned but looks similar. The other board I had the issue with stopped showing it. Will need to see if others do the same and cleaning also fixes them.

[wohali]

What is the proper procedure to start the emulator on the new OS?

I had done a make install in util also but that didn't change anything. I didn't see in the makefile how MFM-EMU-1.dts gets used.

Running make inside of util/ should copy the .dts over to the right place in the /boot hierarchy. You then need to ensure that is added staticly to /boot/uEnv.txt, check my image's version for the right syntax, I am away from my emulator at present.

Sorry to hear about your bad flux -- that can always be a concern.

[dgesswein]

I've reflashed various things but though I am back to the original configuration but now setup_emu is working. I hate when that happens.