Minix3 and modern chipsets

[Max]

Hi,

a friend of mine played quite extensively with Minix in the last months and he found a couple of things, where I just want to double check you (the list) the first thing he talked about:

Its not possible to install on recent bare metal hardware, you can try it quite quickly. If you have a minix instance running in VirtualBox, all you have to do is to change the chipset from PIIX3 to ICH9 and the system complaints with 

'at_wini(65553): panic: no matching device found 

...

Request 0x700 to RS failed: specified endpoint is not alive (error 215). '

Before you tell me to try it out with AHCI, its exactly the same case the only difference is ahci stands in front of the first error message instead of at_wini. I think, its quite a pity as even ICH9 comes out 2007 and today more or less every more or less recent platform is not working. Do not get me wrong, its no offense, we are also happy to contribute essential parts. But I think, we (the list) should at least collect every shortcoming one of us is aware of. Otherwise its quite frustrating to give minix a try and find out after several hours/days/weeks, its not usable. My friend also tried to make it bootable on an alix, which is a Geode based headless SBC. He prepared already the script to create an image, but its running into the same error as virtualbox. The chipset used on alix is a "AMD Geode CS5536".

I think making Minix run on more recent x86 platforms would be a huge step towards trying Minix out. What do we need to make it run on let's say a recent intel chipset like an Intel Board D54250WYB beside from 64 bit support? Another question would be also what's needed from your point of view whats needed to make an alix work?

brgds,

Max

[Antoine LECA]

On 2014-12-01 09:33Z, Max wrote:
> But I think, we (the list) should at least collect every shortcoming one of
> us is aware of.

Isn't it the role of the wiki?
I mean, I guess it is more useful to document those "shortcoming" in the
wiki which is supposed to be the place where one checks (early) about
hardware requisites, than to ask people to search this list (which
furthermore would show a number of obsolete and false warnings.)

> He prepared already the script to create an image, but its running into the
> same error as virtualbox. The chipset used on alix is a "AMD Geode CS5536".

The problem is with the disk PCI device not being recognized.
IIUC, the at_disk driver raises that message when there are no device of
class 1 (mass storage) subclass 1 (IDE), and similarly the ahci driver
complains when there are no device of class 1 subclass 6 (AHCI)

I guess you need to dump the PCI identifiers and classes for the disk
interface (using whatever other OS you can boot), and the messages you
get if you add
pci_debug=1
at the end of the boot command (enter "edit" mode.)

> I think making Minix run on more recent x86 platforms would be a huge step
> towards trying Minix out.

I was understanding the trend was moved and MINIX now aims at the
embedded market and particularly the ARM platforms. Also the rate of
evolution of the "x86 platforms" might easily overcome the resources.


Antoine

[Max]

Hi Antoine,

On Monday, December 1, 2014 3:55:27 PM UTC+1, AntoineLeca wrote:

On 2014-12-01 09:33Z, Max wrote:
> But I think, we (the list) should at least collect every shortcoming one of
> us is aware of.

Isn't it the role of the wiki?
I mean, I guess it is more useful to document those "shortcoming" in the
wiki which is supposed to be the place where one checks (early) about
hardware requisites, than to ask people to search this list (which
furthermore would show a number of obsolete and false warnings.)

Its exactly, what I intended. Sorry being not precisely as needed. I will add a section to the hardware requirements.

 

> He prepared already the script to create an image, but its running into the
> same error as virtualbox. The chipset used on alix is a "AMD Geode CS5536".

The problem is with the disk PCI device not being recognized.
IIUC, the at_disk driver raises that message when there are no device of
class 1 (mass storage) subclass 1 (IDE), and similarly the ahci driver
complains when there are no device of class 1 subclass 6 (AHCI)

I guess you need to dump the PCI identifiers and classes for the disk
interface (using whatever other OS you can boot), and the messages you
get if you add
        pci_debug=1
at the end of the boot command (enter "edit" mode.)

