[GIT PULL] ARM: mvebu: DT changes for v3.17

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Jason Cooper]

Guys,

It's a pretty slow cycle this time around, so here's what I have so far.
Nothing controversial, just putting the last nail in the coffin for
mach-kirkwood/ . :-)

Please pull.

thx,

Jason.

The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:

  Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-3.17

for you to fetch changes up to d854fa8a1500bec982ed9cb26b82d96bd5ae8dab:

  ARM: kirkwood: fix net5big regulator gpio assignments (2014-06-21 19:21:13 +0000)

----------------------------------------------------------------
mvebu DT changes for v3.17

 - kirkwood
    - add boards net2big and net5big

 - dove
    - add vendor prefix for SolidRun
    - split CuBox into it's variants

----------------------------------------------------------------
Andrew Lunn (1):
      ARM: Kirkwood: Add DT descriptions for net2big and net5big.

Jason Cooper (1):
      ARM: kirkwood: fix net5big regulator gpio assignments

Sebastian Hesselbarth (2):
      dt-binding: add vendor prefix for SolidRun
      ARM: dts: mvebu: split SolidRun CuBox into variants

 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm/boot/dts/Makefile                         |   3 +
 arch/arm/boot/dts/dove-cubox-es.dts                |  12 ++
 arch/arm/boot/dts/dove-cubox.dts                   |   3 -
 arch/arm/boot/dts/kirkwood-net2big.dts             |  30 ++++
 arch/arm/boot/dts/kirkwood-net5big.dts             |  83 ++++++++++
 arch/arm/boot/dts/kirkwood-netxbig.dtsi            | 180 +++++++++++++++++++++
 7 files changed, 309 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-net2big.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-net5big.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-netxbig.dtsi

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Russell King - ARM Linux]

On Fri, Jun 27, 2014 at 09:01:29AM -0400, Jason Cooper wrote:
> Sebastian Hesselbarth (2):
>       dt-binding: add vendor prefix for SolidRun
>       ARM: dts: mvebu: split SolidRun CuBox into variants

Are we sure about this?  I mean, in order to find out whether mine is an
engineering sample or not, I had to ask Rabeeh, and Rabeeh had to ask
various questions about the exterior construction in order to identify
which mine was.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Sebastian Hesselbarth]

On 06/27/2014 03:04 PM, Russell King - ARM Linux wrote:
> On Fri, Jun 27, 2014 at 09:01:29AM -0400, Jason Cooper wrote:
>> Sebastian Hesselbarth (2):
>>        dt-binding: add vendor prefix for SolidRun
>>        ARM: dts: mvebu: split SolidRun CuBox into variants
>
> Are we sure about this?  I mean, in order to find out whether mine is an
> engineering sample or not, I had to ask Rabeeh, and Rabeeh had to ask
> various questions about the exterior construction in order to identify
> which mine was.

Russell,

can you be more specific what bothers you about the patch?

The default dove-cubox.dts will now represent 1G production CuBox, while
there will be a dove-cubox-es.dts that you can choose if you know you
have an ES.

Actually, it isn't too hard to find out what version you have:
sdhci card detect is mis-routed on ES, if you plug-in an sdcard after
booting Linux and it doesn't get detected on dove-cubox.dts, then you
have an ES.

Also, production variants have their MAC address stored at 0xd0000 on
SPI flash. And while ES has PL2303 USB-to-UART, production use a
different brand, IIRC FTDI.

That's all about the differences - nothing serious at all.

Sebastian

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Jason Cooper]

Sebastian,

On Fri, Jun 27, 2014 at 03:31:57PM +0200, Sebastian Hesselbarth wrote:
> Also, production variants have their MAC address stored at 0xd0000 on
> SPI flash. And while ES has PL2303 USB-to-UART, production use a
> different brand, IIRC FTDI.

Could you do a follow on patch adding a comment to this effect?  The
Debian guys will need this for flash-kernel and friends.

thx,

Jason.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Sebastian Hesselbarth]

On 06/27/2014 03:39 PM, Jason Cooper wrote:
> On Fri, Jun 27, 2014 at 03:31:57PM +0200, Sebastian Hesselbarth wrote:
>> Also, production variants have their MAC address stored at 0xd0000 on
>> SPI flash. And while ES has PL2303 USB-to-UART, production use a
>> different brand, IIRC FTDI.
>
> Could you do a follow on patch adding a comment to this effect?  The
> Debian guys will need this for flash-kernel and friends.

