Hi Paul,
On 2 September 2015 at 07:37, Paul Gortmaker paul.gortmaker@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