Slow boot

[Tim Radde]

I bought a 2nd board from Decromancer and it's supposed to be based on Dave's board.  It's a rev D and is slightly different mainly in one cap instead of 5.  It does work but only if I power it from a separate PSU and it's fully booted.  It seems it takes way too long to fully boot to be seen by the system in question.  The first board I never saw this problem and it works fine with my Rainbow 100A.  This 2nd I was going to use with my Pro-350 to preserve the contents of the disk as they are prone to failing.  Is there any way to make this boot faster?  I have not timed it but it has to be over 1 minute.  Not sure if it makes a difference but the first one has a BeagleBoard Green, and the 2nd is a BeagleBoard black.  I plan to see what is taking up the most time to boot, but have not gotten to it yet.  Thanks for any info or suggestions.

[David Gesswein]

I had been shipping an old 7.11 Debian version of OS. Decromancer made a new
11.8 version for his use and provided it to me (thanks). The boot was
longer so I made some modifications and applied a kernel patch to get boot
time close to the old 7.11 version. Since my image is based on his image it may
work on his new board but I have not tested. We were trying to keep it
compatible. Updating kernel will lose the boot time fix.

https://www.pdp8online.com/mfm/revb/software.shtml

> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/d997c3ec-a4ea-4b29-978e-8c522d09a0bfn%40googlegroups.com.

[Joan Touzet]

Hi all, it's a holiday here today (Canadian Thanksgiving) so I wasn't going to get to

this until tomorrow. This is just a short update.

On Monday, October 14, 2024 at 2:14:10 p.m. UTC-4 David wrote:

I had been shipping an old 7.11 Debian version of OS. Decromancer made a new
11.8 version for his use and provided it to me (thanks).

 

You're welcome, David! It's she/her, if you please.

The boot was
longer so I made some modifications and applied a kernel patch to get boot

time close to the old 7.11 version. Since my image is based on her image it may
work on her new board but I have not tested. We were trying to keep it

compatible. Updating kernel will lose the boot time fix.

https://www.pdp8online.com/mfm/revb/software.shtml

Tim, you can get through your problem by enabling the supercap on the emulator,

powering the emulator via the PRO, having a failed PRO boot and giving the emulator

enough time to fully boot. Once the drive has full come up, power cycle your PRO-350.

The supercap on the emulator should give you 10-20 seconds of run time while the

PRO is off, without losing the contents of memory.

Tim, also check for a /boot/initrd.* file on the emulator. If this file exists, remove it.

This can speed up boot time by 10-15 seconds.

David, we ship with your image now, but it's possible the kernel auto-updated at

some point on our cached image. The post-kernel-install trigger script should be

update-able to remove the initrd.* file. Was there a separate patch beyond this for

boot performance? If so I can work with upstream to include it in the main BBB

distro.

Cheers,

Joan

[David Gesswein]

On Mon, Oct 14, 2024 at 12:04:44PM -0700, Joan Touzet wrote:
>
> You're welcome, David! It's she/her, if you please.
>

Sorry. Need to stop trusting memory and check things. Thanks for the polite
correction.

> David, we ship with your image now, but it's possible the kernel
> auto-updated at
> some point on our cached image. The post-kernel-install trigger script
> should be
> update-able to remove the initrd.* file. Was there a separate patch beyond
> this for
> boot performance? If so I can work with upstream to include it in the main
> BBB
> distro.
>

To see if its still my kernel
uname -a
Linux BeagleBone 5.10.168-ti-r74-djg #9 SMP PREEMPT Sat Dec 23 21:13:14 EST 2023 armv7l GNU/Linux

This is the patch I added to the kernel. I had to make some minor changes
to make it work with the different kernel version.

https://patchwork.kernel.org/project/linux-acpi/cover/20201121020232.908850-1-sa
rav...@google.com/#23791353

Wasn't in kernel back in December 2023 when we were working on the image.
Haven't checked since.

I can see about figuring out what kernel is current and check it if needed.

[Tim Radde]

On my board: uname -a reports

Linux BeagleBone 5.10.168-ti-r77.  So it's not your version but something a bit newer.  Don't know what changed.

It is slow to boot.  Removing the initrd.* in /boot made the boot process take about 1/2 of what it was taking.  It was

taking about 1.5 minutes to become pingable.  Seems way too long to me.  I will see  what kind of things I don't need