I don't know if that information will be of any use at all.

You cannot determine USB-to-UART type from CuBox but your host PC only.

And I am not sure, if we want to rely on some six numbers stored on
SPI flash, i.e. there is no magic nor header to be really sure, it
is a MAC address.

Sebastian

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Russell King - ARM Linux]

On Fri, Jun 27, 2014 at 03:44:36PM +0200, Sebastian Hesselbarth wrote:
> On 06/27/2014 03:39 PM, Jason Cooper wrote:
>> On Fri, Jun 27, 2014 at 03:31:57PM +0200, Sebastian Hesselbarth wrote:
>>> Also, production variants have their MAC address stored at 0xd0000 on
>>> SPI flash. And while ES has PL2303 USB-to-UART, production use a
>>> different brand, IIRC FTDI.
>>
>> Could you do a follow on patch adding a comment to this effect?  The
>> Debian guys will need this for flash-kernel and friends.
>
> I don't know if that information will be of any use at all.
>
> You cannot determine USB-to-UART type from CuBox but your host PC only.
>
> And I am not sure, if we want to rely on some six numbers stored on
> SPI flash, i.e. there is no magic nor header to be really sure, it
> is a MAC address.

This is kind'a my point - you're confirming that you can't reliably
tell which version you have by running something on the cubox itself.
As Jason points out, there are those who need to choose the correct
DT file when installing.

So, this means that the user has to be asked.  If users have to be
asked, users need some way to identify the hardware that they're
running on.

No, I didn't know until recently, because my Cubox was given to me by
Nicolas Pitre a couple of years ago - that's the problem, the engineering
samples may not be with the original people and therefore their origins
may not be known.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Sebastian Hesselbarth]

On 06/27/2014 03:59 PM, Russell King - ARM Linux wrote:
> On Fri, Jun 27, 2014 at 03:44:36PM +0200, Sebastian Hesselbarth wrote:
>> On 06/27/2014 03:39 PM, Jason Cooper wrote:
>>> On Fri, Jun 27, 2014 at 03:31:57PM +0200, Sebastian Hesselbarth wrote:
>>>> Also, production variants have their MAC address stored at 0xd0000 on
>>>> SPI flash. And while ES has PL2303 USB-to-UART, production use a
>>>> different brand, IIRC FTDI.
>>>
>>> Could you do a follow on patch adding a comment to this effect?  The
>>> Debian guys will need this for flash-kernel and friends.
>>
>> I don't know if that information will be of any use at all.
>>
>> You cannot determine USB-to-UART type from CuBox but your host PC only.
>>
>> And I am not sure, if we want to rely on some six numbers stored on
>> SPI flash, i.e. there is no magic nor header to be really sure, it
>> is a MAC address.
>
> This is kind'a my point - you're confirming that you can't reliably
> tell which version you have by running something on the cubox itself.
> As Jason points out, there are those who need to choose the correct
> DT file when installing.
>
> So, this means that the user has to be asked.  If users have to be
> asked, users need some way to identify the hardware that they're
> running on.

I get your point, but there is no way to automatically tell them apart.
IMHO, that is why cubox-dove.dts should represent the *production*
version.

> No, I didn't know until recently, because my Cubox was given to me by
> Nicolas Pitre a couple of years ago - that's the problem, the engineering
> samples may not be with the original people and therefore their origins
> may not be known.

It is printed on the box it came in ;)

Honestly, I consider it much more likely that someone who buys/owns an
ES is able to tell them apart than the other way round. And _you_ know
how to deal with the wrong dts, the other may not.

Sebastian

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Russell King - ARM Linux]

On Fri, Jun 27, 2014 at 04:13:56PM +0200, Sebastian Hesselbarth wrote:
> On 06/27/2014 03:59 PM, Russell King - ARM Linux wrote:
>> This is kind'a my point - you're confirming that you can't reliably
>> tell which version you have by running something on the cubox itself.
>> As Jason points out, there are those who need to choose the correct
>> DT file when installing.
>>
>> So, this means that the user has to be asked.  If users have to be
>> asked, users need some way to identify the hardware that they're
>> running on.
>
> I get your point, but there is no way to automatically tell them apart.
> IMHO, that is why cubox-dove.dts should represent the *production*
> version.

