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

Simon Glass sjg at chromium.org
Wed Sep 2 16:05:41 CEST 2015


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.

Regards,
Simon


More information about the U-Boot mailing list