Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
36 user(s) are online (20 user(s) are browsing Forums)

Members: 0
Guests: 36

more...

Headlines

 
  Register To Post  

« 1 ... 10 11 12 (13) 14 »
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
@Maijestro

I read about the improvements

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.


Edited by white on 2023/10/14 20:11:37
Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
@whiteQuote:
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.


Edited by Maijestro on 2023/10/14 20:44:16
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top
Re: qemu emualtion of AmigaONE XE
Just can't stay away
Just can't stay away


See User information
@white
Quote:
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.

Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
@joerg

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.


Edited by white on 2023/10/14 20:52:41
Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
@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.

Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
@balaton

Yes it is exactly as you described.
That's why I had to give chmod 777 every time

at every reboot to access the AmigaOS partition
and the qemu command line didn't work normally.

so in summary
better a completely dedicated SSD in case you want to opt for this choice.

Go to top
Re: qemu emualtion of AmigaONE XE
Just can't stay away
Just can't stay away


See User information
@balaton
Quote:
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.

Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
I'll write it here if it might be found interesting by others too
otherwise it's not important.

sudo mkdir -p /media/ramdisk
sudo mount -t tmpfs -o size=2048M tmpfs /media/ramdisk

sudo fdisk -l
we obtain:

/dev/ram0

then we add:
-drive format=raw,file=/dev/ram0

è "hdtoolbox" recognizes the new "virtual partition created with the ramdisk" ready to be initialized

at that point "qemu" comes out giving me the error:
"floating point error"

Not knowing AmigaOS I really don't know if it is possible to manage this type of volume by mounting them in other ways

Or if there is some utility in AmigaOS that can handle all this.

If anyone finds it interesting, we could look into it further.

by modifying "fstab" it can be made permanent or simply the volume disappears upon reboot.

Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
@white
Quote:
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.

If you want a shared folder between host and guest port this to AmigaOS:
https://www.emaculation.com/forum/view ... 5528347928e09724db19d2649

Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
@white
Quote:
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.

Go to top
Re: qemu emualtion of AmigaONE XE
Not too shy to talk
Not too shy to talk


See User information
@white

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.


e.g. tmp directory as a drive under AOS


https://ibb.co/PgnFRx7


"-drive file=fat:rw:/tmp,id=ufat,format=raw,if=none -device usb-storage,drive=ufat"


Edited by smarkusg on 2023/10/15 22:11:14
Go to top
Re: qemu emualtion of AmigaONE XE
Just can't stay away
Just can't stay away


See User information
@smarkusg
Quote:
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.
Are there problems with network access between host and guest in QEmu?
If not why not simply use a FTP, NFS or SMB server on the host and something like https://aminet.net/package/comm/tcp/FTPMount_os4 http://os4depot.net/?function=showfil ... =network/samba/smb2fs.lha or https://aminet.net/package/comm/net/nfs3 on the guest for transferring files between host and guest?

Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
@all

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.

This is the distro I'm using:
https://pop.system76.com/

@balaton
once again thank you for your work.

Go to top
Re: qemu emualtion of AmigaONE XE
Not too shy to talk
Not too shy to talk


See User information
@joerg
Quote:

If not why not simply use a FTP, NFS or SMB server on the host and something like https://aminet.net/package/comm/tcp/FTPMount_os4 http://os4depot.net/?function=showfil ... =network/samba/smb2fs.lha or https://aminet.net/package/comm/net/nfs3 on the guest for transferring files between host and guest?


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

Go to top
Re: qemu emualtion of AmigaONE XE
Just popping in
Just popping in


See User information
@white

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.

Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
@smarkusgQuote:
smarkusg wrote:@white

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.


e.g. tmp directory as a drive under AOS

"-drive file=fat:rw:/tmp,id=ufat,format=raw,if=none -device usb-storage,drive=ufat"


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.

Does it work the same under Linux and Windows?


Edited by Maijestro on 2023/10/16 17:26:02
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top
Re: qemu emualtion of AmigaONE XE
Not too shy to talk
Not too shy to talk


See User information
@Maijestro

Yes. You just have to remember that the content of the directory should not exceed 500MB. QEMU will write out an error message.

https://en.m.wikibooks.org/wiki/QEMU/Devices/Storage

Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
@smarkusg

Quote:
smarkusg wrote:@Maijestro

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

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top
Re: qemu emualtion of AmigaONE XE
Just can't stay away
Just can't stay away


See User information
@AlexC
Quote:
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

Go to top
Re: qemu emualtion of AmigaONE XE
Quite a regular
Quite a regular


See User information
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.devicepTask 0x6FF62600pETask 0xEFFF5240Context 0xEFFF4BA0
[_impl_Waitinput.devicepTask 0x6FF62600pETask 0xEFFF5240Context 0xEFFF4BA0
[RePostSignalReposting signals for task 0x6FF62600 (input.device)
[
RePostSignalTask 0x6FF62600 is waiting
[RePostSignalWaking up task 0x6FF62600
[RePostSignalAdding to back of queue
[RePostSignalDone reposting signals for task 0x6FF62600 (input.device)
[
RePostSignalReady 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.devicepTask 0x6FF62600pETask 0xEFFF5240Context 0xEFFF4BA0
[_impl_Waitinput.devicepTask 0x6FF62600pETask 0xEFFF5240Context 0xEFFF4BA0
[RePostSignalReposting signals for task 0x6FF62600 (input.device)
[
RePostSignalTask 0x6FF62600 is waiting
[RePostSignalWaking up task 0x6FF62600
[RePostSignalAdding to back of queue
[RePostSignalDone reposting signals for task 0x6FF62600 (input.device)
[
RePostSignalReady 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.


Edited by balaton on 2023/11/10 15:16:40
Go to top

  Register To Post
« 1 ... 10 11 12 (13) 14 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project