i played yesterday also with my setup i removed the sata pci card and connected my hd to the internal sata, first thing what happend was that the 460ex didnt boot even i changed the boot to sam460sata port. i did get the same error as what youll get, and i had the change the settings in uboot by multiboot os to choose from wich one it had to look for bootable devices.
ps if im using the internal sata i dont get the hdd led to work isnt it supported or so?
i tried even possible way to connect it to the sams motherboard. everything else was working.
nbache wrote: I had some time today to make my first tests with the Exsys EX-3506 card in the Sam460ex. I first tried simply switching the UBoot setting from Sata2 to PCIe and putting the HD cable on the first internal port of the card and booting from "SATA 3114 HD" (or whatever that setting is called, can't check it ATM).
No luck. So it seems UBoot/FLB cannot use devices on the card as boot sources.
Did you also change the jumper on the motherboard for switching between Sata2 and PCIe? You have to change both the UBoot setting, and the jumper.
In addition, you have to change the jumpers on the Exsys SATA card. I think, by default, the 4 external ports are jumpered to be used and then, no internal port can be used -- I can't remember that I have changed the jumper settings and (as I only need the external ports) I can use all 4 external ones for my devices. Check the manual!
Okay, I just had a moment to try again with the J16 jumper removed as well as the correct UBoot config (BTW, thanks, Hans, for the hint!).
It did make a difference, but not the one I'd hoped for.
After scanning the USB bus, UBoot said "SATA Device 0:..........* Timeout *" (the dots appeared progressively during scanning). When I then let it boot into WB from the SD card, Media Toolbox could not see (any devices on) the sii3114ide.device. A PCIscan showed three new devices:
Device #3:
Vendor: 0x2000 (Smart Link Ltd.)
Device: 0x0000 (Unknown)
Class code: 0x000000
RevisionID: 0x00
Interrupt: Line 0x00, Pin 0x00
Subsystem Vendor: 0x0000
Subsystem ID: 0x0000
Device #5:
Vendor: 0x1095 (Silicon Image, Inc.)
Device: 0x3114 (SiI 3114 [SATALink/SATARaid] Serial ATA Controller)
Class code: 0x010400
RevisionID: 0x02
Interrupt: Line 0x00, Pin 0x01
Subsystem Vendor: 0x1095
Subsystem ID: 0x7114
Resource range #0 (IO)
Base address: 0x00002000
Physical address: 0x00002000
Size: 0x00000008
Resource range #1 (IO)
Base address: 0x00002008
Physical address: 0x00002008
Size: 0x00000008
Resource range #2 (IO)
Base address: 0x00002010
Physical address: 0x00002010
Size: 0x00000008
Resource range #3 (IO)
Base address: 0x00002018
Physical address: 0x00002018
Size: 0x00000008
Resource range #4 (IO)
Base address: 0x00002020
Physical address: 0x00002020
Size: 0x00000010
An "idetool -l sii3114ide.device" says "*** Error opening device sii3114ide.device / unit 0" and the same for all 16 units.
"idetool -b" prints a dump of hex bytes which is useless to me, but part of it does look like it finds a controller which makes some sense to it:
----------SiI3114 PCI IDE Configuration--------------------
PCI Revision : $2
PCI Class code : $2
PCI Cacheline size : $1
IDE0 prim IO base : $00002000
IDE0 alt. IO base : $0000200A
IDE1 prim IO base : $00002010
IDE1 alt. IO Revision : $0000201A
Busmater cntr. IO base: $00002020
Mem. mapped reg. base : $C0000000
So although the card is somewhat visible from both UBoot and AmigaOS, I have no idea if it could be made to actually work. I suspect both UBoot and the sii3114 driver need some sort of update to enable them to work with the known chip in an unknown context - or whatever .
Anybody more informed about the technicalities is welcome to chime in (where's Olegil when we need him? ).
The sii3114ide.device should not need any changes in order to use it, provided that that the intervening bridge chips are correctly set up. The sii3114 is a PCI device, so if it is on a PCI-Express card, then there has to be a PCI-to-PCIe bridge on-board too.
It probably will take a UBoot update to properly initialise the Texas Instruments PCIe to PCI/PCI-X bridge. I have no idea what the Smart Link Limited device is (and a device ID of 0x0000 is rather suspicious).
The main reason that I suspect the bridge setup, is because that's what initially held up my RadeonHD driver development (PCI RadeonHD cards are PCIe devices behind a PCI-to-PCIe bridge). The A1-XE's UBoot will detect devices behind a bridge, but then fail to enable the bridge in order to use it. For a while this had me confused as to why the card wouldn't respond.
It might also be worth checking to see if the card's IO and Mem spaces have been enabled. Ranger will tell you this.
Since sii3114 drivers already exist, fixing UBoot to handle this would probably be the fastest way to get a "PCIe" SATA card supported.
NOTE: The TI bridge is the XIO2000 (datasheet available here).
The main reason that I suspect the bridge setup, is because that's what initially held up my RadeonHD driver development (PCI RadeonHD cards are PCIe devices behind a PCI-to-PCIe bridge). The A1-XE's UBoot will detect devices behind a bridge, but then fail to enable the bridge in order to use it. For a while this had me confused as to why the card wouldn't respond.
Yes, I remember the discussions about this back when the A1s were new. But I thought that had been solved in UBoot for the Sam460ex. If not, will anything ever work in that PCIe x1 slot, or is it sitting there in vain? Maybe it is supported under Linux? I don't have Linux on this machine, so I can't check.
Quote:
It might also be worth checking to see if the card's IO and Mem spaces have been enabled. Ranger will tell you this.
Actually, I think idetool already told me this (except I don't understand what it's talking about ). The full output of "idetool -b" follows, including the hex bits I omitted above:
Ranger shows (among other things) six Resource Ranges (#0-#5) at the bottom of the info page for the RAID controller (the 3114). Five with the flags "I/O" and the sixth with the flag "Mem" - are those what you are referring to?
Quote:
Since sii3114 drivers already exist, fixing UBoot to handle this would probably be the fastest way to get a "PCIe" SATA card supported.
Okay. We'll have to make somebody an offer they can't refuse, I suppose . I wonder if the loan of one of my cards would constitute such an offer.
Quote:
NOTE: The TI bridge is the XIO2000 (datasheet available here).
So that's the thing that needs some sort of initialization or enabling from UBoot in order to make it allow (more?) access to the stuff behind it? I'm a bit confused, because if I understand the data I see from the various tools, the system (both UBoot and AmigaOS) does see the SiI3114, but it's still the bridge in front of it that blocks in some way?
it is a sort of hub that should work it only mulitply the sata connectors en uses i 1 as a host.
what do you think?
It is highly unlikely to work. Port multipliers such as that require the drivers/OS to be aware of it (think back to those A1200 IDE port splitters). Since no-one has used such a device with their Amiga before, I doubt that the driver support for it exists.
nbache wrote: Yes, I remember the discussions about this back when the A1s were new. But I thought that had been solved in UBoot for the Sam460ex. If not, will anything ever work in that PCIe x1 slot, or is it sitting there in vain? Maybe it is supported under Linux? I don't have Linux on this machine, so I can't check.
I don't know if it was solved or not, but the PCI-to-PCIe bridges on the RadeonHD card are not the TI one on your card. So, UBoot might not know exactly what to do with the TI bridge.
This totally doesn't affect the operation of true PCIe cards. True PCIe cards don't have a PCI-to-PCIe bridge in the way, and so should work. However, we currently have very few drivers for PCIe devices.
I don't know if the Linux drivers will be able to work with the device if UBoot doesn't initialise the bridges properly. Generally drivers assume that the BIOS has done its bit.
Quote:
Ranger shows (among other things) six Resource Ranges (#0-#5) at the bottom of the info page for the RAID controller (the 3114). Five with the flags "I/O" and the sixth with the flag "Mem" - are those what you are referring to?
Yes, those flags are what I'm referring to. If those flags are cleared, then the card will ignore any I/O or memory (or MMIO) access attempts.
Quote:
Quote:
Since sii3114 drivers already exist, fixing UBoot to handle this would probably be the fastest way to get a "PCIe" SATA card supported.
Okay. We'll have to make somebody an offer they can't refuse, I suppose . I wonder if the loan of one of my cards would constitute such an offer.
Maybe. You'll need to find the right person to loan it too.
Quote:
Quote:
NOTE: The TI bridge is the XIO2000 (datasheet available here).
So that's the thing that needs some sort of initialization or enabling from UBoot in order to make it allow (more?) access to the stuff behind it? I'm a bit confused, because if I understand the data I see from the various tools, the system (both UBoot and AmigaOS) does see the SiI3114, but it's still the bridge in front of it that blocks in some way?
Going back to the Radeon HD bridge problems, Ranger and AmigaOS could also "see" the Radeon HD chipset behind the bridge, but were unable to access it. This is because UBoot detected its presence, and told AmigaOS that it was there. However, it didn't set up the bridge properly, so actual access wasn't possible. As a result, Picasso96 includes code to set up any bridges that are in the way of graphics cards.
Come to think of it, I have a little BridgeDump utility that might help figure out what's going on. I'll send it to you sometime today.
When I then let it boot into WB from the SD card, Media Toolbox could not see (any devices on) the sii3114ide.device. A PCIscan showed three new devices:
Device #3:
Vendor: 0x2000 (Smart Link Ltd.)
Device: 0x0000 (Unknown)
Class code: 0x000000
RevisionID: 0x00
Interrupt: Line 0x00, Pin 0x00
Subsystem Vendor: 0x0000
Subsystem ID: 0x0000
Device #5:
Vendor: 0x1095 (Silicon Image, Inc.)
Device: 0x3114 (SiI 3114 [SATALink/SATARaid] Serial ATA Controller)
Class code: 0x010400
RevisionID: 0x02
Interrupt: Line 0x00, Pin 0x01
Subsystem Vendor: 0x1095
Subsystem ID: 0x7114
Resource range #0 (IO)
Base address: 0x00002000
Physical address: 0x00002000
Size: 0x00000008
Resource range #1 (IO)
Base address: 0x00002008
Physical address: 0x00002008
Size: 0x00000008
Resource range #2 (IO)
Base address: 0x00002010
Physical address: 0x00002010
Size: 0x00000008
Resource range #3 (IO)
Base address: 0x00002018
Physical address: 0x00002018
Size: 0x00000008
Resource range #4 (IO)
Base address: 0x00002020
Physical address: 0x00002020
Size: 0x00000010
An "idetool -l sii3114ide.device" says "*** Error opening device sii3114ide.device / unit 0" and the same for all 16 units.
16 units? Actually, the card has 4 units and, thus, only unit 0 to 3 should be usable.
Quote:
"idetool -b" prints a dump of hex bytes which is useless to me, but part of it does look like it finds a controller which makes some sense to it:
----------SiI3114 PCI IDE Configuration--------------------
PCI Revision : $2
PCI Class code : $2
PCI Cacheline size : $1
IDE0 prim IO base : $00002000
IDE0 alt. IO base : $0000200A
IDE1 prim IO base : $00002010
IDE1 alt. IO Revision : $0000201A
Busmater cntr. IO base: $00002020
Mem. mapped reg. base : $C0000000
So although the card is somewhat visible from both UBoot and AmigaOS, I have no idea if it could be made to actually work. I suspect both UBoot and the sii3114 driver need some sort of update to enable them to work with the known chip in an unknown context - or whatever .
Anybody more informed about the technicalities is welcome to chime in (where's Olegil when we need him? ).
nbache: I can compare tonight the output with my own card. As I said it works perfectly for me. However, since I only use the external ports, I use 'GiggleDisk' (check Aminet) for mounting my 2TB hardisk. So, maybe, you also can try and check this tool. In addition, if you have a eSATA-to-Sata cable, try if the external ports work. Dunno if that makes a differnence, but well, a it's worth a try.
as AOS4 betatester, do you have access to the sam3114ide.device ? The sam3114ide.device (not to be confused with the sii3114ide.device) uses MMIO instead of IO and there are better chances it could work on a Sam460ex.
as AOS4 betatester, do you have access to the sam3114ide.device ?
It doesn't look like it, no. Maybe it was only released to developers or something?
Quote:
The sam3114ide.device (not to be confused with the sii3114ide.device) uses MMIO instead of IO and there are better chances it could work on a Sam460ex.
An "idetool -l sii3114ide.device" says "*** Error opening device sii3114ide.device / unit 0" and the same for all 16 units.
16 units? Actually, the card has 4 units and, thus, only unit 0 to 3 should be usable.
Yes, but idetool will always loop through 16 devices, even if some of them aren't there (lazy programmer, I guess ).
Quote:
nbache: I can compare tonight the output with my own card. As I said it works perfectly for me. However, since I only use the external ports, I use 'GiggleDisk' (check Aminet) for mounting my 2TB hardisk. So, maybe, you also can try and check this tool. In addition, if you have a eSATA-to-Sata cable, try if the external ports work. Dunno if that makes a differnence, but well, a it's worth a try.
Definitely.
I'll have to get a cable and check the external ports out. And GiggleDisk is of course also worth a shot, although I'd have thought it should technically only be seeing what we see with other tools as well. Is your eSATA disk formatted with an Amigaoid file system, or with FAT?
@nbache Going back to the Radeon HD bridge problems, Ranger and AmigaOS could also "see" the Radeon HD chipset behind the bridge, but were unable to access it. This is because UBoot detected its presence, and told AmigaOS that it was there. However, it didn't set up the bridge properly, so actual access wasn't possible. As a result, Picasso96 includes code to set up any bridges that are in the way of graphics cards.
Yes, that sounds like a very similar situation. But if every driver has to include such code, it would seem to be better to have UBoot do the setup in the first place.
Quote:
Come to think of it, I have a little BridgeDump utility that might help figure out what's going on. I'll send it to you sometime today.
@nbache Going back to the Radeon HD bridge problems, Ranger and AmigaOS could also "see" the Radeon HD chipset behind the bridge, but were unable to access it. This is because UBoot detected its presence, and told AmigaOS that it was there. However, it didn't set up the bridge properly, so actual access wasn't possible. As a result, Picasso96 includes code to set up any bridges that are in the way of graphics cards.
Yes, that sounds like a very similar situation. But if every driver has to include such code, it would seem to be better to have UBoot do the setup in the first place.
Yes, it's much better if UBoot (or whatever the firmware is) correctly initialised the hardware in the first place. The Picasso96 bridge handling code is a workaround put in place because the UBoot bug exists, and may not be fixed for a while (if ever, the A1-XE is getting old).
sorry, was too late yesterday when I finally arrived home. Work is occupying me completely at the moment :( I'll try tonight again :)
Quote:
I'll have to get a cable and check the external ports out. And GiggleDisk is of course also worth a shot, although I'd have thought it should technically only be seeing what we see with other tools as well. Is your eSATA disk formatted with an Amigaoid file system, or with FAT?
Actually, it is formated meanwhile with several ext2 partitions. But i also tested the HD in the beginning with Fat32 and, I think, SFS2. No problems here. I could mount every partition with GiggleDisk.
Pardon me for interrupting this thread, but seriously, is it really necessary for you to keep rubbing into peoples faces "I have two x1000`s" at every possible giving opportunity?
I can always do one better than you but I wont.
One of these days Karma is going to hit you right back in the ass if you keep on saying that, im just saying:)