IntuitionBase - Your Guide To AmigaOS4.x And The AmigaOne

1 - si680ide
=========
There seems to be some confusion about how to use a si680 board. Here are a few hints :

- make sure that in UBoot menu, under the PCI features item, interrupts are set at 9, 10, 11, 7 and all trigger methods are LEVEL (and not EDGE)

- make sure you use a *kernel* version >= 51.15

- make sure you read each word of http://s.guillard.free.fr/OS4/si680ide_dev_relnotes.txt in depth, all sections. If there is something you don't understand, please ask me.

- make sure you stick to my cabling and partitioning advices. In particular, make sure you use a fresh 80 wire UDMA cable, and that your master drive is AT END OF CABLE, wether there is a slave or not.

- you noticed that si680 does not enable UDMA modes without you forcing it to do so (either using the sil_xfer uboot envvar, or using idetool to switch between xfer modes). So don't expect any speed improvement by just installing the si680, in fact currently its PIO code is even slower than the VIA PIO (because I did not enable prefetch buffers in the si680 yet).

- UDMA is currently completely disabled for ATAPI devices (CD|DVD readers|burners), this is because it could not be made safe for a1ide, and this limit was not removed yet in the si680 code. In other words, as of now, your ATAPI devices will only get PIO modes. But no worry, it will come soon for si680.

- in order to find out which UDMA modes are supported by your harddisks, use "idetool -u si680ide.device n" where n is the unit number from 0 to 3 (0 is primary master, 1 is primary slave, 2 is secondary master, 3 is secondary slave). Of course this also works with a1ide.device but a1ide.device will only report PIO modes.

- idetool reports/uses transfer modes as numbers, while the sil_xfer UBoot envvar takes letters. The match is as follows :

a - PIO 0 ( 3 MB/s, modeid 8)
b - PIO 1 ( 5 MB/s, modeid 9)
c - PIO 2 ( 8 MB/s, modeid 10)
d - PIO 3 ( 11 MB/s, modeid 11)
e - PIO 4 ( 16 MB/s, modeid 12)
A - UDMA 0 ( 16 MB/s, modeid 64)
B - UDMA 1 ( 25 MB/s, modeid 65)
C - UDMA 2 ( 33 MB/s, modeid 66)
D - UDMA 3 ( 44 MB/s, modeid 67)
E - UDMA 4 ( 66 MB/s, modeid 68)
F - UDMA 5 (100 MB/s, modeid 69)
G - UDMA 6 (133 MB/s, modeid 70)

- when enabling UDMA, first start at 'A' (or mode 64 if from idetool). Validate that you have no problem for a few days, then raise to next mode etc. Anyway, si680 wont allow you to set a mode that your drive does not support. But we have seen some drives which would not behave well at their max supported mode, in this case lower the mode to n-1.

- for normal use, the only sil_* envvar you should set is sil_xfer. Let si680ide find out by himself for all other things.

- a1ide uses the exact counter parts of sil_* uboot envvars, prefixed with 'ide_' instead of 'sil_'. This has one drawback : UBoot only knows ide_maxbus, wether you told him to use the VIA IDE (no 'ide' envvar) or the si680 IDE (setenv ide sii). Example : if you want both UBoot and si680ide.device to ignore the secondary IDE port of your si680 board, you have to set both ide_maxbus and sil_maxbus to 1, while a1ide would need only setting ide_maxbus.

- if you want to boot completely off the si680, at UBoot prompt, enter 'setenv ide sii' and then 'saveenv'. This way, UBoot will use your 2 si680 IDE ports as if they were the VIA's.

- this does not mean that OS4 is restricted to the si680, in this configration :
o OS4 will use the si680 ports if si680ide.device is in your kicklayout,
o OS4 will use the VIA ports if a1ide.device is in your kicklayout,
o si680ide.device and a1ide.device can work together without problem.

- if you dont have anything connected to the VIA IDE ports, or just dont want OS4 to use whatever is connected here, just drop a1ide.device from your kicklayout.

- same applies for the si680 IDE ports and si680ide.device.

2 - idetool
========
Enter 'c:idetool' and make sure you read the command templates, if you wonder why idetool does not do what you expect it to do.

Examples :
- to switch si680 primary master harddisk to UDMA100 (alias mode 69 or 'F'), enter 'idetool -x si680ide.device 0 69'

- to see what modes your primary master harddisk support and currently use, enter 'idetool -u si680ide.device 0'

Play with other commands, like putting your harddrive to sleep with 'idetool -p si680ide.device 0 2' (dont worry it wakes up automatically at next access). If you don't mess with -0, -1, -2 and -9 commands you cannot do much harm. Idetool can do many other things (including examining any PCI device, and patching its configuration in real time) but don't try that except you *know* what you are doing.

3 - VCORE
========
It appears that many A1's run with a wrong VCORE (the CPU core's supply voltage).

This affects stability (but lowers heat). It is a mistake on an information note that was given to Eyetech by the manufacturer, and it slipped through.

The stability issues are sometimes very rare and odd (ie they can appear only in OS4 and not in Linux, sometimes only with very recent kernels because recent kernels introduced the dynamic power management of the PPC). The only way to make sure that you wont face them, is to set your VCORE properly.

