Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
88 user(s) are online (56 user(s) are browsing Forums)

Members: 0
Guests: 88

more...

Headlines

Forum Index


Board index » All Posts (Hypex)




Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@joerg

Quote:
The main difference in the RTL 8029 and 8139 drivers is that AFAIK the 8139 one uses DMA, while the 8029 is PIO-only, which should be much easier to emulate.


Also I've found the OS4 8139 driver to be crippled somewhat. I can never get full speed out of it. Whatever that is about. If I use Linux it can download at full speed.

Also, strangely, Linux can use the X1000 Ethernet. But OS4 cannot. Except for a buggy driver which by comparison doesn't count. I thought the X1000 was made for AmigaOS but it only works fully in Linux.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@kas1e

Quote:
Dunno why there 2 displays, but that what each of them show:


Could it be a TV out? If not then a duplicate device for extra VGA or DVI perhaps. My 9200SE used to show extra devices, which had a TV out, and could display UBoot on my TV. Been a while since I checked the PCI config.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@balaton

That sounds like a plan. I was going through my sources from when I was hacking with CFE to see what it put in registers when calling a binary. The result must be somewhere else as I didn't find any info extracted. However, what is important is the OF hook, as any boot loader can disregard anything else and the OF hook the core point from which it operates.

The only other important info would be the address range it needs to run in. I was disassembling the Pegasos amigaboot.of, or as I called it, pegaboot, and it first relocates itself before launching. I'd need to check the asm. It was something like $200000. Without it, at least on the X1000 to where it needs to be, interfacing with OF will simply not work. In my case it refused to print anything on screen when using OF write routines.

Now, if you are going to write a replacement for amigaboot.of, it will take time. So, you would want this to be a last resort, since it means it's non standard if the intention was better OS4 emulation. But, given was it does is load in files from combined file lists and send the result to a loader, that may save from some nitty gritty being the job of the loader is to process a list, link it all and launch it where it needs to be.

Go to top


Re: A1222 production now underway!
Just popping in
Just popping in



Go to top


Re: Qemu and Right Amiga key
Just popping in
Just popping in


@walkero

I could see that as an issue since AmigaOS uses right alt as well. You are obviously limited by the keyboard. My laptop has no right logo or menu key but it does have a right ctrl which I assigned as right Amiga. However, I did that in FS-UAE, but not with Qemu.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@balaton

Okay I checked and boot loader code gets passed three parameters. This is what amigaboot.of would pass to the loader.of. But likely what's more important is what gets passed to amigaboot.of by the firmware though it shouldn't be too different. I'll need to look again for that. It should match OF binary standards.

int _start(char *OS, struct List *KickList, int (*OFI)(void *))

So OS is a string like "AmigaOS4". KickList is a list of modules. OFI is the OF interface or hook.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@joerg

Quote:
I only checked the 13 years old version on GitHub, which doesn't include FFS support, but it's probably outdated.
Really DOS\0? Doesn't make any sense, more code required and slower than DOS\1.


It is I found. The blank readme isn't very informative and isn't even a common MD file. It's version 0.91. Also missing from the readme.

The 0.93 is on the ACube site. There is one guide here. And the guide mentions FFS0 support.

http://elwoodb.free.fr/articles/Sam440/debian.html

Quote:
It's required for booting the Sam4x0 versions of AROS, and supposed to make booting Linux easier. If you don't need AROS support it doesn't make any sense to use it for booting AmigaOS.


I imagine not many would want to use a Sam for AROS. Then again the same could be said for Linux. It would make Linux booting easier by supporting a DTB. But it could still work from SLB. The installers tend to lack support for the "old" method".

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@kas1e

I wonder if it would be possible to run a program before amigaboot loads so it can work? One with an UEFI x86 emulator. A batch file would be too involved, if it could work, though it could be loaded off disk. A simple binary would break, since when it returns CFE would crash, before amigaboot could even start. I don't know if a command could load code it, so that when started it runs an emulator to setup card, then return and launch amigaboot.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@kas1e

Quote:
On All Uboot supported machines RadeonHD/RadeonRX works. On X1000 (which is CFE, and not UBOOT) - RadeonHD/RadeonRX also works.


It can for RX but not in a normal way. Some jumper needs setting on the board and there is no CFE output. If all you have is one Workbench that always gets booted it's no issue. But if you have a boot menu with multiple items you're blind sighted to chose an entry.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@joerg

Quote:
If that's the case it would require changes in the Pegasos2 kernel, the slb (slb_v2, amigaboot.(ub|of), Parthenope (which isn't usable anyway because it doesn't support any AmigaOS file system but only Linux (ext2fs) and AROS (SFS 1.84) ones)) can't fix it, nor can the AmigaOS gfx drivers.


Actually, it does. FFS0. Which isn't very useful but okay for a boot partition. Like Ext2.

But there isn't much information about Parthenope. The download from ACube is pretty much a source dump with a lucky binary included. The install guide is just a generic guide to compiling. No wonder people had trouble using it! How can people spend time creating a binary, regardless of the usefulness, but not include any documentation as to what it is or what it does or how to use it?

Obviously Parthenope is for hackers and not end users.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@balaton

Quote:
Yes, thanks, I've also found that function later in parthenope and saw it loads modules and calls the exec binary so maybe I can start from that.
I'm not familiar with the source just found a bug when trying to boot AROS on the sam460ex emulation which I did to check it so I had to fix the bug first to get it load.


That bug took me a month in my spare time to figure out. I modified the source so it would work on the XE models. A fairly trivial change to the boot sources and disabling Sam specific code. So it loaded up but then I found it would randomly crash! But it depended on if it was a fresh boot or a reboot I found out later. So if I kept rebooting to test it didn't show up. I grabbed a log of the crash over serial and UBoot isn't very informative about what caused it, ignores debug info in ELF, gives no clue what did it. So it became very annoying and I couldn't see what was doing it. In the end I did it the old fashioned way and bombed the code with printf's and tracked it to the CDFS reader. Which clearly was sending a NULL where there shouldn't be. For some reason on the Sam it allows it. I don't know how! The firmware violates its own API!

It makes me wonder if some quirk of the hardware fills location 0 with some address that happens to be readable. Or if the firmware does something to fill it in. By some chance on the Sam reading from 0 is legal. Don't know if tests were done on the hardware. Did anyone write or modify code to read back what 0 contains?

Also there is another bug in the Sam-ware. The keyboard goes dead when trying to read it from the key function. That would use USB. But I found recently the same can happen from a Micro A1. Using later beta unreleased firmware in any case.

Quote:
I think the OF ABI on what a binary run by the firmware gets is documented either in some OF standard or in CHRP but for me the easiest is to look at QEMU VOF:
https://gitlab.com/qemu-project/qemu/- ... master/pc-bios/vof/main.c
https://gitlab.com/qemu-project/qemu/- ... ter/pc-bios/vof/bootmem.c
so according to that it would be
(*kernel_addr)(initrd_addr, initrd_size, CI_entry); in r3, r4, r5
so I can start from that and see if I can get ti boot or do something at least.


Yes it's obvious there it sits in R5. Also looking up the PPC kernel source helps as it's right there in the entry point as an expected pointer. That would have been the best place for me to look had I known how the kernel runs on PPC at the time.

Another quirk is the kernel is loaded to 0 or at $C0000000 mapped to 0. Expected such a setup to crash. Somehow that works for Linux.

But the Sam has UBoot. So doesn't have OF. It can pass a DTB unlike the XE UBoot. The Pegasos has the Smart ware which is closer to OF and should be easier to work with and simulate. But lacks source like the Sam. Though Smart is supposed to to be the open Smart source. But with changes. That makes it like CFE on the X1000, can get original CFE source, but not the exact source that is in the X1000.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@balaton

Wow this topic has taken off.

Quote:
Yes I think I meant ub2lb/parthenope when I said AROS bootloader. But doesn't that just load amigaboot file and launches it? Does it replicate what amigaboot does and loads the kernel modules itself? I've looked at the source but it's not very clear.


No, it can do what amigaboot does, all self contained. So yes it can replicate amigaboot but it did lack FFS2 support. It can do the job of what SLB can do, which would predate amigaboot, on the A1 and Sams. And yes, the parthenope one, as it's also called. I looked at the code years ago. It does load in the kernel modules then launch it. By jumping to the loader code module somehow.

Apart from making AROS bootable it has better support for booting Linux. SLB can boot Linux from simple one liner kernel and options, but ub2lb is slightly more complex like GRUB and has more options. I modified it for use when building a Linux installer on the XE so it would auto boot into menu.