That's why I'm saying maybe there shouldn't be a distinction at DT
level - AFAIK the GPIO-based detection also works on the production
version.

>> No, I didn't know until recently, because my Cubox was given to me by
>> Nicolas Pitre a couple of years ago - that's the problem, the engineering
>> samples may not be with the original people and therefore their origins
>> may not be known.
>
> It is printed on the box it came in ;)

Yea, that's why it took a year and a half for me to find out which
model I had.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Sebastian Hesselbarth]

On 06/27/2014 04:46 PM, Russell King - ARM Linux wrote:
> On Fri, Jun 27, 2014 at 04:13:56PM +0200, Sebastian Hesselbarth wrote:
>> On 06/27/2014 03:59 PM, Russell King - ARM Linux wrote:
>>> This is kind'a my point - you're confirming that you can't reliably
>>> tell which version you have by running something on the cubox itself.
>>> As Jason points out, there are those who need to choose the correct
>>> DT file when installing.
>>>
>>> So, this means that the user has to be asked.  If users have to be
>>> asked, users need some way to identify the hardware that they're
>>> running on.
>>
>> I get your point, but there is no way to automatically tell them apart.
>> IMHO, that is why cubox-dove.dts should represent the *production*
>> version.
>
> That's why I'm saying maybe there shouldn't be a distinction at DT
> level - AFAIK the GPIO-based detection also works on the production
> version.

No, it doesn't.

On Dove, mpp12 carries sdio*1* card detect.

ES has sdio*0* slot card detect routed to mpp12 and cannot rely on
SDHCI CARD_PRESENT bit. That is what the gpio workaround is for.

Production uses the correct mpp pin and cannot rely on gpio pin
value, as it is not connected to slot card detect.

So, use the wrong dts on either ES or production will break sdio card
detect.

Sebastian

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Jason Cooper]

> On Jun 27, 2014, at 9:44, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
...
> And I am not sure, if we want to rely on some six numbers stored on
> SPI flash, i.e. there is no magic nor header to be really sure, it
> is a MAC address.

It couldn't be compared with the MAC address of the nic?

thx,

Jason. 

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Sebastian Hesselbarth]

On 06/27/2014 06:49 PM, Jason Cooper wrote:
>> On Jun 27, 2014, at 9:44, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
> ...
>> And I am not sure, if we want to rely on some six numbers stored on
>> SPI flash, i.e. there is no magic nor header to be really sure, it
>> is a MAC address.
> 
> It couldn't be compared with the MAC address of the nic?

Sure, but if it is not equal it tells you nothing.

You can change the NICs MAC in your bootloader, it will be different
from the numbers you read from SPI, and some mechanism will assume you
just made your production version into ES.

We really want to introduce such a crutch?

Sebastian

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Jason Cooper]

On Fri, Jun 27, 2014 at 07:36:12PM +0200, Sebastian Hesselbarth wrote:
> On 06/27/2014 06:49 PM, Jason Cooper wrote:
> >> On Jun 27, 2014, at 9:44, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
> > ...
> >> And I am not sure, if we want to rely on some six numbers stored on
> >> SPI flash, i.e. there is no magic nor header to be really sure, it
> >> is a MAC address.
> > 
> > It couldn't be compared with the MAC address of the nic?
> 
> Sure, but if it is not equal it tells you nothing.
> 
> You can change the NICs MAC in your bootloader, it will be different
> from the numbers you read from SPI, and some mechanism will assume you
> just made your production version into ES.
> 
> We really want to introduce such a crutch?

Well, we need to keep in mind distro's concerns, but we don't need to
(and shouldn't) attempt to solve them.

That's why I wanted to add a comment expressing the facts as best we
know them.  We could also now add a link to this thread to assist future
distro maintainers.

As this patch sits, it is an accurate description of the two variants of
dove-based CuBoxes.  The fact that SolidRun didn't leave a clear
differentiator is unfortunate, but we can't magic a solution out of our
ass.  Nor should we block a patch because we can't.

It also might be worth reaching out to Rabeeh one more time and asking
explicitly if there is a programmatic way to differentiate the two
boards on the board itself.

It would have been ideal if the ES had 512MB of RAM...

thx,

Jason.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Sebastian Hesselbarth]

