[RFC PATCH 0/7] Hummingboard2 improvements

[Jon Nettleton]

On Mon, Jul 10, 2017 at 10:52 AM, Lucas Stach <l.stach at pengutronix.de> wrote:
> Hi Jon,
>
> Am Sonntag, den 09.07.2017, 06:42 +0200 schrieb Jon Nettleton:
>> On Sun, Jul 9, 2017 at 6:39 AM, Jon Nettleton <jon at solid-run.com> wrote:
>> >
>> >
>> >
>> > On Sat, Jul 8, 2017 at 3:59 PM, Russell King - ARM Linux <linux at armlinux.org.uk> wrote:
>> >>
>> >> On Sat, Jun 24, 2017 at 08:30:31AM +0100, Russell King - ARM Linux wrote:
>> >> > On Fri, Jun 23, 2017 at 06:15:14PM +0200, Lucas Stach wrote:
>> >> > > Hi Russell,
>> >> > >
>> >> > > it seems this is making no progress. If you don't mind I'm going to pick
>> >> > > up the patches from you hb2 branch and submit the whole series to Shawn,
>> >> > > so we can finally get things merged. Are you okay with this?
>> >> >
>> >> > If you remember from the reviews back in January of my patch set, Jon
>> >> > Nettleton promised to send me a replacement set of DT files that were
>> >> > properly licensed and updated along the lines of your patches in April.
>> >> > I'm still waiting...
>> >>
>> >> I've chased Jon a couple more times since (once today), and I'm feeling
>> >> that we're not getting anywhere.  I've now told him that we (SolidRun/
>> >> myself) are in danger of having this work replaced by others.  So, I'm
>> >> now adding Rabeeh to this thread.
>> >>
>> >>
>>
>> Besides the licensing there are still a number of bugs that exist for
>> the device-tree files as they stand.  Most notably using the standard
>> regulator code for the SDHC device causes a hang on reboot with some
>> UHS cards.
>
> What's the issue here? Is the bootloader not coming up, or does the
> kernel hang at boot?

it crashes the SDHC firmware because there isn't a long enough time
between power down at 1.8V and power-up at 3.3V.  The old framework
used to use card-external-vcc-supply which allowed enough time for the
card to fully reset.

>
>> Additionally we need to bring in the support for the SOM rev1.5 which
>> has been waiting on the TTY slave devices infrastructure to land.  We
>> have been trying to come up with a better solution than duplicating
>> all our device-tree files with a som revision however there doesn't
>> seem to be.  I would prefer to bring all the support in at once since
>> we are only shipping rev 1.5 soms at this point
>
> What's the difference between the old and new SoMs? Can we patch the DTs
> from the bootloader instead of introducing more variants?

Yes that is the new plan now that u-boot supports this.

>
> Frankly this whole situation is very bad. I have this Hummingboard2
> lying around for 1.5 years now, with no mainline support available. With
> the reasoning above it doesn't seem like this is going to change in the
> near future, as perfect is the enemy of good.
>

I will have new patches ready for -rc1.  Spoke with Russell on irc
last night and the plan is to only support the fully populated board
for each family.  Then we can use overlays in u-boot to disable /
enable devices for the variants.

We will also look into user-space probing for additional devices in
order to load add-on device fragments later on in boot, although that
is a topic for another discussion.

Without changing the structure of our device-tree files in mainline we
are looking at maintaining 20 just for iMX6, and that will only grow.
Not to mention customer boards etc.  The main question now is, where
do we store all the overlay fragments?

-Jon