Now, I see you are familiar with the source since you discovered it crashes in the start_unit_scan() debacle from a NULL pointer, after Googling that function. I knew about this. I'm sure I posted about this years ago on AmigaWorld.

Okay just checked and I did in 2017. Found a thread. Sorry link bombing here:
https://amigaworld.net/modules/newbb/v ... wmode=flat&order=0#801942
https://amigaworld.net/modules/newbb/v ... wmode=flat&order=0#801965
https://amigaworld.net/modules/newbb/v ... wmode=flat&order=0#801974
https://amigaworld.net/modules/newbb/v ... wmode=flat&order=0#801993

Quote:
The Open Firmware part is clear to me. I tested amigaboot.of with the minimal open firmware in QEMU and know what it misses to run and what OF client interface functions it uses but I don't know what it does with the data it retrieves from OF. That is what kind of structure should it build from the OF device tree and how should it pass to the kernel. So I'd need more info on that part, all the others I don't care about.


I'm not certain if it builds anything from the device tree. The loader at the end can look up the tree itself if it needs too. But the Kick modules are all self contained in that the core ones are compiled for the machine they run on. I don't see a way to pass dynamic strings or objects. Extra options are in nvram variables or embedded in a module as text. I don't even think modules can be passed arguments like a normal command. Fairly rigid design.

But yes what's needed is the data that's passed down the line.

The Kicklayout can be slightly misleading as the comments mention EXEC being the name of the main kernel to use that contains exec.library. This not quite correct. EXEC points to a loader that launches the kernel. The kernel module contains exec.library. The EXEC file doesn't contain the kernel at all in the common configuration.

Quote:
The different versions are probably just to talk to the different firmwares in these machines. There are at least 3 kinds of firmware interfaces so there are that many boot loader versions but these likely only differ in the firmware side which I know for OF, I only need info on the kernel facing side that makes the module list in memory and prepares the info about the machine and starts the kernel. I'd look for info, docs or hints on that, the rest I can handle.


Yes that is the core info you need. And refreshing myself with the ub2lb code it looks like it has almost everything you need. I didn't see it before. It's just slightly complicated looking as it supports 4 things for booting; generic, OS4, AROS and Linux. So it reads in the Kicklayout from menu_load() and then in testboot_aos() it builds the module list. But, this is where I was lost, it loads in the EXEC loader separately and stores it as kernel. Usually this would be first module and also stored in the module list. I'm unsure about the module ID and flags but what is referred to as ID could be file type. So ID could be for binary or data. The struct module you need is in here.

https://github.com/cjg/ub2lb/blob/master/src/parthenope.c

What needs to be checked is register parameters which would differ in OF ABI. IIRC it's something like; R3* OS string, R4* module list, R5* OF hook.

Quote:
OK then maybe there are only two versions, one for OF and one for U-Boot wuth the U-Boot part already open source but that's not too interesting.


Likely the CFE/X1000 amigaboot is based directly off the Pegasos one. Don't know who made the firmware that way apart from Varisys but OF was hacked into CFE and they kept it that way. This would have made it easier to port and existing amigaboot over and at least two code bases could be merged. On the X5000, the modern UBoot supports OF basics like trees, since OF is so entrenched in PPC and being UBoot is made for Linux, it made sense. This would make it easier to port it as an amigaboot.ub since they can share the same code base. Right now Trevor owns ExecSG and amigaboot with it.

Quote:

I'd need the interface between amigaboot.of and loader.of and to know what structures in memory loader.of needs and where to pass them. The rest is just firmware dependent or trivial.


The list structure (which is an AmigaOS list) will be above with the module structure as nodes. Where they are passed as parameters needs to be checked.

I actually wrote my own CFE emulator when testing a few years back that emulated OF hooks. It could run amigaboot up to a point. Enough to see what it was doing. It was a bit of a hack as it intercepted DSI crashes since the memory mapped differs. But the range was known. Be more cleaner if it used MMU but it did the job. Should clean up source and release it as experimental emulator.

Quote:
Yes this is the part that would be interesting if it was documented in a bit more detail.


Against all odds it turns out parthenope is your friend.