to boot and somehow disable those.  I can run from an external PSU and all works fine.  If I boot powered from the

Pro-350 it fails no matter what.  I tried the suggestion to boot and then wait for the MFM board to be ready.  Then

power off and on the Pro.   It still fails.  I also noticed 2 process running the powerfail code.  This seemed a bit odd

to me.

--
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/UDtfHe2VUZk/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/Zw3A2j7LAlRUBX11%40hugin3.

[Tim Radde]

More info.  I tried letting the Pro sit for quite some time after I have verified I could ping the MFM board.  It did not try to reboot.  It took about 1.5 minutes to boot

to being pingable.  I moved the one initrd file and that did shorten the boot time to maybe 30+ seconds.  I hadn't reset the stopwatch on my phone so I don't know

for sure.  I do see two processes for powerfail running with the exact same parameters.  Is this normal?  Making sure the MFM board was up and then restarting the

Pro also did not work.  Get the same error.  So something weird is happening.

On Mon, Oct 14, 2024 at 2:52 PM Tim Radde <timr...@gmail.com> wrote:

Thank you for these suggestions.  I am sure the forced reboot will work.  I already have the super-cap enabled.  I just did not expect the boot

to take longer than the Pro-350 waited.  I don't know if the Rainbow waits longer, but the earlier board works fine there.

--
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/UDtfHe2VUZk/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/13f57a3b-8636-4449-bf7f-8b7d949c6017n%40googlegroups.com.

[Joan Touzet]

HI all,

It's a holiday here today (Thanksgiving) and I was going to reply to this and Tim's email to

us directly then. This is just a quick update.

On Monday, October 14, 2024 at 2:14:10 p.m. UTC-4 d...@pdp8online.com wrote:

I had been shipping an old 7.11 Debian version of OS. Decromancer made a new
11.8 version for his use and provided it to me (thanks).

You're welcome! Except I am female, David. It's she/her.

 

The boot was
longer so I made some modifications and applied a kernel patch to get boot

time close to the old 7.11 version. Since my image is based on her image it may

work on his new board but I have not tested.

I believe we ship with your image now, but I will check when I'm back in the office tomorrow.

We received numerous requests to support newer wireless adapters, and the new

BeagleBone Blacks we ship with contain the fix for the dead-Ethernet bug (BBB rev C).

To make both of these work a newer kernel is required.

The 7.11 Debian version is not supported on the boards we ship. It may work, but we

don't test with it.

For boot times, you can power the Pro-350, let the boot fail and give the board a

minute to fully come up, then power cycle the Pro-350. The supercapacitor on the

board should give you 10-20 seconds of uptime, allowing the emulator to keep working

while the Pro is off.

 

We were trying to keep it
compatible. Updating kernel will lose the boot time fix.

https://www.pdp8online.com/mfm/revb/software.shtml

 

Tim, check for a /boot/initrd.* file on the BBB. If present, remove it and see if that

improves your boot time.

David, we can see if it's possible to add that modification to the post-kernel

install script. I thought I'd included it in my original PR to you? Unsure.

[Tim Radde]

Thank you for these suggestions.  I am sure the forced reboot will work.  I already have the super-cap enabled.  I just did not expect the boot

to take longer than the Pro-350 waited.  I don't know if the Rainbow waits longer, but the earlier board works fine there.

On Mon, Oct 14, 2024 at 2:04 PM Joan Touzet <decroma...@gmail.com> wrote:

--
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/UDtfHe2VUZk/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/13f57a3b-8636-4449-bf7f-8b7d949c6017n%40googlegroups.com.

[d...@pdp8online.com]

Google has improved groups to standard useless. It insists on a spam filter that is now catching half the messages. I only get notified after a day or two. I'll try the support group but just saw people complaining about it.

On this

For boot times, you can power the Pro-350, let the boot fail and give the board a

minute to fully come up, then power cycle the Pro-350. The supercapacitor on the

board should give you 10-20 seconds of uptime, allowing the emulator to keep working

while the Pro is off.

Won't when you power off the pro it trigger the auto powerdown? Or did you change how powerfail works? You can use --wait on the powerfail command to delay shutdown so you can do a quick power cycle.

On I also noticed 2 process running the powerfail code.

The powerfail program forks so you end up with two processes.

