[U-Boot] [PATCH 3/3] tegra2: Add support for Compal Paz00 (Toshiba AC100)

[Simon Glass]

Hi Stephen,

On Mon, Jan 9, 2012 at 12:10 PM, Stephen Warren <swarren at nvidia.com> wrote:
> On 01/09/2012 01:04 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Mon, Jan 9, 2012 at 12:00 PM, Stephen Warren <swarren at nvidia.com> wrote:
>>> On 01/09/2012 12:55 PM, Simon Glass wrote:
>>>> On Fri, Jan 6, 2012 at 2:14 PM, Stephen Warren <swarren at nvidia.com> wrote:
>>>>> The Toshiba AC100 (Compal code-name Paz00, aka Dynabook AZ) is a netbook
>>>>> derived from the NVIDIA Tegra Harmony reference board. It ships with
>>>>> Android, but is often repurposed to run Linux. This patch adds just enough
>>>>> support to get a U-Boot serial console, and the ability access built-in
>>>>> eMMC and the external SD slot.
>>> ...
>>>>> diff --git a/board/compal/paz00/Makefile b/board/compal/paz00/Makefile
>>> ...
>>>>> +COBJS  := $(BOARD).o
>>>>> +COBJS  += ../../nvidia/common/board.o
>>>>
>>>> I think you can drop this as the top-level Makefile should bring in
>>>> the library from that directory.
>>>
>>> I did try that initially, and it doesn't work. I didn't investigate very
>>> far at all, but I assume it's because the common library is for vendor
>>> NVIDIA, but this board is for vendor compal, and so the common library
>>> doesn't get pulled in? Does that make sense, or should I investigate
>>> further?
>>
>> Sorry, of course you are using a different vendor.
>>
>> It seems a bit dodgy to include a board file from a different vendor.
>> Sad as it is, perhaps the right thing to do is to copy the code from
>> that file?
>
> I think that's what Thierry did with the Avionics Design boards. But to
> me it seemed the lack of cleanliness of pulling in an existing file from
> outside the vendor tree was less than that of cut/pasting the code.
>
> With my patch, any issues should still show up with "MAKEALL -s tegra2"
> at build-/change-time, whereas if I cut/paste the code, the Compal
> vendor might not pick up any bug fixes etc. to the shared code until
> after someone had actually tested on the PAZ00 board, which will
> probably happen a lot less frequently.
>
> Given that, do you think this change is reasonable?
>
>> We should perhaps look at moving some of it into arch, as we have done
>> previously.
>
> Yes, that's probably the best long-term solution. I don't actually
> recall exactly which parts of that common code the PAZ00 code relies on
> right now; it might be an easy change.

It's not that hard (each of the two functions has <10 LOC), but I
agree with your reasoning, and this is fine with me until we address
it.

Acked-by: Simon Glass <sjg at chromium.org>

>
> --
> nvpublic

Regards,
Simon