On 06/28/2014 04:54 PM, Jason Cooper wrote:
> On Fri, Jun 27, 2014 at 07:36:12PM +0200, Sebastian Hesselbarth wrote:
>> On 06/27/2014 06:49 PM, Jason Cooper wrote:
>>>> On Jun 27, 2014, at 9:44, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
>>> ...
>>>> And I am not sure, if we want to rely on some six numbers stored on
>>>> SPI flash, i.e. there is no magic nor header to be really sure, it
>>>> is a MAC address.
>>>
>>> It couldn't be compared with the MAC address of the nic?
>>
>> Sure, but if it is not equal it tells you nothing.
>>
>> You can change the NICs MAC in your bootloader, it will be different
>> from the numbers you read from SPI, and some mechanism will assume you
>> just made your production version into ES.
>>
>> We really want to introduce such a crutch?
> 
> Well, we need to keep in mind distro's concerns, but we don't need to
> (and shouldn't) attempt to solve them.
> 
> That's why I wanted to add a comment expressing the facts as best we
> know them.  We could also now add a link to this thread to assist future
> distro maintainers.
> 
> As this patch sits, it is an accurate description of the two variants of
> dove-based CuBoxes.  The fact that SolidRun didn't leave a clear
> differentiator is unfortunate, but we can't magic a solution out of our
> ass.  Nor should we block a patch because we can't.

Ok, I'll look through my eMails and Web again to collect some
differences and prepare a "add comment" only patch for the CuBox DTSs.

> It also might be worth reaching out to Rabeeh one more time and asking
> explicitly if there is a programmatic way to differentiate the two
> boards on the board itself.

Yeah, I remember someone said that there is a different SPI vendor on
production CuBox. That could be a way to tell them apart _if_ it is
used exclusively on production boxes.

But I'll ask Rabeeh about it again.

> It would have been ideal if the ES had 512MB of RAM...

Depends, for differentiation yes, otherwise I am quite happy with 1G ;)

Some magic and a variant number in SPI would have been better I guess.

Sebastian

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Jason Cooper]

Sebastian,

On Mon, Jun 30, 2014 at 09:50:30AM +0200, Sebastian Hesselbarth wrote:
> On 06/28/2014 04:54 PM, Jason Cooper wrote:
> > On Fri, Jun 27, 2014 at 07:36:12PM +0200, Sebastian Hesselbarth wrote:
> >> On 06/27/2014 06:49 PM, Jason Cooper wrote:
> >>>> On Jun 27, 2014, at 9:44, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
> >>> ...
> >>>> And I am not sure, if we want to rely on some six numbers stored on
> >>>> SPI flash, i.e. there is no magic nor header to be really sure, it
> >>>> is a MAC address.
> >>>
> >>> It couldn't be compared with the MAC address of the nic?
> >>
> >> Sure, but if it is not equal it tells you nothing.
> >>
> >> You can change the NICs MAC in your bootloader, it will be different
> >> from the numbers you read from SPI, and some mechanism will assume you
> >> just made your production version into ES.
> >>
> >> We really want to introduce such a crutch?
> > 
> > Well, we need to keep in mind distro's concerns, but we don't need to
> > (and shouldn't) attempt to solve them.
> > 
> > That's why I wanted to add a comment expressing the facts as best we
> > know them.  We could also now add a link to this thread to assist future
> > distro maintainers.
> > 
> > As this patch sits, it is an accurate description of the two variants of
> > dove-based CuBoxes.  The fact that SolidRun didn't leave a clear
> > differentiator is unfortunate, but we can't magic a solution out of our
> > ass.  Nor should we block a patch because we can't.
> 
> Ok, I'll look through my eMails and Web again to collect some
> differences and prepare a "add comment" only patch for the CuBox DTSs.

No rush, just a gentle ping.  ;-)

> > It also might be worth reaching out to Rabeeh one more time and asking
> > explicitly if there is a programmatic way to differentiate the two
> > boards on the board itself.
> 
> Yeah, I remember someone said that there is a different SPI vendor on
> production CuBox. That could be a way to tell them apart _if_ it is
> used exclusively on production boxes.
> 
> But I'll ask Rabeeh about it again.

any word from Rabeeh?

thx,

Jason.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Jason Cooper]