On It was taking about 1.5 minutes to become pingable.

The MFM emulator code starts quite a bit before the system is fully initialized. Best way to tell when MFM code is running is if the board has drive activity LED is to ground the drive select line and see how long it takes for the activity light to turn on.

Savings from my kernel is 6 seconds.

If I missed anything else I should have replied to let me know.

[Tim Radde]

By activity lights do you mean the blue leds?  I started it up and once up I ran "systemd-analyze time" to show how long it took to fully boot.

Results: 14.5 kernel time, 30.4 user time.  Total time: 44.99 seconds.  

My Linux box reports 15 seconds for the same command.  Wonder if something is waiting or failing?

It's even slow to just log in.  I ssh to it.  The prompt comes up fast but after entering password and hitting

return it takes about 5 seconds to actually get to the prompt. This seems odd.

[David Gesswein]

I don't have Decromancer board so not sure what the current LED's are.
I'm referring to LED's that show when the emulated drive is being accessed.

I tested my board with 11.8 OS and its 15 seconds from BBB power light
lighting to drive activity LED lighting when autostarting. On my board I
have LED's connected to J7. With old OS start time is 11 seconds.

For me logging in first time takes about 2.5 seconds to get prompt. Second
time is minimal delay.

This is a 10 year old ARM processor so not that fast and EMMC not too quick
either.

On Tue, Oct 15, 2024 at 08:38:16AM -0700, Tim Radde wrote:
> By activity lights do you mean the blue leds? I started it up and once up
> I ran "systemd-analyze time" to show how long it took to fully boot.
> Results: 14.5 kernel time, 30.4 user time. Total time: 44.99 seconds.
>
> My Linux box reports 15 seconds for the same command. Wonder if something
> is waiting or failing?
>
> It's even slow to just log in. I ssh to it. The prompt comes up fast but
> after entering password and hitting
> return it takes about 5 seconds to actually get to the prompt. This seems
> odd.
>
> On Tuesday, October 15, 2024 at 8:16:34 AM UTC-5 d...@pdp8online.com wrote:
>
> > Google has improved groups to standard useless. It insists on a spam
> > filter that is now catching half the messages. I only get notified after a
> > day or two. I'll try the support group but just saw people complaining
> > about it.
> >
> > On this
> >

> > *For boot times, you can power the Pro-350, let the boot fail and give the
> > board a*
> > *minute to fully come up, then power cycle the Pro-350. The supercapacitor
> > on the*
> > *board should give you 10-20 seconds of uptime, allowing the emulator to
> > keep working*
> > *while the Pro is off.*

> >
> > Won't when you power off the pro it trigger the auto powerdown? Or did you
> > change how powerfail works? You can use --wait on the powerfail command to
> > delay shutdown so you can do a quick power cycle.
> >

> > On *I also noticed 2 process running the powerfail code. *

> > The powerfail program forks so you end up with two processes.
> >
> >

> > On *It was taking about 1.5 minutes to become pingable.*

> > The MFM emulator code starts quite a bit before the system is fully
> > initialized. Best way to tell when MFM code is running is if the board has
> > drive activity LED is to ground the drive select line and see how long it
> > takes for the activity light to turn on.
> >
> > Savings from my kernel is 6 seconds.
> >
> > If I missed anything else I should have replied to let me know.
> >
> >
>

> --

> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/c9d24b5b-454a-42d7-adbd-46077e370aa2n%40googlegroups.com.

[Tim Radde]

I have a Rev C of your board.  I'd have bought another but could not find a link of where to order.  So I went

with this other that is supposed to be functionally equivalent to yours.  I see a DA0 and a DA1 that look like

they might be for LEDs but nothing is populated there.  I am assuming that DA stands for drive activity.

There's has tiny LEDs (at least I think they are) but have not checked for activity.  Just noticed they were

there but they are hidden by the 3d printed plastic holder I made some time ago.  Will look there.  I know these

are not super fast boards but yours works fine with my Rainbow.  This does not unless I power it separate and have

it powered on at least a minute.  I can leave it like this as it's not a huge issue but would prefer to see it work

as it's supposed to.

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/UDtfHe2VUZk/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/Zw7YRlSTLvuUlpW%2B%40hugin3.

[Joan Touzet]

HI Tim, David,

