<div dir="ltr"><div><div><div><div><div>> Linux, for a long time, did not need no steenkin' BIOS (you can find 
that quote if you look back far enough). <span style="color:rgb(255,0,0)"><u><i><b>But those days are gone.<br><br></b></i></u></span></div><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)">This is the reason why INTEL has no chance to win IoT race with ARM (just in few special use cases). With all these compatibilities, and test modes, INTEL is forcing customers to the HW CLOSED model, forcing as well Firmware CLOSED model (with 10x more silicon/HW extensions to comply, and end users/customers are paying for that). Since there are gazillion of boot registers which need to be set-up properly for modes to work as intended.<br><br></span></span></div><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)">Having concept of Device Tree Usage (HW OPEN model, forcing FW/BSP OPEN model), I can, having one very smart HW designer (with random IO controller order with ARM SoCs: i.MX6/7/8, tegra, etc.), build the whole ARM based SoC HW and whole system SW including FW, application tools rich root-tree, and Device Drivers in few weeks using YOCTO. Board Plug & Play, ready for Application, written in Qt5, Java, C++ with all tools, U name it!</span></span></div><div><br><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)"><a href="https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf" target="_blank"><font size="2" face="sans-serif" color="blue">https://events.<wbr>linuxfoundation.org/sites/<wbr>events/files/slides/petazzoni-<wbr>device-tree-dummies.pdf</font></a><font size="2" face="sans-serif"><br>
</font></span></span></div><div><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)"><br></span></span></div><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)">So, Device Tree Usage + YOCTO = 2 experienced men work from scratch with the COMPLETE embedded solution for 2 to 3 weeks. Mini com express for around 20 to 100 EUR a piece?</span></span><br><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)"><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)"> </span></span></span></span></div><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)">Please, could you try to do this with INTEL ATOM or CORE in this time for this price? ;-)<br><br></span></span></div><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)">Zoran Stojsavljevic<br></span></span><div><div><div><div><div><span style="color:rgb(255,0,0)"><u><i><b></b></i></u></span></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 7, 2017 at 2:23 AM, ron minnich <span dir="ltr"><<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The original statement about BIOS -- that it was a second OS from the first day on -- is not correct.<div><br></div><div>I am pretty sure the term BIOS (Basic Input Output Subsystem) comes from the early days, from CP/M. That's when I started hearing it anyway.</div><div><br></div><div>The BIOS was the bottom half of CP/M. It provided an abstract device interface that the top half -- the part that came on a floppy -- could use. So the BIOS was not a second OS. It was 1/2 the OS you ran. Vendors created hardware and BIOS for the (usually 1024 byte) ROM and that ensured that CP/M could run on their box. The part of CP/M on the floppy, and the part in EEPROM, combined to provide a kernel. Kernel, of course, being a very loose term given the lack of processor modes. </div><div><br></div><div>This was a very different model from, e.g., the minicomputers of the day, wherein the ROM was used to boot a kernel and then it got out of the way. </div><div><br></div><div>So BIOS nature as a runtime entity was established very early on. </div><div><br></div><div>Linux, for a long time, did not need no steenkin' BIOS (you can find that quote if you look back far enough). But those days are gone.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>ron</div></font></span></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 6, 2017 at 5:09 PM Julius Werner <<a href="mailto:jwerner@chromium.org" target="_blank">jwerner@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> The awkward thing about BIOS is that it was a second OS from the first<br>
> day on – while the reasonable philosophy behind firmware should be:<br>
> Start the board, load the OS and go back into your flash until reboot.<br>
<br>
My history lessons may be failing me here, but IIRC the main reason<br>
for that was memory: DOS wasn't a full OS in the modern sense, it was<br>
pretty much just a shell and a collection of utility programs. All the<br>
actual device driving was done by the BIOS. So if you compare it with<br>
a modern GNU/Linux machine, the BIOS was equivalent to Linux and DOS<br>
to the GNU parts.<br>
<br>
The original IBM PC had so little memory that they couldn't really<br>
afford to waste any of it on stuff like device drivers. So they put<br>
the drivers in flash where they could be executed in-place, which<br>
became the BIOS. Most of DOS itself (essentially the <a href="http://command.com" rel="noreferrer" target="_blank">command.com</a><br>
shell) was just unloaded whenever you launched a program and re-loaded<br>
from disk afterwards, and while the program was running it mostly<br>
interacted with the BIOS directly.<br>
<br>
So you're right that from our current point of view that having<br>
callbacks into firmware makes little sense, but back then they were<br>
working with what they had and it was pretty much the only way to get<br>
as much out of the machine as they needed. The BIOS was really the<br>
first OS on the platform, and all those later ones that implement<br>
their own drivers (Windows, Linux) are breaking with the intended<br>
paradigm.<br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a></blockquote></div>
</div></div><br>--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br></blockquote></div><br></div>