On Fri, Jun 27, 2014 at 02:04:30PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 27, 2014 at 09:01:29AM -0400, Jason Cooper wrote:
> > Sebastian Hesselbarth (2):
> >       dt-binding: add vendor prefix for SolidRun
> >       ARM: dts: mvebu: split SolidRun CuBox into variants
> 
> Are we sure about this?  I mean, in order to find out whether mine is an
> engineering sample or not, I had to ask Rabeeh, and Rabeeh had to ask
> various questions about the exterior construction in order to identify
> which mine was.

What were the specific details Rebeeh use to differentiate ES and
production?  Is it something generic we could put in a comment?

Sebastian, what happens when the wrong dtb is loaded?  afaict, card
detect won't work for the sd card.  Which isn't earth-shattering, but I
know at least the Debian guys are going to want a programmatic way to
determine which board they are on.

thx,

Jason.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Olof Johansson]

On Fri, Jun 27, 2014 at 09:01:29AM -0400, Jason Cooper wrote:
> Guys,
> 
> It's a pretty slow cycle this time around, so here's what I have so far.
> Nothing controversial, just putting the last nail in the coffin for
> mach-kirkwood/ . :-)
> 
> Please pull.

FWIW, holding off until the CuBox issue has been resolved -- I didn't see
a resolution in the thread.


-Olof

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Jason Cooper]

On Mon, Jul 07, 2014 at 10:34:34PM -0700, Olof Johansson wrote:
> On Fri, Jun 27, 2014 at 09:01:29AM -0400, Jason Cooper wrote:
> > Guys,
> > 
> > It's a pretty slow cycle this time around, so here's what I have so far.
> > Nothing controversial, just putting the last nail in the coffin for
> > mach-kirkwood/ . :-)
> > 
> > Please pull.
> 
> FWIW, holding off until the CuBox issue has been resolved -- I didn't see
> a resolution in the thread.

?  Sebastian is working on a follow-on patch to add a comment to the dts
file regarding the CuBox's lack of programmatic determinism.
Unfortunately there's nothing else we can do.

The patches Sebastian has written are correct in that *most* CuBox
owners have production models.  So if those users select dove-cubox.dtb,
they'll get a working system.  On the off chance they don't know they
have an engineering sample, card-detect won't work.

All CuBoxes bootloaders are non-DT, so users will be appending the dtb.
Which presents a very manageable upgrade path.  Just not ideal.  And
asking the user to swap out dtbs if the card-detect doesn't work isn't
ideal either.  Unfortunately, SolidRun left us with no clean way to
detect which board we are running on.

Can you offer any suggestions as to how you would like this resolved?  I
thought when I voiced my opinion as above, and Russell didn't reply,
there was implied acknowledgement...

I can drop the cubox changes if you want, but I'm struggling to see a
technical reason to do so.

thx,

Jason.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Russell King - ARM Linux]

On Tue, Jul 08, 2014 at 07:57:27AM -0400, Jason Cooper wrote:
> Can you offer any suggestions as to how you would like this resolved?  I
> thought when I voiced my opinion as above, and Russell didn't reply,
> there was implied acknowledgement...

I didn't reply probably because I didn't see the message and/or I'm busy
with other stuff.

I know that Sebastian asked Rabeeh on IRC yesterday whether the flash
chip type could be used to detect the difference between the two, but
has not yet received an answer.

As the two DT descriptions are mutually incompatible, there isn't much
choice.  And (afaik) there's no choice of updating the boot loader to
a version which can deal with DT - yes it may be u-boot, but I've no
idea if modern u-boot works on it, and I really would not like to try.

While SolidRun tried to make changing u-boot easy and recoverable, I've
had personal experience of trying to help people restore their cuboxes.
It's a total nightmare (mainly seems to be down to the wide variation
in USB hardware which causes the on-board USB-serial for the console to
be unreliable.)  That's why on their later iMX6 hardware (Cubox-i & HB)
they decided to have zero on-board non-volatile storage.

So, even if it was possible to detect the difference in u-boot between
the Cubox models, getting the updated u-boot on the machine is far from
trivial.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Jason Cooper]

On Tue, Jul 08, 2014 at 01:12:52PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 08, 2014 at 07:57:27AM -0400, Jason Cooper wrote:
> > Can you offer any suggestions as to how you would like this resolved?  I
> > thought when I voiced my opinion as above, and Russell didn't reply,
> > there was implied acknowledgement...
> 
> I didn't reply probably because I didn't see the message and/or I'm busy
> with other stuff.

