I have to go back to AmigaONE again. I had a problem with the latest kernel released for Linux. Even though I've solved it now. As I had already mentioned previously. I still can't compile the version of qemu on the official site.
So I continue to compile from the "balaton" channel and everything works.
So I'll be back to try AmigaONE again.
I also noticed that using the SSD with AmigaOS there are some problems.
In practice, if I create both the "ext4" partition and the SFS partition dedicated to AmigaOS on the same SSD, for some reason it seems that the two filesystems create problems for the "partition table" If used on the same disc, but this is nothing new, it also happened a long time ago. Even with 3.xx somehow even if you format a partition previously used with SFS it creates problems. You need to completely recreate the "partition table" Otherwise SFS seems somehow "immune" to formatting. He continues to be present all the same.
Even after formatting with another filesystem. Maybe "joerg" could answer this.
simplified explanation format everything goes fine (ext4) but if I use qemu I use that partition AmigaOs is still present although it obviously shouldn't be like this because the partition has been formatted.
So the ideal use is to have 2 separate disks, one entirely dedicated to "Linux" and another only for "AmigaOS". In this case there will be no problems.
white wrote:@Maijestro Even after formatting with another filesystem. Maybe "joerg" could answer this.
simplified explanation format everything goes fine (ext4) but if I use qemu I use that partition AmigaOs is still present although it obviously shouldn't be like this because the partition has been formatted.
So the ideal use is to have 2 separate disks, one entirely dedicated to "Linux" and another only for "AmigaOS". In this case there will be no problems
And that's exactly what I did, I don't use a partition that I pass to Qemu, I use a complete real hard drive and it works really well.
It is a 500 GB SSD and also AmigaOs4.1 recognized it without problems.
The hard disk could probably be taken off and also a real Pegasos2 could boot it.
In practice, if I create both the "ext4" partition and the SFS partition dedicated to AmigaOS on the same SSD, for some reason it seems that the two filesystems create problems for the "partition table" If used on the same disc, but this is nothing new, it also happened a long time ago.
What kind of "partition table"? AmigaOS only supports RDB, but there is no AmigaOS ext4 filesystem port implemented as a kickstart module. Linux only supports MBR and GPT, not RDB. AFAIK the only exceptions are the AmigaOne/PPC and Amiga/m68k versions of Linux, which additionally support RDB.
Let me explain better but I repeat this has been happening for many years also with Workbench 3.1 but I had forgotten.
I use GParted Main partition "Linux ext4" Extended partition "left unformatted" or directly using the "Amiga" partition create function with Gparted" All perfect .
Well if I go to format the partition to make it go back to being an "ext4" partition everything will seem normal. But in reality the AmigaOS (SFS) system is always present even after formatting the partition with GParted again in "ext4" In practice, the only way to permanently delete AmigaOS from the disk is to recreate a new partition table in "ext4" of the entire disk.
"does not create new partition" but the disk must be completely reinitialized with a new "partition table"
but it's nothing important anyway.
but the proof is that if you try to move files it will tell you that the partition is full even though GParted clearly shows that the partition is empty because it has just been formatted.
@white It's hard to understand what you describe but if you are talking about a partition that was formatted as SFS and then you format it as ext4 and after that still can be mounted as SFS that may be because these file systems store their info block at different places so formatting ext4 does not overwrite it and SFS still thinks tha partition is SFS (but some data is overwritten by ext4 infos). The soulution is just to clear the blocks where SFS stores irs infos then format it with other file system. Not sure where that would be but probably zeroing first few dozen sectors of the partition should remove SFS blocks then it should not be detected as valid any more.
The soulution is just to clear the blocks where SFS stores irs infos then format it with other file system. Not sure where that would be but probably zeroing first few dozen sectors of the partition should remove SFS blocks then it should not be detected as valid any more.
The SFS root block is the fist block of the partition, but it additionally has a backup of it in the last block of the partition. If either one gets destroyed it can still work by using the other and restoring the damaged one.
But that doesn't explain the problem white has. If you change the file system (DOSType) of a partition from SFS\0 or SFS\2 in the RDB to LNX\0 (Linux partition, ext2/3/4fs), or any other file system, SFS wont even try to mount it nor access it in any other way. All AmigaOS file systems are only started on partitions with their own DOSTypes. If GParted doesn't support RDB but creates a MBR or GPT instead AmigaOS file systems can't mount the partitions at all, at least not automatically. You'd have to create and use a Mountlist/DOSDriver (similar to fstab on Unix) with exactly the same partition information manually instead, add the correct DOSType to it, which is missing non-Amiga partition tables like MBR, and of course manually update the DOSDriver with any changes done with a MBR or GPT partitioning tool.
I'll write it here if it might be found interesting by others too otherwise it's not important.
It's not interesting, it's nonsense. You're mixing up things without any sense and even if it did what you wanted it would not work because you cannot export a file system mounted on host to the guest and then mount it there becuase then host and guest would overwrite each other and break the file system. Besides that tmpfs and /dev/ram are different things: https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html https://www.kernel.org/doc/html/latest ... ide/blockdev/ramdisk.html and even if tmpfs were on /dev/ram you were trying to reformat that from guest with a different file system so no chance for this to do anything sensible.
I still can't compile the version of qemu on the official site.
So I continue to compile from the "balaton" channel and everything works.
What's your problem compiling QEMU master? I did not update the qmiga repo so that still has QEMU 8.1 and the old version of patches so to test the latest version you should apply the last version of the patch series from qemu-ppc list or patchew.org/QEMU on QEMU master.
Quote:
I also noticed that using the SSD with AmigaOS there are some problems. ... So the ideal use is to have 2 separate disks, one entirely dedicated to "Linux" and another only for "AmigaOS". In this case there will be no problems.
No idea what you're trying to do but if you export the disk to the guest (like /dev/sdb without a partition number) then host cannot use it any more because setting up partition table in AmigaOS will not be seen by host. Again you're overwriting stuff from host and guest which will cause they break each other's data. You can give a partition to guest and use that as a virtual harddisk like using /dev/sdb2 for example which should work. The setup in this case would be /dev/sdb is the whole disk partitioned on host and one partition on it /dev/sdb2 is given to AmigaOS which will use this partition as a harddisk so you put RDB on it and partition it further in AmigaOS and format those partitions but on the host it's just a single partition holding the image of a whole disk. I hope this was clear to you and it's not the problem you described.
II am not in the subject what do you want to do with the ramdisk , some kind of portable drive from the host ? mounting on host image "nbd0" - transferring data ?
You might find this useful - directory as usb drive. You don't have to play with ramdisks. It's not super fast, it's not perfect (can't see changes after booting into host folder, size 500MB ) but it works just fine.
You might find this useful - directory as usb drive. You don't have to play with ramdisks. It's not super fast, it's not perfect (can't see changes after booting into host folder, size 500MB ) but it works just fine.
I changed Linux distribution nothing in particular but I like it and I also don't have to disable the Nvidia Nouveau drivers because the distribution already has the drivers being installed. even if in the end there are just a few steps to do. And few things installed Ideal for me who only use it for qemu. I just had to add the packages to compile qemu including the annoying "meson"
And light and I notice that it is faster than "kali" Also now I can compile directly from the qemu master branch. Without mistakes.
Other than that the idea of creating a sharing directory was a simple additional option.
With the ramdisk configuration I thought it was possible to choose a "raw" filesystem but I couldn't find anything on the subject although there is certainly something out there to read.
Now qemu no longer gives the "floating point" error But if I try to initialize the ramdisk it tells me that it cannot initialize RDB "0"
It would also be fine in fat32 for sharing or some compatible format. But it doesn't matter it was just something more to add.
On the other hand, why not try it when it takes a few minutes to restore the Linux backup, it costs nothing and is fun
Thanks for all the suggestions.
Since I'm here I wanted to ask if "aiostrems" still works for you and twitchTV doesn't seem to work for me anymore. While YT.rexx works fine.
Sometimes it's simpler to use something like this. I download something quick, some files, an installation package from a site that Odyssey doesn't support . I add it to /tmp - I run QEMU and I have the file visible Host file in /tmp - it disappears after a reboot and I don't keep junk. For stored data surely smb or ftp,sftp ip is better
It's good to have different options and use the ones that suit you
I don't know if what follows is applicable to your observation but I thought I'd mention it in case it does.
The Amiga RDB can be located anywhere within the first few KB of a drive, can't remember if it's 4k, 32k or more, but when you configure the RDB in MediaToolbox you can choose where the RDB should be written (start block and size), and is automatically found, wherever it is, by kickstart or cfe/uboot.
So if your RDB start at block 2, and has an SFS partition listed in it, it wouldn't matter what you do in Parted, the RDB would still be there until you overwrite the RDB, presumably with data written to the first partition starting at block 2. I doubt linux would scan the entire disk and find the SFS partition, but rather finds and parses the RDB.
I use this feature extensively on external drives as it allows to share the same drive between x86 and Amiga by having an MBR on the first block, followed by the RDB, keeping the partitions hidden from each other.
That approach requires remembering not to create/start the first MBR partition before the end of the RDB blocks, and keeping track of which block is the border between the x86 and Amiga partitions to prevent overlapping partitions.
Technically you could even specify the otherwise invisible partitions of the other OS in both the MBR and RDB, but it's too easy to make a destructive mistake, not worth the risk on a backup drive.
II am not in the subject what do you want to do with the ramdisk , some kind of portable drive from the host ? mounting on host image "nbd0" - transferring data ?
You might find this useful - directory as usb drive. You don't have to play with ramdisks. It's not super fast, it's not perfect (can't see changes after booting into host folder, size 500MB ) but it works just fine.
Thanks for the information, I didn't know about such a solution it is perfect for fast file transfers from host to guest and works very well here. Thanks a lot
Qemu is like an open book and so extensive from the configuration but it is also more than that because it communicates with the real system and that is what makes it so exciting. You just have to understand how things are done and that's what makes it so complicated.
Yes. You just have to remember that the content of the directory should not exceed 500MB. QEMU will write out an error message.
Ok perfect there were always many questions how to copy files from host to guest system the fastest or easiest way.
Using network share folders would be one solution, but drive=ufat with the right line anyone could use it without having to do complicated network shares, even if the drive is limited to 500 MB. Thanks
The Amiga RDB can be located anywhere within the first few KB of a drive, can't remember if it's 4k, 32k or more
It has to be inside the first 16 sectors of the drive: #include <devices/hardblock.h>
#define RDB_LOCATION_LIMIT 16
In theory RDB supports any sector size which is a multiple of 256 bytes, but in practice nearly all AmigaOS device drivers are limited to multiples of 512 bytes/sector, and even worse MediaToolBox only supports exactely 512 bytes/sector. 16 * 512 bytes = 8 KB
I'm trying to debug a hang during boot that I can reproduce with QEMU amigaone machine while other machines (or Linux on this machine) boot fine. With kernel.debug and debuglevel=16 I get these logs:
[_impl_Wait] 'FD0: pTask = 0x6FF62720, pETask = 0xEFFF5300, Context = 0xEFFEF000
[RePostSignal] Reposting signals for task 0x6FF62720 (FD0)
[RePostSignal] Task 0x6FF62720 is already ready
[RePostSignal] Done reposting signals for task 0x6FF62720 (FD0)
[RePostSignal] Ready task is 0x6FF62720 (FD0)
[RePostSignal] Reposting signals for task 0x6FF62600 (input.device)
[RePostSignal] Task 0x6FF62600 is waiting
[RePostSignal] Waking up task 0x6FF62600
[RePostSignal] Adding to back of queue
[RePostSignal] Done reposting signals for task 0x6FF62600 (input.device)
[RePostSignal] Ready task is 0x6FF62720 (FD0)
[_impl_Wait] 'input.device: pTask = 0x6FF62600, pETask = 0xEFFF5240, Context = 0xEFFF4BA0
[_impl_Wait] input.device: pTask = 0x6FF62600, pETask = 0xEFFF5240, Context = 0xEFFF4BA0
[RePostSignal] Reposting signals for task 0x6FF62600 (input.device)
[RePostSignal] Task 0x6FF62600 is waiting
[RePostSignal] Waking up task 0x6FF62600
[RePostSignal] Adding to back of queue
[RePostSignal] Done reposting signals for task 0x6FF62600 (input.device)
[RePostSignal] Ready task is 0x6FF62720 (FD0)
[_impl_Wait] 'input.device: pTask = 0x6FF62600, pETask = 0xEFFF5240, Context = 0xEFFF4BA0
[_impl_Wait] input.device: pTask = 0x6FF62600, pETask = 0xEFFF5240, Context = 0xEFFF4BA0
[RePostSignal] Reposting signals for task 0x6FF62600 (input.device)
[RePostSignal] Task 0x6FF62600 is waiting
[RePostSignal] Waking up task 0x6FF62600
[RePostSignal] Adding to back of queue
[RePostSignal] Done reposting signals for task 0x6FF62600 (input.device)
[RePostSignal] Ready task is 0x6FF62720 (FD0)
[_impl_Wait] 'input.device: pTask = 0x6FF62600, pETask = 0xEFFF5240, Context = 0xEFFF4BA0
[_impl_Wait] input.device: pTask = 0x6FF62600, pETask = 0xEFFF5240, Context = 0xEFFF4BA0
[RePostSignal] Reposting signals for task 0x6FF62600 (input.device)
[RePostSignal] Task 0x6FF62600 is waiting
[RePostSignal] Waking up task 0x6FF62600
[RePostSignal] Adding to back of queue
[RePostSignal] Done reposting signals for task 0x6FF62600 (input.device)
[RePostSignal] Ready task is 0x6FF62720 (FD0)
[_impl_Wait] 'input.device: pTask = 0x6FF62600, pETask = 0xEFFF5240, Context = 0xEFFF4BA0
[_impl_Wait] input.device: pTask = 0x6FF62600, pETask = 0xEFFF5240, Context = 0xEFFF4BA0
This repeats 216 times and then it stops completely. The logs seems that it tries to wake up input.device but somehow the floppy task is cannot be prempted? QEMU emulates a floppy but maybe not completely and likely not needed so I'll try to disable a1floppy.device for now and see if that changes anything but does anybody have an idea how to debug this further? On pegasos2 the same floppy emulation is also present but maybe that machine does not have a driver so this does not happen there? Also this seems to be related to something like timing or memory layour (Heisenbug) becuase I did not see this before and changing unrelated patches in QEMU also makes it go away.
Edit: I think I've found out what caused this. Looks like PCI BARs are mapped with higher priority in QEMU so the IDE BAR shadows part of the FDC IO ports which causes a1floppy.device unable to communicate with the FDC and hang. This could probably be fixed but just disabling the floppy driver in Kicklayout is probably an acceptable workaround for now when one needs to modify Kicklayout to add siliconmotion502.chip driver anyway.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
