[RFC][TRUSTY] X-Gene platform support

[Tim Gardner]

On 03/20/2014 06:48 PM, Dann Frazier wrote:
> On Thu, Mar 20, 2014 at 5:48 PM, Tim Gardner <tim.gardner at canonical.com> wrote:
>> On 03/18/2014 01:15 AM, Dann Frazier wrote:
>>>
>>> On Fri, Mar 14, 2014 at 1:12 PM, Dann Frazier
>>> <dann.frazier at canonical.com> wrote:
>>>>
>>>> On Thu, Mar 13, 2014 at 8:22 AM, Tim Gardner <tim.gardner at canonical.com>
>>>> wrote:
>>>>>
>>>>> On 03/11/2014 12:15 PM, Dann Frazier wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>     I've assembled a git tree with support for the X-Gene platform:
>>>>>>
>>>>>> git://kernel.ubuntu.com/dannf/trusty-xgene.git for-ubuntu-20140310
>>>>>>
>>>>>> The PCI changes in the above are fairly significant and still under
>>>>>> upstream review. I've therefore provided a separate branch with these
>>>>>> changes backed out and replaced with an earlier version of the host
>>>>>> controller driver, with fewer dependencies:
>>>>>>
>>>>>> git://kernel.ubuntu.com/dannf/trusty-xgene.git
>>>>>> for-ubuntu-20140310-oldpci
>>>>>>
>>>>>
>>>>> Ugh! Even with the PCI reverts there are some questionable patches wrt
>>>>> to
>>>>> maintenance and stability.
>>>>
>>>>
>>>> Though, other than SATA and PCI, I think the drivers are pretty well
>>>> self-contained,
>>>> so hopefully are low risk for other platforms. And we're certainly
>>>> down for tracking
>>>> upstream progress and updating them over time.
>>>>
>>>>> I could _probably_ accept the ahci_platform patches since they are
>>>>> already
>>>>> in linux-next and will likely make it into 3.15 (though I'll remind you
>>>>> that
>>>>> I _really_ like to just cherry-pick the final patch from Linus' repo).
>>>>> Are
>>>>> the "Library-ise" patches necessary ?
>>>>>
>>>>> My knee jerk reaction is a NAK to all of the KVM patches. They appear to
>>>>> be
>>>>> a work in progress and likely won't even make the 3.15 merge window.
>>>>>
>>>>> Likewise with "arm64: PCI(e) arch support". A work in progress that is
>>>>> unlikely to make 3.15.
>>>>>
>>>>> Instead of removing the X-Gene reboot driver, can't we just disable the
>>>>> config ? Its a bit less churn and we won't have to resolve the conflict
>>>>> in
>>>>> future kernels.
>>>>
>>>>
>>>> Seems like that should work, but it didn't in my testing - system hangs
>>>> on reset
>>>> even though:
>>>>     # CONFIG_POWER_RESET_XGENE is not set
>>>>     CONFIG_POWER_RESET_SYSCON=y
>>>> I'll investigate why, but probably not until Monday.
>>>>
>>>>> What is the current state of the X-gene SOC ? I see that we already have
>>>>> DTB
>>>>> files for mustang and storm. Do they already boot and have networking ?
>>>>
>>>>
>>>> With the current Ubuntu kernel, they can boot, but not into userspace
>>>> (no disk, no networking).
>>>>
>>>> fyi, I've updated my branch:
>>>>
>>>> git://kernel.ubuntu.com/dannf/trusty-xgene.git for-ubuntu-20140314
>>>>
>>>> This pulls in the KVM changes from linux-next (I assume its no
>>>> different than what
>>>> you have), and also updates to the latest submitted version of the SATA
>>>> driver.
>>>>
>>>> There's a few other experiments in it - no longer reverting the
>>>> RESET_XGENE driver
>>>> (as mentioned above), and making QMTM & NET_XGENE both modules. Neither
>>>> seems to be working well.
>>>
>>>
>>> Whups, I was apparently testing with the wrong .dtb. I've verified
>>> that it *is* safe to keep
>>> xgene_qmtm and xgene_enet as modules, so I recommend:
>>>
>>> CONFIG_AHCI_XGENE=m
>>> CONFIG_NET_XGENE=m
>>> CONFIG_PCI_XGENE=y
>>> CONFIG_PHY_XGENE=y
>>> CONFIG_RTC_DRV_XGENE=y
>>> CONFIG_XGENE_QMTM=m
>>>
>>> Also, it is safe to disable CONFIG_POWER_RESET_XGENE and keep the
>>> driver in place.
>>>
>>> Sorry for the confusion.
>>>
>>
>> I think I've got everything merged to master-next with the following config
>> settings:
>>
>> CONFIG_AHCI_XGENE=m
>> CONFIG_ARCH_XGENE=y
>> CONFIG_COMMON_CLK_XGENE=y
>> CONFIG_NET_XGENE=m
>> CONFIG_PCI_XGENE=y
>> CONFIG_PHY_XGENE=m
>>
>> # CONFIG_POWER_RESET_XGENE is not set
>> CONFIG_RTC_DRV_XGENE=m
>> CONFIG_XGENE_QMTM=m
>
> Thanks Tim!
>
> For config, I think we need both PHY and RTC statically linked.
> PHY isn't automatically loaded by udev, causing the SATA module
> to fail. As for RTC, I believe this is normally statically linked for
> all platforms,
> so that the system clock can be set early in boot by the hctosys driver.
> Otherwise hctosys bails with:
>
> [    1.258714] /tmpfs/linux-3.13.0/drivers/rtc/hctosys.c: unable to
> open rtc device (rtc0)
>
> This is needed in early boot to compare mount times of the root
> device, etc - and
> also needed for MAAS to be able to validate certificates (though it has some
> approximation code these days). You might say, well why not put it in
> the initramfs?
> I think there's a reason that is insufficient, but I don't remember
> what it is. For right
> now I'll just wave my hands and say it doesn't work today
> (initramfs-tools doesn't
> include the rtc driver by default), and rest on precedent for other platforms:
>
> armhf/highbank: CONFIG_RTC_DRV_PL031=y
> x86: CONFIG_RTC_DRV_CMOS=y
>
> And the note in "annotations" that says the latter is "boot essential".
>
> I'll test the other functionality once the PHY issue is resolved
> (can't boot w/o it).
>
> fyi, I think ab8d0329067ae97e0d7fb22727a8a9070eb09bd3 is good - Tanmay
> submitted a new rev of his upstream-targeted driver today, and it had the same
> change versus the previous. Feel free to squash this into the
> xgene-pci commit if
> you like.
>
> Oh, and while you're at it, mind adding these modules to the udebs?
>
> ahxi_xgene.ko ? -> sata-modules
> xgene-enet ? -> nic-modules
>
> qmtm will be automatically picked up by kernel-wedge.
>

Changed the config settings and added the suggested modules to d-i.

-- 
Tim Gardner tim.gardner at canonical.com