<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, May 28, 2017 at 7:20 PM Peter Stuge <<a href="mailto:peter@stuge.se">peter@stuge.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jonathan Neuschäfer wrote:<br>
> I wonder if we should just import libfdt when we need to parse or<br>
> modify devicetree blobs.  A quick check on the libfdt.a on my<br>
> system (x86_64) shows that the set of .o files takes about 15kB, so<br>
> it's not huge.<br>
<br>
If the license is compatible I think that's a good idea.<br></blockquote><div><br></div><div>yeah, I agree with you both.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> I think we should consider splitting the memory-resident part of<br>
> coreboot on RISC-V into its own stage, similar to the SMM code on x86.<br>
<br>
Is there any way a system can work completely without it?<br><br></blockquote><div><br></div><div>one way, which I've done, is for a kernel to supply its own code, i.e. move the responsibility for supplying M-mode code to the kernel and away from firmware.f</div><div><br></div><div>This would remove some concerns people have about run-time firmware, since there would not be any :-)</div><div><br></div><div>ron </div></div></div>