Quote:
quiesce is the OF client interface word for closing down and stop using firmware services after boot so it's not just how Linux calls it. The OF client interface is well documented in its standard.


I see. I wonder if OS4 kernel uses it as well? It could be hidden.

I struggled to find basic technical info years ago about the ABI. Such as the OF hook being in R5. For some reason I just couldn't find the ABI layout. I suppose if you have something like "void *, void *, (*)()" R5 will be hidden. Don't recall exactly. But I do recall I could never figure the memory allocator out. It seemed to be too technical and needed hand holding with memory ranges or something. I expected something like a malloc() that was self managed. I wanted to program OF to allocate some memory. In the end I gave up and just wrote my own allocator using a preset range.

Quote:

I'm not sure about that part, I think I'm still missing the structs and calling convention of loader.of to be able to reimplement amigaboot.of.


Here's an amigaboot.of chain loader.

https://forum.hyperion-entertainment.com/viewtopic.php?t=4672

Quote:
Since yaboot probably can't load AmigaOS I don't think it would help much.


No but it does reveal one clue about the Pegasos. The Pegasos is the only platform here with CHRP support that was officially supported by Linux PPC install CDs. They contained extra scripts in FORTH that loaded in a CHRP kernel and booted it. It also needed the extra kernel but it had support. Unlike other platforms like the A1/XE which had no support on official releases. Likely because UBoot was totally different and had no OF emulation. Having built an installer CD for the XE it would be way over the scope of a simple configuration since it needed a fully custom kernel and modules. Though the PegXMac Mac emulator CD did manage to support both Pegasos and XE with one boot CD.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


@balaton

Quote:
All I'd need for that is to know what it does and what the AmigaOS kernel needs at boot. Is this documented somewhere? Or if it's easier to just open source amigaboot.of I can figure that out without docs fron the source. The AROS boot loader does something very similar so likely it would not be too difficult to reimplent amigaboot.of based on that or even from scratch. That seems to be a better path then rewriting the pegasos2 firmware.


I don't think it's documented anywhere and likely you won't get any answers if you ask. But, the ub2lb project can be a starter. That works on the Sam though, which is different to the Pegasos, but contains info on how to boot an OS4 kernel.

What amigaboot.of is doing, is talking to OpenFirmware, what ever one is in the host firmware. Cannot confirm but likely it uses OF hooks to read system and files in. It then passes control over to the Kicklayout EXEC binary to boot the system.

Now, there is a Pegasos version and X1000 version of amigaboot. There's also X5000 version but that is amigaboot.ub running under UBoot so totally different port for the most part. It depends on the hardware or OF set up, but amigaboot can only run if it is relocated to a specific address range. I found this out myself the hard way, when I tried to write CFE binaries using OF hooks to print messengers and they didn't do anything. Nor crash. After a month of doing my head in I found out nothing was wrong with my code, when I was examining amigaboot.of, and noticed it relocated itself. I copied the address into my linker setup and suddenly my CFE binaries worked! Yes side note, CFE doesn't execute real CFE binaries, since CFE is only a "user" interface. It's all OF under the hood even if it hides it. A CFE binary is just an OF binary.

So, the boot sequence goes, Smart/CFE-OF -> amigaboot.of -> EXEC loader.of. Amigaboot loads all the Kick modules in, links them all in a list, then sends it off to loader.of which is a raw binary that takes the Kick list and bootstraps the kernel. All along amigaboot.of and loader.of have access to OF and hooks. Only at the end is OF killed by the OS. Or "Quiesce" as Linux kernel calls it. You can easily write your own chain loader this way.

I also tried running yaboot (Linux bootloader) on my X1000 but it crashed. Lol. I don't know if it loads to a particular address, since it is Mac specific, but I wonder if it could be recompiled to be compatible with Pegasos or X1000 if that helps.


Edited by Hypex on 2023/6/29 2:14:11
Go to top


Re: Task scheduler
Just popping in
Just popping in


@Capehill

Okay, yes, can see that. Thanks for explanation.

Go to top


Re: Task scheduler
Just popping in
Just popping in


@Capehill

Thanks. Looks nice and useful. Sometimes my CPU goes up just after booting.

What I found is, when my CPU clock suddenly listed high CPU after booting Workbench, is that CPUCLock appears to be the culprit. It listed about 97% usage but the priority is -128 or close to. It shouldn't be that high and shouldn't get so much CPU time to register as such. But maybe something is putting it off.