Fair enough.

> I know that Sebastian asked Rabeeh on IRC yesterday whether the flash
> chip type could be used to detect the difference between the two, but
> has not yet received an answer.

Ok.

> As the two DT descriptions are mutually incompatible, there isn't much
> choice.  And (afaik) there's no choice of updating the boot loader to
> a version which can deal with DT - yes it may be u-boot, but I've no
> idea if modern u-boot works on it, and I really would not like to try.

Right, what I'm arguing for (since trimmed), is *not* bootloader
upgrades.  I think Sebastian's changes are ok because:

 - Most users have production boxes (Sebastian's patches provide their
   sane default)

 - Most users of mainline or distro kernels are appending the dtb, so
   swapping out a dtb, while not ideal, isn't earth-shattering.

The *only* failure condition I can see is what you already highlighted,
people who don't know they have an engineering sample.  Sebastian's
patches work for most people, and on the odd chance of the failure, the
user simply appends the other dtb and reboots.

Once we hear back from Rabeeh, at a minimum, we'll add a comment to the
dts file for distro maintainers and users to find.  If possible, we'll
add a hook in arch code to read from SPI and adjust the dtb accordingly.

In either case, comment or code, the dts files changed in this series
are correct and won't change.

I'm sorry to be dense, Russell, but what am I missing from your
objection?

thx,

Jason.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Jason Cooper]

Russell,

On Tue, Jul 08, 2014 at 08:46:53AM -0400, Jason Cooper wrote:
> On Tue, Jul 08, 2014 at 01:12:52PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Jul 08, 2014 at 07:57:27AM -0400, Jason Cooper wrote:
> > > Can you offer any suggestions as to how you would like this resolved?  I
> > > thought when I voiced my opinion as above, and Russell didn't reply,
> > > there was implied acknowledgement...
> > 
> > I didn't reply probably because I didn't see the message and/or I'm busy
> > with other stuff.
> 
> Fair enough.

This is the second time I've asked you for a technical reason not to
merge these DTS patches, only to be met with silence, again.

> > I know that Sebastian asked Rabeeh on IRC yesterday whether the flash
> > chip type could be used to detect the difference between the two, but
> > has not yet received an answer.
> 
> Ok.
> 
> > As the two DT descriptions are mutually incompatible, there isn't much
> > choice.  And (afaik) there's no choice of updating the boot loader to
> > a version which can deal with DT - yes it may be u-boot, but I've no
> > idea if modern u-boot works on it, and I really would not like to try.
> 
> Right, what I'm arguing for (since trimmed), is *not* bootloader
> upgrades.  I think Sebastian's changes are ok because:
> 
>  - Most users have production boxes (Sebastian's patches provide their
>    sane default)
> 
>  - Most users of mainline or distro kernels are appending the dtb, so
>    swapping out a dtb, while not ideal, isn't earth-shattering.
> 
> The *only* failure condition I can see is what you already highlighted,
> people who don't know they have an engineering sample.  Sebastian's
> patches work for most people, and on the odd chance of the failure, the
> user simply appends the other dtb and reboots.
> 
> Once we hear back from Rabeeh, at a minimum, we'll add a comment to the
> dts file for distro maintainers and users to find.  If possible, we'll
> add a hook in arch code to read from SPI and adjust the dtb accordingly.

Either of these solutions will be follow-on patches.  There's no need to
hold up this pull request over this information.

> In either case, comment or code, the dts files changed in this series
> are correct and won't change.

I still stand by this.

> I'm sorry to be dense, Russell, but what am I missing from your
> objection?

Olof, Arnd, please merge this request.  I can re-send if you need.

We have more changes pending in mvebu/dt on top of this, and we're
getting very close to the cutoff for the merge window.

thx,

Jason.

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Arnd Bergmann]

On Thursday 17 July 2014 08:35:50 Jason Cooper wrote:
> Olof, Arnd, please merge this request.  I can re-send if you need.
> 
> We have more changes pending in mvebu/dt on top of this, and we're
> getting very close to the cutoff for the merge window.

Please send both pull requests now so we can look at the whole
picture. No need for you to wait for this to be merged before
sending the follow-up pull request.

I think we should just merge, there is no nice solution for
the technical problem and the approach you have taken looks
like the least problematic one to me.

Olof, any further thoughts on this?

	Arnd

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Olof Johansson]