Unfortunately, the pci_debug is not helpful at all:

PCI: do_first_dev: no acl for caller 65551

PCI: do_acl: setting ACL for 65553 ('at_wini_0') at entry 0

I assume the problem starts before looking for mass storage device?

I booted debian on the system (alix) and I got the following information:

# lspci -vmm

Slot:   00:01.0

Class:  Host bridge

Vendor: Advanced Micro Devices [AMD]

Device: CS5536 [Geode companion] Host Bridge

SVendor:        Advanced Micro Devices [AMD]

SDevice:        CS5536 [Geode companion] Host Bridge

Rev:    33

....

Slot:   00:0f.0

Class:  ISA bridge

Vendor: Advanced Micro Devices [AMD]

Device: CS5536 [Geode companion] ISA

SVendor:        Advanced Micro Devices [AMD]

SDevice:        CS5536 [Geode companion] ISA

Rev:    03

Slot:   00:0f.2

Class:  IDE interface

Vendor: Advanced Micro Devices [AMD]

Device: CS5536 [Geode companion] IDE

SVendor:        Advanced Micro Devices [AMD]

SDevice:        CS5536 [Geode companion] IDE

Rev:    01

ProgIf: 80

...

I left out a the Ethernet, USB and encryption devices for a better readability.

I did not find a shell tool to get the ide bus too. Nevertheless, its strange as I see the following:

# cat /proc/scsi/scsi 

Attached devices:

Host: scsi0 Channel: 00 Id: 00 Lun: 00

  Vendor: ATA      Model: CF CARD 1GB      Rev: 2007

  Type:   Direct-Access                    ANSI  SCSI revision: 05

 

> I think making Minix run on more recent x86 platforms would be a huge step
> towards trying Minix out.

I was understanding the trend was moved and MINIX now aims at the
embedded market and particularly the ARM platforms. Also the rate of
evolution of the "x86 platforms" might easily overcome the resources.

Its not up to me to direct the future of Minix. I think Intel is making huge steps towards embedded systems and its from my point of view more easy to target x86 hardware than all of the different ARM CPU dialects and chipsets out there in the wild.

brgds,

Max 

[Antoine LECA]

On 2014-12-02 11:08Z, Max wrote:
>> The problem is with the disk PCI device not being recognized.
>> IIUC, the at_disk driver raises that message when there are no device of
>> class 1 (mass storage) subclass 1 (IDE), and similarly the ahci driver
>> complains when there are no device of class 1 subclass 6 (AHCI)
>>
>> I guess you need to dump the PCI identifiers and classes for the disk
>> interface (using whatever other OS you can boot), and the messages you
>> get if you add
>> pci_debug=1
>> at the end of the boot command (enter "edit" mode.)
>
> Unfortunately, the pci_debug is not helpful at all:
>
> PCI: do_first_dev: no acl for caller 65551
> PCI: do_acl: setting ACL for 65553 ('at_wini_0') at entry 0
>
> I assume the problem starts before looking for mass storage device?

I left it to the knowledgeable people, but I believe there is enough
information to know where the problem is.
I guess the call to PCI_first_dev is issued by the at_wini driver (in
w_probe) when it initializes; and it found no ACL set up, which ought to
have been done earlier (by RS, in manager.c:init_slot()) when it reads
and maps the authorization.
More debugging can be further done adding rs_verbose=1, but you will
likely be flooded by the amount of data, unless you can set up a serial
line and a terminal to grab the output.
Sorry to not be able to help more, I have no idea of that part of MINIX.

By the way, which build are you using?

> I booted debian on the system (alix) and I got the following information:
>
> # lspci -vmm

> ....
> Slot: 00:0f.0
> Class: ISA bridge
> Vendor: Advanced Micro Devices [AMD]
> Device: CS5536 [Geode companion] ISA
> SVendor: Advanced Micro Devices [AMD]
> SDevice: CS5536 [Geode companion] ISA
> Rev: 03
>
> Slot: 00:0f.2
> Class: IDE interface
> Vendor: Advanced Micro Devices [AMD]
> Device: CS5536 [Geode companion] IDE
> SVendor: Advanced Micro Devices [AMD]
> SDevice: CS5536 [Geode companion] IDE
> Rev: 01
> ProgIf: 80
>
> ...

Pretty printed output but it leaves the important data which are the
numbers :-( Anyway I can guess the class is indeed 0101 which should be
OK for the at_wini driver, at least according to system.conf(5)

service at_wini
{
io 1f0:8 # Controller 0
3f6 # Also controller 0
170:8 # Controller 1
376 # Also controller 1
;
irq
14 # Controller 0
15 # Controller 1
;
system
UMAP # 14
IRQCTL # 19
DEVIO # 21
SDEVIO # 22
VDEVIO # 23
;
pci class # Match these PCI classes:
1/1 # Mass storage / IDE
;
pci device # In addition, match these devices:
1106:3149 # VIA VT6420 RAID (1/4)
1095:3512/1095:6512 # Silicon Image SATA RAID (1/4)
1095:3114/1095:3114 # Silicon Image SATA RAID (1/80)
;
};

which is unchanged since October 2013 change which improved the PCI
support for the "AT disk" driver. BTW, David, I guess the io and irq
sections are now unnecessary, ain't they?

I notice that the previous version had more classes:
1/80 # Mass storage / Other (80 hex)
1/4 # Mass storage / RAID
and I feel the change (to only deal with IDE) is correct, but perhaps
there are some glitch here?

> I did not find a shell tool to get the ide bus too. Nevertheless, its
> strange as I see the following:
>
> # cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: ATA Model: CF CARD 1GB Rev: 2007
> Type: Direct-Access ANSI SCSI revision: 05

Perhaps the "normal" result of Linux having a "merged" ATA+SCSI driver?


Antoine

[David van Moolenbroek]

Hey Antoine, all,

On Tuesday, December 2, 2014 12:46:03 PM UTC+1, AntoineLeca wrote:

On 2014-12-02 11:08Z, Max wrote:
> Unfortunately, the pci_debug is not helpful at all:
>
> PCI: do_first_dev: no acl for caller 65551
> PCI: do_acl: setting ACL for 65553 ('at_wini_0') at entry 0
>
> I assume the problem starts before looking for mass storage device?

I left it to the knowledgeable people, but I believe there is enough
information to know where the problem is.

So far our discussion on IRC led to the conclusion that the PCI driver cannot find the PCI bus at all; otherwise it would dump all the devices on it as part of pci_debug=1. Unfortunately I do not know what could cause this; whether it is just a bug in the PCI driver or that these newer platforms require a much better integration with ACPI or whatnot..

BTW, David, I guess the io and irq
sections are now unnecessary, ain't they?

I'm afraid not - as I found out the hard way, there is no guarantee that compatibility-mode IDE controllers have all their resources in their PCI record, so those still require hardcoding..

I notice that the previous version had more classes:
                1/80                        # Mass storage / Other (80 hex)
                1/4                        # Mass storage / RAID
and I feel the change (to only deal with IDE) is correct, but perhaps
there are some glitch here?

Just to clarify: the 1/80 and 1/4 classes were previously there just so that a small number of whitelisted devices in those classes could be recognized. The same set of devices is now whitelisted by vid:did(/sub) instead. All other devices in the two classes were always ignored, and still are. In general, especially 1/4 is a major pain in terms of choosing the right driver to start (at_wini or ahci), but that's another story..

Regards,
David

[Max]

That's a fast reply! :)

On Tuesday, December 2, 2014 12:46:03 PM UTC+1, AntoineLeca wrote:

 

I left it to the knowledgeable people, but I believe there is enough
information to know where the problem is.
I guess the call to PCI_first_dev is issued by the at_wini driver (in
w_probe) when it initializes; and it found no ACL set up, which ought to
have been done earlier (by RS, in manager.c:init_slot()) when it reads
and maps the authorization.

I fear, PCI is not up and running at all so far? 

service pci

{

        io      cf8:8           # PCI bus controller

                4d0:2           # PIIX

        ;

        system

                PRIVCTL         #  4

                DEVIO           # 21

        ;

        uid 0;

};

contains PIIX specific io address and I just try to find out whether its valid for ICH9 and the geode chipset at all.

 # lspci -b -n -v

// Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge

00:01.0 0600: 1022:2080 (rev 33)

        Subsystem: 1022:2080

        Flags: bus master, 66MHz, medium devsel, latency 248

        I/O ports at ac1c

// ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03)

00:0f.0 0601: 1022:2090 (rev 03)

        Subsystem: 1022:2090

        Flags: 66MHz, medium devsel

        I/O ports at 6000

        I/O ports at 6100

        I/O ports at 6200

        I/O ports at <unassigned>

        I/O ports at 9d00

        I/O ports at 9c00

        Kernel driver in use: cs5535-mfd

// IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01) (prog-if 80 [Master])

00:0f.2 0101: 1022:209a (rev 01) (prog-if 80 [Master])

        Subsystem: 1022:209a

        Flags: bus master, 66MHz, medium devsel, latency 248

        I/O ports at ff00

        Kernel driver in use: pata_amd

maybe, it helps already?

More debugging can be further done adding rs_verbose=1, but you will
likely be flooded by the amount of data, unless you can set up a serial
line and a terminal to grab the output.
Sorry to not be able to help more, I have no idea of that part of MINIX.

serial is up and running the whole time, my only chance to get the output I pasted so far :) I wll try it.

 

