<div class="gmail_quote">On Fri, Jul 23, 2010 at 2:38 PM, <span dir="ltr"><<a href="mailto:david@protonic.nl">david@protonic.nl</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This has been an interesting discussion, but I don't want to upset any<br>
more people here. I just want to ask one more question, being new to<br>
ARM-linux: What setup should I chose for our products then? What would be<br>
more in tune with the most desireable long-term goal of ARM-linux booting?<br>
<br>
1. u-boot doing all pad/IO setup and loading linux.<br>
2. u-boot just loading linux and doing only the minimum IO-setup necessary<br>
for that job, and write a linux BSP that does ALL IO-init<br>
3. Don't use u-boot at all, and investigate Magnus's Kexec technique?<br>
4. Something else?<br>
<br></blockquote><div><br></div><div>Option (1) is the best bet for a *production* device (your scenario).</div><div><br></div><div>For me (as a SoC company BSP engineer, trying to make a zillion</div><div>disparate customers all happy) I use option (4):</div>
<div><br></div><div> a) A minimial (<16k) boot block, that reads a config out of flash, and runs...</div><div> b) A small DDR (and other devices) init routine (<32k) out of flash, and then...</div><div> c) Linux </div>
<div><br></div><div>(a) Doesn't set up *anything* other than the serial UART. It is primarily</div><div> for reading the config, and performing the load order from flash as</div><div> requested by the config.</div>
<div>(b) Contains all the 'real' chip/pad/board initialization, that would be</div><div> per-production board specific.</div><div>(c) Doesn't need to set up pads/pins, assumes (b) took care of it.</div><div>
<br></div><div>So, this is kinda like option (1), except that we use our own minimal loader</div><div>and board setup instead of U-Boot. The source code for (a) and (b) are provided</div><div>as examples to our customers.</div>
<div><br></div></div>-- <br>Jason S. McMullan<br>Netronome Systems, Inc.<br>