How to use PCI SATA controller?

[Reth]

Hi everybody,

maybe someone of you set this already up, so here is my question:

How would an AOS4 installation have to be set up so that it can benefit from an PCI SATA controller as good as possible?
Since the Peg2 cannot boot from drives connected to these controllers initial loading of kickstart modules needs to be done from an internal IDE drive.

So how can the system be split up so that only the initial loading of kickstart modules will happen from internal IDE?

Does anybody has this setup running successfully? If so please give me some hint!

Many thanks in advance!

Bye

[Slayer]

If I read you correctly you want to load the kickstart from the bootable IDE and during the reset stage boot off the SATA is this right? I doubt there is any other way than to time it right and enter the early startup menu and then select the SATA partition that you want to boot from.

Another way which isn't quite the same thing is you wait until the IDE begins its startup-sequence and you reassign all control over to the SATA partition so it effectively becomes the new SYS:

But to be honest I'm not sure there really is any point doing this, with proper planning you can have all your heavily used programs running off the SATA partition anyway.

[Reth]

Thanks for the hints.

Yes, you got me right. A pitty to hear that there seems to be no way (would be great to be able to define where to boot from after kickstart has been loaded).

But since there is currently everything installed at the SATA SSD the usage of all programs from that one would be automatically the case.
So if I got you right the easiest way would be having the system partitions at the internal IDE and all other stuff at the SATA SSD.

In addition I can think about having some of the utilities, internet programs (like DOpus, Browsers, Players etc.) and so on from the system partition outplaced onto the SSD (which might be complicated for some tools in terms of assigns etc.). What about libs, sobjs, c etc.?

[Slayer]

Is the IDE interface on the Peg such an incredible bottleneck?

Sorry you'll have to excuse my ignorance

I'm just thinking for the amount of times the system would need to access the odd library or obj or c command it wouldn't leave me pulling my hair out, I don't think

Why not give it a try and setup your SATA partition as an exact copy of your IDE Sys: partition and ensure it's bootable and then enter the early startup menu and boot off it (could you live with this every cold boot or reset)

I'm just wondering though if the boot priorty is honoured on the Peg that if you set the booting priority higher on the SATA that every warm reset from that point on would boot straight into your SATA and only during cold reboots would you need to enter the early startup menu

Hope that helps? See how you go

[Reth]

It's not only C and the libraries but also all additional stuff which is installed within SYS: like browsers (and for me AmiUpdate too). Maybe it's worth to move these ones onto SSD-partitions? What do you think (foremost regarding browsers and their caches).

As an update I've got installed the SATA-PCI card, the system partition, as well as BOOT-partition (and the MOS one) are placed onto the IDE HDD. The bootpriorities are now:

SSD:
- BOOT: Prio 0
- AOS4: Prio 4
- MOS: Prio 3

IDE HDD:
- BOOT_HD: Prio -3
- AOS4_HD: Prio -1
- MOS_HD: Prio -2
.
Guess what? The sytem always boots from AOS4_HD. Even every warm reboot is carried out on that partition.
Of course setting BootDevice does not help since the SSD partitions are not yet mounted at the end of kickstart loading!

So it seems that I can delete all bootable partition from the SSD and reallocate the space to all other remaining partitions on that drive.

SWAP is still located on the SSD thought but I do not know whether this works or not!

BTW: Are the recommended block sizes which are mentioned within the peg2ide.device doc still valid? And are they valid for SSDs on SIL-PCI-Controllers to (also for SFS/02)?

Bye

[Reth]

After some new input from some other thread inside AmigaWorld (see here: [url]os4-beta@hyperion-entertainment.biz[/url]) I made some additional attempts.
Now I've got AOS4 booting from SATA SSD after kickstart had been loaded from IDE partition (I copied my kickstart dir onto my BOOT partition where also of file resides).

There are only 2 (minor) drawbacks resulting from the fact that I also have an additional IDE partition where I installed a clean AOS4.1 system. Hence I've got at least one bootable IDE partition (clean AOS4.1 install) with lower boot prio (2) and one SATA partition (beta installation) with higher boot prio (4).

• When making BOOT: partition with kickstart dir non-bootable bootloader shows available kicklayouts like the following:
  First entry (not selected as default): Kickstart residing on BOOT: partition (partition lies in front of partition hosting AOS4.1 clean installation)
  Second entry (selected as default): Kickstart residing on partition with clean AOS4.1 installation.
• When making BOOT: partition with kickstart dir bootable using boot prio 3 (higher than AOS4.1 clean installation but lower than AOS4.1 beta installation on SATA SSD) then kickstart on BOOT: partition is chosen as the default one but after kickstart has been loaded system still tries to boot from BOOT: partition even though SATA SSD should be booted from according to boot priorities! So I tried to use BootDevice entry inside kickstart directory of BOOT: partition doing in shell echo > Kickstart/BootDevice "AOS4" and enabling MODULE Kickstart/BootDevice as last entry inside kicklayout of BOOT: partition (AOS4 is the device name of SATA SSD AOS4.1 beta partition). But then when bootloader tries to process this entry it's telling me: "Kickstart/BootDevice missing" or sth. like that). Does this mean it cannot find the file named BootDevice (which exists at exactly that place with exactly this name) or does this mean it cannot find the appropriate device (since SATA devices are not available during kickstart loading)?

Maybe somebody can give some info on the second point? Question is: Why does system boot from SATA SSD bootable partition when BOOT: partition is non-bootable but does not boot from SATA SSD bootable partition when BOOT: partition is bootable (if necessary I can post the setup of those partitions as list with BOOT prio, device names, units etc.)?

The less painful procedure is now: Leaving BOOT: partition non-bootable and select it manually as partition where kickstart should be loaded from each time a cold reboot is necessary.

Or is there still sth. I missed here?

Bye

[thomasrapp]

Does the BootDevice Kickstart module not work on a Peg? Or did you forget to RTFM?


From SYS:Documentation/Kickstart/bootmenu.doc:

Code: Select all

Predefining the default boot device in the KickLayout file
----------------------------------------------------------
This feature requires slb 1.16+ and Loader V51.10+ on an AmigaOne or
BootLoader 51.14+ on a classic machine. You should not try to use it
without those requirements, this may result in a non-booting or unstable
system!

If you want some other device than that with the highest boot priority
to be the default boot device for a given KickLayout file, add an entry
like

MODULE Kickstart/BootDevice

to the KickLayout file (caution, the name is case sensitive) and create
a text file with that name that contains the device name (not the volume
name) of the preferred boot device, e.g. this command

Echo >Kickstart/BootDevice "DH1"

executed in the shell will do it.


[Reth]

Does the BootDevice Kickstart module not work on a Peg?

Don't know. Could try to set it to an IDE partition and reactivate it.

Or did you forget to RTFM?

No. As stated above: I did exactly what is mentioned inside bootmenu.doc according to the part you posted! But when kickstart is loaded from IDE partition it states that Kickstart/BootDevice is missing.

[Reth]

Hm, strange enough:

After making my IDE BOOT: partition (the one which hold of file and kickstart dir) nonbootable again its now recognized as default kicklayout when AOS4 bootloader starts. So now sequence of kickstarts/kicklayouts listed is now vice versa hence now it is working completely as it should:

Kickstart is loaded from IDE partition where also OF file resides, afterwards system boots from SATA SSD partition which itself has highest boot priority.