Go to top


Re: Lsof AmigaDOS?
Just popping in
Just popping in


@joerg

Quote:
Actually we have at least 2 of them.
However, my "top" can't be used in DOS or ARexx scripts since it running infinitely until you stop it with Ctrl-C, but maybe Capehill's "Tequila" can be used that way.


That thread was mostly discussion then I found some links on the end.

But what I meant was a command or tool built in. It's becoming common that I find or rather don't find what I thought would be an obvious tool built into the OS. It's likely using what other OS has and then I realise something so obvious like even a basic process monitor doesn't come with OS4.

Go to top


Re: How do you understand a CFE memory test?
Just popping in
Just popping in


@noXLar

It does give a clue thanks. There is source with memory test commands which gives an indication what it is doing. But it does differ on X1000 so not fully clear what else it is doing.

Go to top


Re: How do you understand a CFE memory test?
Just popping in
Just popping in


@Raziel

Thanks. Yeah, CFE wasn't meant to run on PPC, yet alone run on a desktop mobo so no surprises it had some quirks. Plus it was hacked by whomever to run OF binaries. It would have been useful if it was actually useful in diagnosing issues such as reboot loops, CFE crashing on boot and crashing during loading.

Go to top


How do you understand a CFE memory test?
Just popping in
Just popping in


Hi guys.

I've been trying to understand the CFE memory tests for years. I have found no info on what they mean. And I so far cannot decipher the output of it. CFE commands testdram and memorytest appear to work fine. But randmemtest spews out a bunch of 64 bit numbers I don't get and hangs the machine. Is it normal for it to do this? CFE does have bugs so thought this might be another bug. The output implies some error and the hang isn't a good sign.

So here is output with one 2GB RAM stick inserted. I can't make any sense of it. Do other people get senseless results and a hang as well?

CFEmemorytest
Available memory arenas
:
phys 0000000000000000virt 0000000000000000size 000000007FD1D000

Testing memory
.

Testingphys 0000000000001500virt 0000000000001500size 000000007FD1BB00
Writing
a/5/c/3
Reading
a/5/c/3
Writing
address|5555/inv/aaaa|address
Reading
address|5555/inv/aaaa|address
MC_Status
:  MC000000000 [ ] SBE=MC100000000 [ ] SBE=0
*** command status 0
CFE
testdram
DRAM test complete
!
*** 
command status 0
CFE
randmemtest
Writing 
(0000000000000000 -> 0000000010000000scrambler=7
Reading
.
mem[000000000FFFFFC08000000000000000 should be 55555AAAAAAAAAAA (D5555AAAAAAAAAAA)
mem[000000000FFFFFC87FE000087FE00008 should be AAAAA55555555555 (D54AA55D2AB5555D)
mem[000000000FFFFFD87FE000087FE00008 should be AAAAAAAAAAAAAAAA (D54AAAA2D54AAAA2)
mem[000000000FFFFFD07FE000087FE00008 should be 5555555555555555 (2AB5555D2AB5555D)
mem[000000000FFFFFE07FE000087FE00008 should be 000000000FFFFFC0 (7FE00008701FFFC8)
mem[000000000FFFFFE87FE000087FE00008 should be FFFFFFFFF000003F (801FFFF78FE00037)
mem[000000000FFFFFF07FE000087FE00008 should be 0000000000000000 (7FE000087FE00008)
mem[000000000FFFFFF87FE000087FE00008 should be FFFFFFFFFFFFFFFF (801FFFF7801FFFF7)

Go to top


Re: Lsof AmigaDOS?
Just popping in
Just popping in


@daveyw

Okay I see. By the looks of it there isn't a command to do that. I think that is slightly lower level as that descends into DOS internals. We don't even have a top command. I didn't realise it until I needed it that we can't even do something as simple as listing current tasks. To see what is hogging CPU.

The suggestion for a DOS function maybe the way to go if you use ARexx as ARexx can call library functions. I'm not sure if ARexx can actually list open files but ARexx tends to go deeper than what DOS scripts can provide.

Aside from that writing your own binary to use as a command is another solution but more work. However sometimes it's needed on AmigaOS.

Go to top



TopTop
« 1 2 (3) 4 5 6 ... 11 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project