On 31 July 2017 at 20:59, Alan Ott alan@softiron.com wrote:
On 07/31/2017 03:30 PM, Ard Biesheuvel wrote:
On 31 July 2017 at 18:39, Alan Ott alan@softiron.com wrote:
On 07/29/2017 06:23 AM, Ard Biesheuvel wrote:
On 29 July 2017 at 02:17, Alan Ott alan@softiron.com wrote:
Sorry I'm really late to this thread.
On 06/27/2017 09:21 AM, Ard Biesheuvel wrote:
The second SATA port is only available on B1 silicon, but as it turns out, not on /all/ versions of it: the Overdrive 3000 is B1 based as well, but any attempts to use the second SATA controller cause the firmware to crash. So just disable it.
This is not true. The SoftIron OverDrive 3000 has 14 SATA ports that all work. Did someone at SoftIron tell you this?
Interesting. Do they all work in UEFI as well?
Hi Ard,
We use the 2nd controller from Linux extensively.
Regarding use from within UEFI, this obviously doesn't get as much use by us as does using the drives from Linux (since as you might expect we typically boot from the first port), but I just now booted successfully from all 6 drives on the second controller using debug and release builds.
OK, interesting. I had the same experience on my B1, but flashing this one SoftIron 3000 to the open source firmware resulted in the crash I mentioned.
What I don't remember exactly is whether I updated the secure part as well, or only the EDK2 code and var partitions on the SPI flash.
I'm building OverdriveBoard.dsc configuration in OpenPlatformPkg and flashing Build/.../STYX_ROM.fd directly onto the SPI flash. I'm not rebuilding the secure part for any of this.
OK. But in my case, I may have flashed the 3000 board with the open source UEFI only, and kept whatever was in the secure partition.
I programmed the open source Overdrive firmware on a SoftIron box at the ARM office (Punit's), and it crashed in UEFI when trying to initialize the second SATA controller. The same code works fine on my non-SoftIron B1 Overdrive, so I wonder what the difference is.
I can't say for sure. If you have a bad unit, we'd be happy to help you with that.
I must admit disabling the second port was also useful in fixing the Gen1/2/3 setting in AmdSataInitLib, given that the PCD in question is 32-bits and so can only describe 8 ports. I suppose it makes sense to get to the bottom of that one first, though.
Are you talking about PcdSataPortMode? That's 16 bits wide, which I think is what you meant (8 ports * 2 bits is 16). We should increase the size to 32.
Indeed.
Did you simply revert that change? Or switch to Gen2 or Gen1?
I didn't change it. It works fine with that change, but only because 0xffff
n is still 0xffff.
Ah ok. But I thought you had identified that change as the source of a problem?