<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 13, 2018 at 8:25 AM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Amaan,<br>
<span class=""><br>
<br>
On Fri, Jul 13, 2018 at 3:32 AM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> wrote:<br>
> The built documentation can more easily be viewed here:<br>
> <a href="http://whatthedude.com/rtems/user/html/bsps/bsps-x86_64.html" rel="noreferrer" target="_blank">http://whatthedude.com/rtems/<wbr>user/html/bsps/bsps-x86_64.<wbr>html</a><br>
><br>
> It feels a bit convoluted to me at the moment. I'd appreciate feedback on how<br>
> the documentation may be made more understandable, and on whether the current<br>
> approach even seems sustainable - specifically, using FreeBSD's bootloader ties<br>
> us into using the UFS filesystem and can slow down the iterative-development<br>
> process.<br>
><br>
</span>I agree. It looks like you have to build FreeBSD at least one time to<br>
use this? Alternatives should be again considered for iterative<br>
improvement.<br></blockquote><div><br></div><div>Reducing what has to be built is an important goal. But an alternative is</div><div>to host a pre-built binary of what is required to boot. I did that for a boot</div><div>floppy for the pc386. There were instructions for making one and they</div><div>worked but, in practice, just grabbing the floppy image was easier. </div><div><br></div><div>Note; you didn't need to use a real floppy. Telling qemu what file</div><div>was the 1.44 MB image was all that was needed. Combine that with</div><div>vfat for c: and it worked find.</div><div><br></div><div>So I think we need both -- RSB for building from source and a pre-built</div><div>binary. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> In my opinion, this system is good _enough_ for now - we can explore other<br>
> options later if time permits, but I'd love to hear differing opinions.<br>
><br>
> P.S. - Joel asked earlier if the QEMU that the RSB builds will suffice - for me,<br>
> it didn't because in it "SDL support is disabled" (and so are all other graphics<br>
> options). It's likely possible to install FreeBSD without graphics, it may not<br>
> be worth the effort of setting up - it's likely easier to update the RSB's QEMU<br>
> to also build graphics support.<br>
><br>
</span>I was going to recommend this. You can make it an option of the qemu<br>
configuration in RSB to enable the support needed. I suggest you talk<br>
to Vijay as he has some experience now with RSB, and also this will<br>
require Chris Johns approval.<br></blockquote><div><br></div><div>Everything that wasn't needed was disabled to make it easier to build</div><div>on multiple hosts. Too many projects are Linux monoculture and </div><div>getting things built on multiple hosts can be a pain.</div><div><br></div><div>But I think SDL support needs to be enabled since otherwise we have</div><div>no way to test graphics at all.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Relatedly, does it make sense for you to look at creating an RSB<br>
"recipe" for building the UEFI firmware?<br></blockquote><div><br></div><div>See above. I think we need RSB recipes for everything required that</div><div>we expect to be put together by a user. And we should host binaries</div><div>along with matching sources for some pre-built versions. I don't want</div><div>this BSP to be an order of magnitude harder to get started with than</div><div>any of the others.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> P.P.S. - Some of the documentation is double-spaced, but this patch isn't. Let me<br>
> know if it ought to be (the README didn't say anything of the sort, and it isn't<br>
> consistent throughout).<br>
><br>
<br>
</span>Stick to one consistent approach within your chapters. If consistency<br>
needs to be dealt with across chapters in a manual or across the set<br>
of manuals, that can be done later and simpler if each chapter is<br>
internally consistent.<br></blockquote><div><br></div><div>How did some documentation get to be double-spaced? I thought we</div><div>had a consistent style of single space or something like 1.5. I have</div><div>never even thought of changing the line spacing and don't know how. :)</div><div><br></div><div>Sounds like we need to look at fixing the inconsistent places. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
> Amaan Cheval (1):<br>
>   user: Add x86_64 BSP chapter<br>
><br>
>  user/bsps/bsps-x86_64.rst | 143 ++++++++++++++++++++++++++++++<wbr>+++++++++++++++-<br>
>  1 file changed, 142 insertions(+), 1 deletion(-)<br>
><br>
> --<br>
> 2.16.0.rc0<br>
><br>
</div></div></blockquote></div><br></div></div>