On Fri, Jul 18, 2014 at 03:29:53PM +0200, Arnd Bergmann wrote:
> On Thursday 17 July 2014 08:35:50 Jason Cooper wrote:
> > Olof, Arnd, please merge this request.  I can re-send if you need.
> > 
> > We have more changes pending in mvebu/dt on top of this, and we're
> > getting very close to the cutoff for the merge window.
> 
> Please send both pull requests now so we can look at the whole
> picture. No need for you to wait for this to be merged before
> sending the follow-up pull request.
> 
> I think we should just merge, there is no nice solution for
> the technical problem and the approach you have taken looks
> like the least problematic one to me.
> 
> Olof, any further thoughts on this?

I have a CuBox, and based on USB id for the UART, it's an ES model.

Since the only thing that breaks seems to be SD, I can personally live with
that just fine even if I have to refer to the non-ES dtb for backwards
compatibility.

If this requires more discussion then the obvious solution is to leave out
these patches and send the superceding DT pull request of a branch that doesn't
have them. I think we can take this as it is for now though -- I suspect in
reality the number of affected ES owners should be pretty small?


-Olof

[GIT PULL] ARM: mvebu: DT changes for v3.17

[Sebastian Hesselbarth]

On 07/08/2014 02:12 PM, Russell King - ARM Linux wrote:
> On Tue, Jul 08, 2014 at 07:57:27AM -0400, Jason Cooper wrote:
>> Can you offer any suggestions as to how you would like this resolved?  I
>> thought when I voiced my opinion as above, and Russell didn't reply,
>> there was implied acknowledgement...
>
> I didn't reply probably because I didn't see the message and/or I'm busy
> with other stuff.
>
> I know that Sebastian asked Rabeeh on IRC yesterday whether the flash
> chip type could be used to detect the difference between the two, but
> has not yet received an answer.

Yeah, I asked him by mail too to give him more time to reply on it.
I looked through my emails and found a request to update kernel's
dove-cubox.dts for a different SPI flash type on 1G production.

My ES box has a Winbond W25Q32BV (compatible = "st,w25q32", obviously
wrong vendor prefix) and the request was to add "n25q032" to make
Linux MTD happy again.

The question I asked Rabeeh basically is, if above difference is true
for all production CuBoxes. If it is, we can use it to tell them apart
without user intervention.

As soon as I get a reply, I'll cook a patch for it (either compatible
fix or comment about indiscrimination).

> As the two DT descriptions are mutually incompatible, there isn't much
> choice.  And (afaik) there's no choice of updating the boot loader to
> a version which can deal with DT - yes it may be u-boot, but I've no
> idea if modern u-boot works on it, and I really would not like to try.

Most current MVEBU bootloader work is probably done on barebox. I have
currently pending patches for usb and sdhci on Dove, eth is supported
already. Let's say it is close to be considered as a replacement for
u-boot. Of course, some of the voltage optimization is missing. Anyway,
we cannot expect users to jump on barebox and update their boxes for
obvious reasons you stated below.

And yes, the two DT descriptions are mutually incompatible, but the
perceived impact may be low. I'd expect most users to have their
rootfs on SDHCI, so hot-plugging is not an option. Even if it is on
a different medium, the SD card slot is well hidden under the HDMI
jack.

Considering the low impact and given that most users will have a
production version, I copy Jason's statement. As said above, I'll
either add a comment or fix the SPI compatible in a follow-up patch.

> While SolidRun tried to make changing u-boot easy and recoverable, I've
> had personal experience of trying to help people restore their cuboxes.
> It's a total nightmare (mainly seems to be down to the wide variation
> in USB hardware which causes the on-board USB-serial for the console to
> be unreliable.)  That's why on their later iMX6 hardware (Cubox-i & HB)
> they decided to have zero on-board non-volatile storage.
>
> So, even if it was possible to detect the difference in u-boot between
> the Cubox models, getting the updated u-boot on the machine is far from
> trivial.

I agree that bootloader replacement isn't trivial, but compared to other
SoCs the UART boot button makes it quite easy to deal with. But it is no
fool-proof method of course.

The reason I was conservative about using any stored information on SPI
flash as indicator for CuBox revision was also driven by those issues
reported on IRC, i.e. if somebody erased the SPI MAC address, it would
have been identified as ES.

Sebastian