linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] ARM: mvebu: DT changes for v3.17
Date: Mon, 30 Jun 2014 09:50:30 +0200	[thread overview]
Message-ID: <53B116C6.80601@gmail.com> (raw)
In-Reply-To: <20140628145424.GK23978@titan.lakedaemon.net>

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

  reply	other threads:[~2014-06-30  7:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-27 13:01 [GIT PULL] ARM: mvebu: DT changes for v3.17 Jason Cooper
2014-06-27 13:04 ` Russell King - ARM Linux
2014-06-27 13:31   ` Sebastian Hesselbarth
2014-06-27 13:39     ` Jason Cooper
2014-06-27 13:44       ` Sebastian Hesselbarth
2014-06-27 13:59         ` Russell King - ARM Linux
2014-06-27 14:13           ` Sebastian Hesselbarth
2014-06-27 14:46             ` Russell King - ARM Linux
2014-06-27 14:52               ` Sebastian Hesselbarth
2014-06-27 16:49         ` Jason Cooper
2014-06-27 17:36           ` Sebastian Hesselbarth
2014-06-28 14:54             ` Jason Cooper
2014-06-30  7:50               ` Sebastian Hesselbarth [this message]
2014-07-08 12:10                 ` Jason Cooper
2014-06-27 13:37   ` Jason Cooper
2014-07-08  5:34 ` Olof Johansson
2014-07-08 11:57   ` Jason Cooper
2014-07-08 12:12     ` Russell King - ARM Linux
2014-07-08 12:46       ` Jason Cooper
2014-07-17 12:35         ` Jason Cooper
2014-07-18 13:29           ` Arnd Bergmann
2014-07-18 22:20             ` Olof Johansson
2014-07-08 12:53       ` Sebastian Hesselbarth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53B116C6.80601@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).