[U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[Masahiro Yamada]

Hi.


2015-09-02 23:05 GMT+09:00 Simon Glass <sjg at chromium.org>:
> Hi Paul,
>
> On 2 September 2015 at 07:37, Paul Gortmaker
> <paul.gortmaker at windriver.com> wrote:
>> On 2015-09-01 10:08 PM, York Sun wrote:
>>>
>>>
>>> On 08/24/2015 12:26 PM, Paul Gortmaker wrote:
>>>> Tested on commit 3ea0953d36023d7e50fb00b2e258d8fb2828aeac
>>>> ("dm: Move pre-reloc init earlier to cope with board_early_init_f()")
>>>> since the commit after that ("Set up stdio earlier when using driver
>>>> model") hangs this board at "Net:" init, just like it hangs the
>>>> sbc8548 board[1].  So, until that is resolved, this will be the
>>>> newest functional baseline for both boards.
>>>>
>>> Paul,
>>>
>>> I can't test this patch. As the commit message said, it only works on an ancient
>>> point. Even this patch is merged, you can use the top of tree anyway. Is there
>>> any effort to find out why it is broken?
>>
>> Well, I was hoping to get more detailed suggestions from folks here,
>> now that we know it is not board specific and probably breaks a lot
>> of the older freescale boards - both the sbc8548 and sbc8641d were
>> close derivatives of their MPC8548CDS and HPCNET/8641D cousins, but
>> just targeting a smaller form factor.  I'm betting they are dead too.
>>
>> Maybe now that we know that, Simon [added to CC] can offer some more
>> detailed suggestions on what is going on, since I bisected it back
>> to his commit relating to uart init.
>>
>> http://marc.info/?l=u-boot&m=142715170512534
>>
>> I can test incremental changes on top of that last working baseline
>> easily enough, since the board has redundant flash (which let me
>> get that far).  But currently I've no clue where to start, since
>> the uart init breaking net init, or leaving a booby-trap such that
>> touching the net device hangs - doesn't really point to an obvious
>> starting point to test.  :(
>
> I don't have any good ideas, you could try these (with reference to my
> commit 294b91a5):
>
> 1. Move the initr_barrier()...initr_dm() code sequence back to its
> original place below initr_w83c553f(), and see if that fixes it. Then
> progressively move it earlier until you see a breakage.
>
> 2. Add another initr_barrier() in the original place
>
> 3. Comment out initr_dm()
>
> Since you are presumably not using driver model for serial yet you
> should be able to fiddling things around quite a bit without breaking
> anything. Once you narrow it down a fix may be obvious, or may need a
> bit of thought.
>


Any plan about this patch?

I think this is the last non-generic board for PowerPC architecture.

This board is still keeping us from removing arch/powerpc/lib/board.c



-- 
Best Regards
Masahiro Yamada