By the way, which build are you using?

used the release.sh on Friday and used the git master branch, so more or less recently.

 

Pretty printed output but it leaves the important data which are the
numbers :-( Anyway I can guess the class is indeed 0101 which should be
OK for the at_wini driver, at least according to system.conf(5)

    service at_wini
    {
        io        1f0:8                # Controller 0
                3f6                # Also controller 0
                170:8                # Controller 1
                376                # Also controller 1
        ;
        irq
                14                # Controller 0
                15                # Controller 1
        ;
        system
                UMAP                # 14
                IRQCTL                # 19
                DEVIO                # 21
                SDEVIO                # 22
                VDEVIO                # 23
        ;
        pci class                # Match these PCI classes:
                1/1                        # Mass storage / IDE
        ;
        pci device                # In addition, match these devices:
                1106:3149                # VIA VT6420 RAID (1/4)
                1095:3512/1095:6512        # Silicon Image SATA RAID (1/4)
                1095:3114/1095:3114        # Silicon Image SATA RAID (1/80)
        ;
    };

verified it, the class is indeed 1/1. 

Slot:   00:0f.2

Class:  0101

Vendor: 1022

Device: 209a

SVendor:        1022

SDevice:        209a

Rev:    01

ProgIf: 80

brgds,

Max

 

[Max]

Hi Antoine,

the problem is found, now I'm looking for a solution (should not be so hard now). The pci_intel_init() checks only once and returns. So, the PCI bus is not initialized at all. 

brgds,

Max

in /usr/src/minix/drivers/bus/pci/pci.c: 

        vid= PCII_RREG16_(bus, dev, func, PCI_VID);

        did= PCII_RREG16_(bus, dev, func, PCI_DID);

        if (OK != (s=sys_outl(PCII_CONFADD, PCII_UNSEL)))

                printf("PCI: warning, sys_outl failed: %d\n", s);

        if (vid == 0xffff && did == 0xffff)

                return; /* Nothing here */

On Tuesday, December 2, 2014 12:46:03 PM UTC+1, AntoineLeca wrote:

[Max]

Do not know, what the change will break, but deleting the two lines

if (vid == 0xffff && did == 0xffff)

      return;

make everything work now!

Thank you all for your support,

Max