VCORE should be set as close as possible (but always below, never above) to nominal value as per Motorola / FreeScale specs for the exact processor model as written on the silicon die. The ONLY way to make sure what processor model you have is to remove the heatsink and fan, and look at what is written on the CPU silicon die.

Given that there is an exponential relationship between VCORE and heat, you have to make sure that you have adequate cooling before changing anything. Read below for what I did myself.

I take no responsibility for whatever consequence of your acts, beware, you can FRY your CPU if raising VCORE without adequate cooling, even if staying well below spec. Of course, NEVER go higher than spec.

The VCORE can be changed by setting the 4 dip switches next to the ATX Power Supply connector on the motherboard, and the JP17 jumper close to this dipswitch pad. Nothing is to change on the CPU daughterboard. Read that again.

The table below defines the VCORE from the setting of the 4 dipswitches and the JP17 jumper (taken from the MAI XE user manual) :

1 2 3 4 JP17 VCC_CORE
Off Off Off Off Short 1.34
On Off Off Off Short 1.39
Off On Off Off Short 1.44
On On Off Off Short 1.49
Off Off On Off Short 1.54
On Off On Off Short 1.59
Off On On Off Short 1.64
On On On Off Short 1.69
Off Off Off On Short 1.74
On Off Off On Short 1.79
Off On Off On Short 1.84
On On Off On Short 1.89
Off Off On On Short 1.94
On Off On On Short 1.99
Off On On On Short 2.04
On On On On Short 2.09
Off Off Off Off Open 1.244
On Off Off Off Open 2.14
Off On Off Off Open 2.24
On On Off Off Open 2.34
Off Off On Off Open 2.44
On Off On Off Open 2.54
Off On Off On Open 2.64
On On On Off Open 2.74
Off Off Off On Open 2.84
On Off Off On Open 2.94
Off On Off On Open 3.04
On On Off On Open 3.14
Off Off On On Open 3.24
On Off On On Open 3.34
Off On On On Open 3.44
On On On On Open 3.54

I will now only speak for the 7455/933 G4's, on the die of which is written XPC7455RX933PC, because I only know the values for that chip, I leave that to whoever to compile a list of the correct- and factory-set VCORE for all PPC's used on A1's . Appearently, all of the 7455/933's were delivered with a 1.59V VCORE, while the processor theoretically needs 1.84. This explains by the fact that there is another 7455/933, with a 'LC' suffix, which needs 1.6V.

If you have a XPC7455RX933PC (again the ONLY way to make sure is to remove the heatsink and fan, and look at what is written on the G4 die), you probably have the dipswitches set like this :

On Off On Off Short 1.59

In theory you should set them like this :

Off On Off On Short 1.84

My strong advice is to set them like this :

On Off Off On Short 1.79

Why just one step below ? because there is an exponential relationship between VCORE and heat, and our processor cooling equipment is weak.

On this topic, I strongly advise the G4 owners, to consider using an adequate cooling device for their processors. Some time ago, I compiled a few notes on what I did myself, find that at http://s.guillard.free.fr/OS4/Cooling

4 - Stability
=========

We developpers have been trying to help ourselves, then the betatesters, and now the broad community of earlybird owners, to fix stability problems.

It very often (more than you can imagine) comes down to those things, in high- to low-occurence order :

- incompatible memory stick. Symptom : whatever random behaviour. Solution : change for a memory stick delivered by an approved A1 dealer. Kingston buffered sticks seem to be a common working model.

- use of two memory sticks. Symptom : whatever random behaviour. Solution : remove all but the 1st.

- wrong VCORE (see above)

- bad IDE cabling (see si680ide releasenotes, URL above)

- insufficient CPU cooling (see cooling URL Labove)

- trying to use an UDMA mode that a drive claims to support but which it does not really. Solution : try the mode just below.

- motherboard battery worn out (the CR2032). Symptom : random behaviour as early as in UBoot. Solution : change the battery (it costs 5 Euro).

Those sentences are very 'straight to the point', but this is a direct first hand experience return, and every developer ran into at least one of those problems (myself, i had mostly all).

For instance, one reason which held the release of UDMA a1ide for months, was that I sometimes had 1 flipped bit, among more than 5 GB transferred.

I was *sure* that it was a DMA problem, so I chased it for months. In the end, someone suggested me to swap my RAM, I did, and voilà, it never happened ever since (but you know why i cannot release a1ide UDMA either...)

Everything in this mail is stated on my sole behalf, it is in no way an official statement from whoever else, nor Eyetech, nor Hyperion etc.

- I take no responsibilty to whatever consequence of whatever you do, those words above are only intended as helpful advices,

- raising VCORE up to nominal without adequate cooling can FRY your CPU,

- VCORE has nothing to do with overclocking, it has to be set close (but below and never above) to nominal value from Motorola / FreeScale processor specs,

- again, I only know the XPC7455RX933PC nominal VCORE value, for other PPC cores, find someone with trustworthy information,

- the ONLY way to make sure what PPC core you have is to remove the heatsink and fan, and look at what is written on the G4 die. Every letter and digit matters.

Hoping this helps,
Regards,
--
Stéphane Guillard

published: 22nd October 2004