Yesterday i've spent a wonderful exciting evening devoted to this little long-standing problem. And here are results: the operation is quite simple, however it can't be accomplished inside MorphOS environment. Here is a short description of what and why (for all curious guys here):
1) Besides sending a shutdown command to the VIA8235 controller it's necessary to perform some "magic" PCI configuration space access cycle. The necessary registers on Peg2 are: 0xF1000c78 - address, 0xF1000c7c - data. They are part of Marvell chip (base address is 0xF1000000).
2) Such a cycle can't be caused by pci_write_config_long() because the address written doesn't represent a valid PCI device.
3) Marvell's MMIO space exists under MorphOS however it's protected fron the applications by the MMU. pcix.library doesn't access them directly, it uses Quark calls.
4) To call Quark you load function code into r0 register and produce an "sc" (system call) interrupt. The rest of processing is performed inside Quark on CPU supervisor level. Interrupt vectors table is placed at 0xFFF00000 and it's impossible to even read it. It is protected with MMU.
That's all folks. Your hands are tied here.
One more interesting fact: A window at 0xF1002000 is open for r/w access, a Gigabit ethernet controller is located there. Drivers writers are welcome.

Related links:
Linux kernel source code - gives a great overview of all Marvell northbridge registers. See MIPS-specific kernel part for the HW accessing code.
U-Boot firmware source code - This opensource firmware is used on AmigaOne, however it supports Marvell reference boards too. This link leads to Marvell-specific code. Note that Articia code is also present in this tree, it can be interesting for Peg1 owners.

[ Edited by Sonic on 2006/8/29 11:35 ]

Hmmm ... this was told me years ago. (That it does not work with current MorphOS-Bootimage)

Now imagine how much time you wasted

Quote:

2 evenings total.
You know, i can't say they are totally wasted. That was great experience and my first steps in PPC asm
Probably one day i'll write some kind of article about Pegasos HW and MorphOS internals, for curious guys like me.

i also don't think the time was wasted... i like this investigation, and would be cool to get even more information of the pegasos2 itself... reminds me good old amiga hw, and it's special addresses...

bye and thanks, MarK.

Quote:
Not at all!

Quote:
And I'm for sure one that will be very interested in that reading. MorphOS is about investigation. Hell, home computers used to be for learning, remember those old times hacking away our lottle Commodores?
This use for computers as learning tools got lost when PC's came into scene, and computers became commodity items. This has lead to an ever growing percentage of computer users which don't really know how they work (leading to immense amounts of frustration, rejectness, and... wads of money coming in from support services).
Computers are not for ignorants, no matter how much money big companies put in to convince the world otherwise.

So, if anyone could explain to a n00b.. The protected MMU address space is defined where? If we now know the range of memory that need to be readable/writable from within MOS, can this be changed in MOS v1.5 or later versions? It would certainly be a nice feature to have :)

The possibility of making Quark calls is also very interesting. It would allow you to protect/un-protect the areas you need, or maybe to remap memory areas... that would be very useful to port SheepShaver.

Quote:

Uhhh, 1.5 had this feature from day 1...

Besides, it was a complete waste of time by Sonic because someone else already hacked a software shutdown for 1.4 (which will probably corrupt your harddrive, destroy your pegasos (and your precious floppy drive too!) and eat your children (atleast the first example is quite likely), but who cares, you got shutdown! ;) ).


- CISC

Quote:

The first one might be useful (but that won't happen until the API is ready for public consumption), the second is nonsense, unprotecting areas we set as protected will always be a no-go for obvious reasons, however some limited MMU access was always planned...


- CISC

Quote:
So why doesn't MorphOS 1.4.5 has that feature? Afaik, it's newer than "day 1 MorphOS 1.5"

Quote:

Because Quark underwent a series of rather big changes during this period, which meant we could not easily transplant a newer Quark into the 1.4.x releases without potentially seriously breaking something, so we didn't...


- CISC

Quote:

At least not current Quark version i guess (however, just guess, may be i'm wrong).
You can see many interesting information on your serial port if you specify some qdebugflags on the kernel's command line. Unfortunately i don't remember their names but you can find them out yourself. To do this ungzip your kernel, load it into hex editor and search for "QDEBUGFLAGS" string. You'll fing a ReadArgs() template used to parse kernel command line then (yes, ReadArgs() is also part of Quark now ). It will be followed by 3 more templates. First of them is embedded template for qdebugflags (Quark), second - for edebugflags (exec.library) and third - for ddebugflags (dos.library). These arguments (except Quark) correspond to switches in "Debug" section of your MorphOS system prefs, however setting these flags at boottime allows you to get some init-time information which is hidden otherwise.
The flag names are pretty self-explanatory.
In short, amongst other things, this will tell you about how memory mapping is set up. You'll see that it's setup during startup and exec.library doesn't change it after that. It's really an "A-Box", an operating system inside another operaring system (Quark), this is the same situation as Linux-hosted AROS, you can't get into Linux's side from within AROS, it runs in a completely virtualized isolated environment.
So i guess current Quark doesn't provide calls to do it just because noone needs it. Even if it does, we would have to disassemble Quark in order to understand them, but this is impossible (A-Box just doesn't see it, for it Quark's memory space doesn't exist, we just get hits when we try to get there).
Modules inside the kernel are compressed (debug log tells about this), so disassembling a raw kernel binary doesn't discover the kernel implementation itself.
PCI interrupts are not true interrupts, they are emulated. This means you're not a true supervisor inside them and you can't do more than you can usually do. I guess they are implemented as bottom halves.
Also the kernel really doesn't use even OpenFirmware's RTAS, despite you can find its methods names in the kernel, i've checked it by replacing "system-reboot" string with "shutdown"; after this rebooting function inside MorphOS gave reboot as before, this means this RTAS method is not used, obviously other methods aren't used also. This means my previous suggestions were wrong and it's impossible to introduce "virtual firmware" layer which would intercept some calls from within the kernel.
All we can learn about Quark are syscalls numbers which implement AmigaOS libraries functionality (like rebooting, PCI access, etc). However this won't have any practical application since these functions can be accomplished in a system-friendly manner using libraries. Moreover, noone guarantees that Quark API will not change in future MorphOS versions/revisions.
Further reverse engineering would require a giant effort of modifying MOL to make it running MorphOS. After this we could have a complete virtual machine to look what's inside. However, personally i have neither time nor enough motivation to do it. In addition i'm enough busy with other projects.

Quote:

That would be great! I guess that Itix could do a SheepShaver port in a week

@Sonic

wow :)

@Sonic: that was an interesting post :) Keep sharing your experimentations :)

@CISC:
Quote:
And what would you be breaking if you released newer Quark+MOS 1.5 ?

Leo.

[ Edited by Leo on 2006/8/29 13:40 ]

Quote:

A secret deal with satan?

Quote:

very interesting, does that mean that Peg1 boards could be turned to AOnes very easily ? and Pegasso2 as well ?
That would definately break the market if u could get a cheap Peg1 board flashed with uboot and sold on ebay as AOnes for 1000$ :-p

I still believe that Sonic would give a significant boost for MorphOs development if he could join the VIP MOS coders secret society. *sigh*

Quote:

Really. Wow. That was some damn serious hacking. I guess it could win Sonic an award as core member of MorphOS... or completely otherwise, as his tactics are quite... erm... unorthodox?
That's brave man! You seem to be a developer with a great degree of deep concentration!

Quote:
More or less everything :-)

Quote:
Pegasos-1 - yes, exactly.
There was some post in some AmigaOne-oriented forum (i've found it once but lost the link) about the experiment conducted by Genesi. They've flashed a slightly modified Pegasos-1 firmware into AmigaOne and it booted MorphOS.
Technically it is possible. It is also technically possible to write a loadable u-boot implementation for Pegasos-1 which would boot up AmigaOS4. It's also possible to do a reverse thing - write an OpenFirmware implementation on top of u-boot and make AmigaOne booting up MorphOS.
This is the same kind of task as my BootX port. Difficult but doable.
AmigaOS4 people, however, say that they ship some hardware protection key with every copy of AmigaOS4. Well, probably loyal OS4 owners could tell more...
All this is not true, however, for Pegasos-2. It has quite another northbridge that AmigaOS4 is unable to drive.

[ Edited by Sonic on 2006/8/30 8:44 ]

Quote:

Quote:

I thought that was V1.666.

Actually, there is some extra stuff on the flash of the AmigaOne. I wanted to fix the CW keyboard support in UBoot, and if you flash an AmigaOne with just UBoot, OS4 doesn't boot any more (only linux). You have to flash it with UBoot, and the extra stuff that OS4 uses.

Quote:

Well, isn't UBoot GPL? In which case you (as an owner of an A1 and the UBoot that comes with it), must be able to receive the full sources of UBoot on request, including the bit that makes OS4 run...


- CISC

I don't think the OS4 stuff is part of UBoot, referenced by UBoot or required by UBoot. Its just stored on the same chip. Just like its possible to distribute GPL and non-GPL programs on the same CD.

Even if a different license would be required (which I don't actually know, see above), how do we know Hyperion haven't got such a license? They have a good working relationship with the U-Boot team, AFAIK.

If you _REALLY_ care, take it up with them.