I have a Pro-350 here I can test with, I just need time to get it out of storage and into the lab for testing. That won't be for several days, I'm afraid - probably next week earliest. Your patience is appreciated!

DA0 and DA1 are identical to the drive activity LEDs on David's board. Our bracket gives you front-panel visibility to those lights.

As for the power-from-Pro-350-then-power-cycle option I mentioned over the long weekend, David's comment is wise: that would work only if you *disable* the powerfail command. If you do that, that should at least get you away from having to use an external power supply to run the emulator.

Once that's solved we just need to get boot times down, and I'll plan to allot an entire day to testing and optimisation next week.

Is that course of action acceptable to you both?

Thanks in advance,

Joan

[Tim Radde]

That's all fine with me.  I have plenty of other things to keep me busy.  And it's not really a problem to run this off an external PSU.  I don't have your bracket

as I had one from some time back that I printed from Thingiverse.  So it's very generic.  I had to cut the front opening a bit to make the Ethernet port fit.

It does not show the DA0 or DA1 as yours does.  I see the DA0 light comes on solid, but does not blink during access.  Once again take whatever time you

need.  I still have a PiDP-10 to finish assembling.

To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/20b8c8a2-323e-45ad-80e1-078d6a63a4c7n%40googlegroups.com.

[d...@pdp8online.com]

On I'd have bought another but could not find a link of where to order.

I don't have online ordering. As page said you need to email me.

On Is that course of action acceptable to you both?

Don't think your schedule is my call. Vintage computer stuff happens when it happens. Sounds like you have everything needed to properly investigate.

[Tim Radde]

Ah, then I am not sure where I got my first one.  I was pretty sure I got it from Decromancer too.  It's a Rev C board and

has a different Beaglebone in it as it's green.  That one works very well and is why I wanted another one.  I can make this

work so that's the main thing.

[Alison Telford]

Hi all --

I also run one of David's rev C boards in a Dec Rainbow -- timed things last night and it takes my unit about 55 seconds to respond to ssh commands from power-on (using wifi). It looks like I probably did an update at some point (I didn't realize it would kybosh David's mods), and am running the .77 bullseye. There are no iniitrd files in /boot. So I think Tim's timings are probably pretty normal for the unpatched startup configuration?

Anyway, I wanted to ask -- having (foolishly) updated my kernel, David, is there any way to reapply your mods to improve the startup, or should I reflash the emmc? (Ugh, have to remember how I got wifi working lol -- it was like a year ago, and of course I didn't make notes :)

Best wishes to all -- huge fan of Joan and David and the whole project!

Cheers, Alison

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/67d595ec-8173-4284-807d-1a1d7085a75dn%40googlegroups.com.

[Tim Radde]

My problem with the MFM board is with a DEC Pro-350.  The Rainbow works fine but maybe that is due to still having to boot from a floppy as my ROM does not

support booting directly from the hard drive.  I tried to used a FlashFloppy thing but I don't think it works with an RX50 as it does not support two drives of which 

an RX50 is.  I'd have to go back and boot it up to make sure though.  I'd love to not have to boot from a floppy drive.  I do not have any networking on the Rainbow

so don't know about SSH.  Did you use one of the dongle things that allows older computers that don't have network ability to connect?  So what do you run on

your Rainbow for OS?  I am curious as I would not think the Rainbow would even support SSH.

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/UDtfHe2VUZk/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/CAMB0cfY-zqf2duuB9WyP5Z7S3Nf8zpJFTafTHrkDxpHxAuhQ2A%40mail.gmail.com.

[Alison Telford]

Hi Tim -- apologies, I was unclear. I ssh onto my beaglebone, which has a wifi usb dongle installed. The beaglebone (and obviously the mfm controller) is installed in the center drive bay of my rainbow next to the rx50 drives.

I have used a flashfloppy on the 100 in the past, connected to the second floppy ribbon connector on the controller card (the one that controls C and D drives). It works well, appearing as either C or D drive, depending on my gotek jumper settings. (I think I also needed to use a tweaked .CFG file to control how the flashfloppy presents itself to the system, e.g., as a "dec" drive)

In terms of floppy booting, on my 100A (my mfm is installed in a 100B), there's a very neat workaround using a program called BOOT31.CMD. What was done in the past is that you prepare a bootable CP/M disk with BOOT31.CMD installed, and using the AUTO utility (I can provide all of this if you want -- took a little hunting online to find), the CPM floppy boots, then automatically invokes BOOT31 to boot the hard drive from whichever partition you want. It's a little slower than a 100B firmware hard drive boot, but allows a bootup straight from the startup ROM menu into your harddrive. If you put that CPM bootable image on a flashfloppy, it would be pretty quick I think (I use a physical RX50 disk right now).

I also wanted to mention that if you're using a 100A, I asked the question on VCF forums a while ago if there was any way to increase memory above 256K. Turns out, there are a lot of brilliant people out there and a fellow in Italy reverse engineered a card from the 80s called the Rambow that allows almost 1mb of available memory on the 100A. It works wonderfully. Between that and the AUTO/BOOT31, my 100A is very close to a 100B in usability.

It's also interesting you ask about networking. This is why my 100 is out right now -- I ran across some posts about internet serial modems a while ago, and then a video by Michael Brutman (theoldnet) showing how to use one such modem as a SLIP adapter. This all works perfectly on an IBM PC, connecting to the internet via a serial port. Plus the source code is available for the SLIP driver. So I wondered, if we can change the slip driver code to work with the Rainbow's very different serial port, can we get SLIP on a rainbow? I'm working on this project now -- I may not have the brains to pull it off, but I'm having fun learning more assembly and digging into how the Rainbow's serial controller works :)

ANYWAY, wayyyyy off topic, but let me know if you'd like me to share any of these resources, happy to do so. You can just email me at alison....@gmail.com if you want to take this part of the discussion offline.

Cheers! Alison

To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/CABTODK9MLdXoXJ022t6KFcbw7EWQabbcb5A6V8E9DaMDbHcHXA%40mail.gmail.com.

[Alison Telford]

Just re-reading my post -- to clarify further, BOOT31 transfers the boot process from the CPM disk to the boot sector of the hard drive partition, so you are booting cleanly into whatever operating system you have installed on the given partition. So the initial floppy CPM boot is transient, operating more like firmware bootstrap code.

[Tim Radde]

I just booted my Rainbow to make sure it still works.  I don't seem to have a proper power cable to boot with the Flashfloppy on this machine as it's on a different machine.

Pretty sure it complained, but maybe I will have to steal this power cable to try.  I never seem to have enough cables.  Yes, I would be interested in how you were able to boot

using CP/M or whatever.  I have DOS on the HD of the Rainbow.  I do not know how much memory my Rainbow has but it does have an expansion card for RAM.  It's a decently

loaded Rainbow.  I am not really an expert with the Rainbow so I don't even know how to check available memory.

To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/CAMB0cfbdkBzPH74qMqx21KG66f6DPUmdusJfPaBiqOJBzjHz6Q%40mail.gmail.com.

[Tim Radde]

I ran chkdsk (seemed I remembered it might display memory size).  It report 850k of memory.

[Tim Radde]

I have one of the "thisoldnet" serial wifi adaptors.  I have not tried it on the Rainbow yet.  Pretty sure I have to reflash it as I was trying to make it

work with something else.  Don't know if it will work with the Rainbow or not.

[Alison Telford]

Hi Tim -- re the RAM in your 100A, wow, fantastic! That must be one of DEC's original super-expansion cards (or even an original RAMBow lol). Those are, from my experience anyway, almost unobtainium. Nice score! :)

Re cables, I KNOW lol -- I never have enough of the specific kind I need, despite amazon and thrift store pillaging.

Not wanting to hijack this thread any further, I can send you the auto/boot and flashfloppy items I have to your gmail account directly, if that's ok?

Cheers, Alison

To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/cd2ec7e2-2580-4dbf-b8f1-c57722eb23a8n%40googlegroups.com.

[David Gesswein]

On Wed, Oct 16, 2024 at 09:17:03AM -0400, Alison Telford wrote:
> Hi all --

>
> Anyway, I wanted to ask -- having (foolishly) updated my kernel, David, is
> there any way to reapply your mods to improve the startup, or should I
> reflash the emmc? (Ugh, have to remember how I got wifi working lol -- it
> was like a year ago, and of course I didn't make notes :)
>

Should be possible.

First check to see if it deleted the old kernel.

Does /lib/modules/ have 5.10.168-ti-r74-djg
also /boot/System.map-5.10.168-ti-r74-djg /boot/vmlinuz-5.10.168-ti-r74-djg

If so in /boot/uEnv.txt set
uname_r=5.10.168-ti-r74-djg

Otherwise would need to copy those back from my image.

Needed also depmod -a after booting

[Alison Telford]

Hi David -- thank you for this! It looks like I have 5.10.168-ti-r71  as the OS installed on my emmc prior to r77. I followed your instructions and reverted to that one, which worked.

uname -a now shows Linux BeagleBone 5.10.168-ti-r71 #1bullseye SMP PREEMPT Fri Sep 1 04:05:07 UTC 2023 armv7l GNU/Linux

I also ran sudo depmod -a, which completed without error.

I'm not seeing a speed improvement -- I'm thinking I should simply reflash to r74? I'm a bit leery to do so, recalling that getting my wifi to work was a bear. In the end for wifi I believe I got it working with .conf entries in /etc/wpa_supplicant ( rather than in /etc/network/interfaces or /interfaces.d -- perhaps I did something wrong? It does work, however)

Cheers and thank you! Alison

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

To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/ZxEZiJi4%2BGaFV5SA%40hugin3.

[Alison Telford]

Apologies, David, I forgot to ask: Once I've flashed the emmc (as I have), is there a way to "undo" that and get the beaglebone to boot from the sd card instead? It would be more convenient to have the os and data (and configuration) all on a removable sd card, which would let me swap out/upgrade etc without trashing my working OS. I recall originally I could not get the beaglebone to boot from the SD card, which is why I ended up using the flasher image.

Cheers, and apologies (and none of this is super urgent) A

[David Gesswein]

> uname -a now shows Linux BeagleBone 5.10.168-ti-r71 #1bullseye SMP PREEMPT

If it doesn't have djg in it its not my modified kernel.

On Thu, Oct 17, 2024 at 01:30:04PM -0400, Alison Telford wrote:
> Apologies, David, I forgot to ask: Once I've flashed the emmc (as I have),
> is there a way to "undo" that and get the beaglebone to boot from the sd
> card instead? It would be more convenient to have the os and data (and
> configuration) all on a removable sd card, which would let me swap
> out/upgrade etc without trashing my working OS. I recall originally I could
> not get the beaglebone to boot from the SD card, which is why I ended up
> using the flasher image.
>

Put this on a uSD card and it should boot off of it.
New OS bootable image BBB-mfm-emu-v4.20-OS-11.8-r74.img.xz (last modified Thursday, 21-Mar-2024 17:56:47 EDT )
https://www.pdp8online.com/mfm/revb/software.shtml

[Joan Touzet]

Alison,

For the moment, I would recommend against flashing David's image with our Rev D "cape" boards. Feel free to experiment with his image on a microSD card!.

I confirmed this morning that our image has additional configuration and modifications in it, and yes, does not have David's kernel at this time.

I contacted Robert Nelson (Beaglebone SW maintainer, upstream) and he is looking into taking the kernel patches David found into the BB base image.

Assuming that happens quickly, you should just be able to "apt update && apt upgrade" to get the updated kernel.

If for whatever reason that falls through, the additional repositories we maintain, and that are configured in the Decromancer image (but not David's) can be used to push the updated kernel to you and can be configured to override the kernel being provided by the default BeagleBone repository. We'll take these steps if necessary soon.

[Alison Telford]

Hi Joan -- apologies, I wasn't really clear. I waded into the discussion because I found that my rev C board (I purchased the pcb from David) was similarly slow to boot as Tim's Decromancer rev D. In my case, it's entirely my fault, as I performed an update of the OS after installation (I wasn't aware it would break David's mods).

In my case, it's not a big deal, but I will go ahead and see if I can get a David-modded version back on my board (just waiting for fresh sd cards :)

Cheers and thank you! Alison

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

To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/553c98aa-e67a-4bd3-b07b-28be04f7da02n%40googlegroups.com.

[Alison Telford]

Hi all -- fyi I prepared a fresh sd card with r74, got the wifi working (wpa_supplicant), and wow, spectacular startup speed. I enabled the power-on mfm-emu service and the drive is accessible pretty much by the time the rainbow has finished self-testing. Very nice!

Thanks everyone for all of the pointers and great help as usual!

Cheers, Alison