On 06/15/10 23:52, M. Warner Losh wrote: > In message: <4c187013.5000...@firmworks.com> > Mitch Bradley <w...@firmworks.com> writes: > : Mike Rapoport wrote: > : > Mitch Bradley wrote: > : >> Mike Rapoport wrote: > : >>> Mitch Bradley wrote: > : >>> > : >>>> The second topic is the hypothetical use of OFW as a HAL. That will > : >>>> not happen for several reasons. The opposition to the idea is > : >>>> widespread and deeply held, and there are good arguments to support > : >>>> that opposition. Furthermore, the economic conditions necessary for > : >>>> the creation of such a HAL do not exist in the ARM world, nor indeed > : >>>> in the Linux world in general. (The necessary condition is the > : >>>> ability for one company to impose a substantial change by fiat - > : >>>> essentially a monopoly position.) > : >>>> > : >>>> Shall we agree, then, that any further discussion of the HAL issue is > : >>>> "just for fun", and that nobody needs to feel threatened that it would > : >>>> actually happen? > : >>> > : >>> I've recently worked with vendor versions of U-Boot for advanced ARM > : >>> SoCs. There is already *huge* chunk of HAL code in those versions. And > : >>> if there would be possibility to have callbacks into the firmware > : >>> these chunks would only grow, IMHO. > : >> > : >> How can there be HAL code in U-Boot unless there is already the > : >> possibility to have callbacks into the firmware? > : > > : > Currently it aims to abstract hardware from U-Boot and reuse the same > : > HW access code across operating systems and bootloaders. If this code > : > would have callbacks I afraid the things would became worse. > : > : The only way I can understand what you said is if I assume that by > : "callback", you mean the following sequence: > : > : a) U-boot loads and executes the OS, providing to the OS the address > : of some HW access routines that it can use > : b) The OS calls one of those HW access routines > : c) During the execution of that HW access routine, that routine calls > : "back" into the OS, before returning. So a call into the OS is nested > : inside a call into U-boot resident code. > : > : If that is what you are worried about, it is not what we were > : discussing. We were discussing - and many people were against - step > : (b). > : > : Are you saying that step (b) - the OS calling into routines provided > : by U-Boot - is already the status quo? > > I don't know about status quo, but it certainly is supported. There's > an option to allow for a secondary boot loader, such as FreeBSD's > /boot/loader, to call back into uboot to read things from > flash/disk/whatever, do network access, etc. Not so much a HAL, but > more of an echo of the functionality provided by PC BIOS functions. > /boot/loader can be viewed as a mini OS that calls back into uboot to > have it do things. Once /boot/loader loads FreeBSD, btw, it and uboot > disappear from the scene, so this isn't exactly a HAL situation...
Just for reference, there is a patch request on LKML to enable calling openfirmware from the kernel on OLPC: http://lkml.org/lkml/2010/6/18/336 -Frank _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev