Thanks to bigfoot's help, MorphOS can now be installed on the SAM460LE board.
First, I installed on a HDD drive and everything works great, as expected :)

However, I wanted to set up a dual boot option for AmigaOS and MorphOS.

I installed AOS4.1 on the HDD drive with 3 partitions:
Two SFS2 partitions DH2"AmigaOS", DH3"AOS Data" and one SFS0 partition DH4"Shared Data" to be accessable in MorphOS as well.

Then I installed MorphOS on SD card with standard settings, so it created DH0"System" and DH1"Work" partitions on SD card.

Both systems boot fine. In MorphOS however, the system freezes when copying files to the SD card (some random freezes occur, too). It does not freeze when copying files to the HDD's "Shared Data" partition!
I already tried to install MorphOS on a different SD card, same issue...

Any ideas?

Quote:
Have you considered that this could potentially also be related to the card reader?

Quote:
Yes, but you won't like it: Don't use an SD card as your system disk.

The main issue with SD cards is that writing many small files can be unbearably slow even if the SD card performs well when copying large files. Putting Wayfarer's browser cache on an SD card would likely be a recipe for disaster, for example.

Writing on SD card in AmigaOS works fine, so the card reader is technically ok.
I am totally happy with SD card performance for a modest system like MorphOS. Browser cache can be put on my Shared Data HDD partition, for example.

Any ideas why Morphos is crashing?

> Browser cache can be put on my Shared Data HDD partition, for example.

...or to RAM:, as well as the cookies database as of v5.0 :-)

It is possible that the USB port on your SAM isn't quite supplying enough power for the card reader, which would explain these kind of freezes. However, that wouldn't explain why it works on OS4.

I've had issues with MorphOS FFS in the past on removeable devices, such as floppy, but it was many years ago (who uses floppy now?), and the system is still technically seeing your reader as a fixed disk.

Quote:
Yes, but there could be a driver issue. My point was that trying different card readers may help to narrow down the problem. Simply trying different SD cards may not be enough.


Quote:
Have you tried copying files via shell/CLI instead? Do you still experience issues?

The main issue is the flash segmentation. When using SD cards e.g. inside a Raspberry Pi, they are under stress by linux reading/writing constantly, BUT linux is aware of the physical flash segmentation and reports unused areas back to the internal controller.

MorphOS has currently no flash aware file system.

Which means EVERY small write access will cause a huge write. So when installation is writing a small 4K file the smart file system when used in 512 Byte mode, will write 4096/512 times and the SD card will clear and rewrite 16k, 32k, 64k or even 128k and even more flash memory for EACH block. In addition MorphOS is not aware of block alignment. So the 4K write may even write over the boundaries of two flash blocks. Even the installer installs an RDB or mac boot sector without flash matching alignment. So a partition may start at 4K of an 8K flash block, so the boot sector gets reflashed every time the beginning of the partition gets flashed.

This will wear flash memory very fast. The smaller the card is the higher the speed of degradation. Especially cheap cards do not very well handle wear management.

You often read to leave a good amount of an SSD untouched, when dealing with legacy systems. This is the reason. Untouched space means the flash controller knows it can use them as spare blocks. If an e.g. format is clearing the blocks, those spare blocks are considered as in use, so the controller is not switching to them, but internally moving data around to keep the data intact, when sections start failing.

In addition you should be aware that flash memory also degrades on reading. Once in a while the internal controller will reflash the internal blocks due to electron leakage, which is also the reason flash memory is bad for backups, as it will loose memory over time, when not at least powered once in a while.

That is why proper SSD are working longer without issues on MorphOS under the same harsh condition. 2.5" SSDs are usually bigger, have proper chips with proper ram write cache and a reasonable amount of spare blocks, when wear management detects an error. They even have fully implemented s.m.a.r.t. support, so you can read the health of the SSD. Even USB sticks are more feasible than SD Cards.

So even so it is possible, avoid writing SD cards constantly using MorphOS. Install the OS and put your data else where. Format your file system with a block size of at least 4096 bytes to reduce the damage caused by file fragmentation. If a file needs less blocks it needs less writes to be stored.

Not sure if AmigaOS has an flash aware file system, but I don't think so.

Is there any particular reason you don't just install MorphOS on the hard disk?

@geit: Thank you very much for your explanation. Very interesting, it makes now sense why the RPi's perform well on SD card.

@bigfoot: Since the bootloaders don't mutually support AmigaOS and MorphOS, there is a blog showing this "convenient" way to boot both OS on the SAM460.
I thought, if only the lightweight OS and it's standard tools are on SD card and I use my SFS0 HDD partition for everything else, everything will perform nice. I wasn't expecting those freezes!

So in deed, the best answer to my problem would be to show me a way how to boot multiple OS from one single HDD drive.
But still, I would like to know why the system freezes so hard...

Quote:

Well, just goes to show that you shouldn't trust everything you read on the internet :P

The design of this whole Amiga OS 4-U-Boot boot system is indeed a giant mess, but that's a rant for another time.

MorphOS' U-Boot bootloader supports chain-loading the Amiga OS 4 bootloader from a file on the installed system, although this has only ever been tested on the X5000, as I don't have a copy of Amiga OS 4 for the Sam460. The path to the file should be :l/slb_v2. MorphOS' U-Boot bootloader supports FFS and SFS, so it has to be one of those two filesystems. Also due to limitations in Amiga OS 4, Amiga OS 4 has to have the highest boot priority, and thus be the default, for this to work.

Alternatively you can load just the MorphOS bootloader off an SD card, but then use the boot device selector to choose to boot off a partition with MorphOS installed on it.

This sound great. I will test and report back.

>> Since the bootloaders don't mutually support AmigaOS and MorphOS, there
>> is a blog showing this "convenient" way to boot both OS on the SAM460.

> just goes to show that you shouldn't trust everything you read on the internet :P

Apart from that blog, he may have come across that thread where the thread opener failed to run both MorphOS and OS4 from the same drive. It wasn't resolved back then, and the thread opener then resorted to not even using different drives on the same X5000, but to using each OS on its own X5000 ;-)

So, simply copying the AmigaOS bootloader to :L doesn't trigger the hyperbootloader to chain-load it.
Is there a way to configure the MorphOS bootloader? I looked in the HDConfig tool (the edit bootloader option sounds promising) but found nothing helpful.

[ Edited by Skygecko 03.08.2023 - 14:16 ]

Quote:

Hyperbootloader automatically lists all found RDB partitions that are marked as bootable and don't have the do not mount flag set, and which use a supported filesystem (ie, FFS (DOS3 and DOS7) or SFS (SFS\0)) as options to boot from. No configuration is necessary.

If Hyperbootloader doesn't list the partition containing :l/slb_v2. as a boot option, then it is either on a partition using an unsupported filesystem, the partition is not marked as bootable, the partition is marked as do not mount or for one reason or another, the disk can't be read by U-Boot at all, with the latter option being unlikely.

When Hyperbootloader lists your boot options, press the key on your keyboard corresponding to the partition you want to boot from. Here's the output of Hyperbootloader on my system here:

Code:

By default it will boot from DH0:, but if I want it to boot from DH1: instead, I have to press the 2 key on the keyboard when presented with this prompt.

It finally works :) Now I have DH0 for MorphOS, DH1 as a shared data partition and DH2 for AmigaOS on my HDD.
Thank you very much for all your help and explanations!

Glad to hear you got it working and confirming that it also works on the Sam460!

I just playing with my Sam460LE and three operating systems. I have question about bootloaders:

Are Hyperbootloader ( installed by MOS ) and slb_v2 ( installed by AOS ) installed on the same disk block(s)? I.e. are they mutually exclusive?
And can I simply overwrite slb_v2 with hyperbootloader and vice versa?

It SHOULD be this way, but I want to be sure, so excuse my a little stupid question


[ Edited by sailor 06.11.2024 - 09:28 ]

Don't simply overwrite slb_v2 with hyperbootloader since only slb_v2 can boot AOS4.
AOS should be installed on a SFS\00 partition/disk and the SAM460 needs to boot the MorphOS partition/disk first.
Hyperbootloader then simply lists all RDB partitions with compatible file systems (AOS on SFS\02 will not be found) so it can chainload slb_v2 on a SFS\00 partition to boot AOS4.

Quote:

Thanks, I know, I have it this way:
-SDcard: Hyperbootloader + SFS0 partition with L:slb_v2 + Kickstart/*
-SATA: slb_v2 ( not needed in this scenario), SFS0 MorphOS partitions, SFS02 AmigaOS partitipns
everything is worked as expected:
boot from SD invoke Hyperbootloder menu, I can continue to MOS or AmigaOS-slb

But I want to testing some configurations and also install linux, and want to install Hyperbootloader to SSD. And question is, if I overwrite Hyper again with slb, if there remains something somewhere, or is it OK. I.e. if slb and hyper occupy exactly the same place on disk...

They should, but I want to be sure.