Re: AMD releases open source boot code
Jonathan de Boyne Pollard
>>> OS/2-based projects)?
>>>
>> No you wouldn't. It's replacement firmware, not operating system
>> software.
>>
> Can't we learn something from it though? There will be examples of
> tapping into interfaces that our loader currently has no clue about.
>
Once again: It's not an operating system or an operating system
loader. It's replacement firmware. There won't be any "tapping into
interfaces" because it isn't a loader. It's what loaders (the so-called
"payload") run on top of and use.
And what's this "our loader" business? I for one don't have any stake
in the IBM OS/2 kernel loader. It isn't mine. It's IBM's, last that I
looked.
I know of only three groups outwith IBM that have stakes in OS/2-clone
kernel loaders. The OSFree people have their own loader, which is
(we're told) based upon the old FreeLDR loader from David C. Zimmerli
(not to be confused with the ReactOS FreeLDR). They're the only people
with an interest in "our loader", and they'll tell you as I do that
firmware source code doesn't show how to *use* firmware APIs.
Marty
>>>> Might be able to leverage this for eCS boot code (or future
>>>> OS/2-based projects)?
>>>>
>>> No you wouldn't. It's replacement firmware, not operating system
>>> software.
>>>
>> Can't we learn something from it though? There will be examples of
>> tapping into interfaces that our loader currently has no clue about.
>
> Once again: It's not an operating system or an operating system loader.
> It's replacement firmware. There won't be any "tapping into interfaces"
> because it isn't a loader. It's what loaders (the so-called "payload")
> run on top of and use.
http://www.coreboot.org/Developer_Manual
"The final mainboardinit fragment is mainboard-specific, in C, called
romstage.c. For non-cache-as-RAM targets, it is compiled with romcc. It
includes and uses other C-code fragments for:
1. Initializing MSRs, MTTRs, APIC.
2. Setting up the southbridge minimally ("early setup").
3. Setting up Super I/O serial.
4. Initializing the console.
5. Initializing RAM controller and RAM itself.
..."
Really? None of that is useful? Clearly we don't need to initialize
the RAM controller and things like that, but what about APIC support?
MTRR init examples could have been useful some years back for video
drivers. I'm sure there's some other useful tidbits in there. High IRQ
handling, special memory ranges and meanings, enabling SSE, ...
Just because this stuff is designed to execute from ROM doesn't mean we
can't make use of it.
> And what's this "our loader" business? I for one don't have any stake in
> the IBM OS/2 kernel loader. It isn't mine. It's IBM's, last that I looked.
The loader that we, who use OS/2, use. If you prefer not to be included
in that group, then I won't complain if you don't read yourself into my
statement.
> I know of only three groups outwith IBM that have stakes in OS/2-clone
> kernel loaders. The OSFree people have their own loader, which is (we're
> told) based upon the old FreeLDR loader from David C. Zimmerli (not to
> be confused with the ReactOS FreeLDR). They're the only people with an
> interest in "our loader", and they'll tell you as I do that firmware
> source code doesn't show how to *use* firmware APIs.
I'd be mining for data from under every rock if I were them, and
hopefully they are not as close-minded as you seem to assume.
--
Reverse the parts of the e-mail address to reply by mail.
A.D. Fundum
> Once again: It's not an operating system or an operating
> system loader. It's replacement firmware.
What about the reversed situation, changing/checking certain
BIOS-settings from within the OS? Not just because of the better UI,
but also to allow e.g. a driver to reboot ASAP if a BIOS-setting was
wrong for the eCS environment.
If that requires firmware-level knowledge indeed, I can e.g. imagine
some (configurable) IBM ThinkPad T42-driver which checks the
Speedstep-setting, with an option to change the stetting and reboot if
Steepstep is enabled, the power source is the battery and the built-in
WLAN is required. Practical use: it'll save some time, and one no
longer has to remember to disable Speedstep if one want to use the
WLAN with eCS on battery power.
--
Paul Ratcliffe
<J.deBoynePoll...@NTLWorld.COM> wrote:
> firmware source code doesn't show how to *use* firmware APIs.
It can do, in the absence of any other documentation.
Jonathan de Boyne Pollard
>>
> It can do, in the absence of any other documentation.
>
Not without a lot of work. (And I mean a *lot*. I've done this. It's
a lot of work, even with source code.) And that's quite irrelevant for
sorts of firmware APIs that we're actually talking about here, which are
publicly documented. (I'm having trouble coming up with an example of an
undocumented firmware API that a bootstrap loader would have any
business using.)
Jonathan de Boyne Pollard
>>> tapping into interfaces that our loader currently has no clue about.
>>>
>> Once again: It's not an operating system or an operating system
>> loader. It's replacement firmware. There won't be any "tapping into
>> interfaces" because it isn't a loader. It's what loaders (the
>> so-called "payload") run on top of and use.
>>
> romstage.c. For non-cache-as-RAM targets, it is compiled with romcc.
>
> Really? None of that is useful?
>
Correct. None of it is useful. What part of "is mainboard-specific" is
unclear here? No-one working on the OS/2 kernel loader or a clone who
is in their right mind would make the loader specific to a particular
mainboard. Loaders are generic, that use the abstract interfaces
provided *by* the firmware, without regard to the details of the
particular mainboard at hand.
> Just because this stuff is designed to execute from ROM doesn't mean
> we can't make use of it.
>
No-one said anything about it executing from ROM being the problem. The
fact that it's firmware, not an operating system loader, is what makes
it useless for the purposes of an operating system loader. It's
firmware. It's not an operating system loader. It's code that does a
completely different job, at a different layer of abstraction. How many
times does this point have to be made before it sinks in?
>> And what's this "our loader" business? I for one don't have any stake
>> in the IBM OS/2 kernel loader. It isn't mine. It's IBM's, last that I
>> looked.
>>
> The loader that we, who use OS/2, use. If you prefer not to be
> included in that group, then I won't complain if you don't read
> yourself into my statement.
>
You clearly haven't thought that through. Merely using a loader doesn't
make your the owner of it. And if you aren't the person who is capable
of changing the loader, *even if* this replacement firmware were somehow
relevant to the task of doing so, then you don't belong to the relevant
"we", which in this case is IBM and the people who can modify OS2LDR,
and the other groups that I alluded to. In other words: You're not
included in the relevant "we" any more than I am. You're mistaken to
think that you are.
>> I know of only three groups outwith IBM that have stakes in
>> OS/2-clone kernel loaders. The OSFree people have their own loader,
>> which is (we'retold) based upon the old FreeLDR loader from David C.
>> Zimmerli (not to be confused with the ReactOS FreeLDR). They're the
>> only people with an interest in "our loader", and they'll tell you as
>> I do that firmware source code doesn't show how to *use* firmware APIs.
>>
> I'd be mining for data from under every rock if I were them, and
> hopefully they are not as close-minded as you seem to assume.
>
This isn't about close-mindedness. This is about having some degree of
Clue as to what the task of writing an operating system loader actually
entails, and thus what is and isn't helpful to that task. What is
helpful are things like the PCI BIOS specification, the PnP BIOS
specification, the EFI specification, the Phoenix/IBM/Microsoft INT 13h
extensions specification, the AMD and Intel CPUID specifications, the
AMD and Intel software developers' manuals, and so forth. What isn't
helpful is the source code to one particular machine firmware. One
doesn't need to know how the firmware does its job internally. One
needs to know the interface contract that you and it work to. Rare
indeed is the implementation source code that is useful for knowing the
interface contract. Try reading the Bochs firmware source code and
working out the PnP BIOS or PCI BIOS specifications from it, for
example. (Those in the know will be highly amused at that suggestion.)
You're getting all excited just because of a press announcement for a
five-year-old project, announcing some "free" stuff, and your excitement
is taking the fact that it's "free" to be far more important than the
fact of whether it's even relevant. I'm the person with Clue telling
you that this sort of thing is about as relevant to the job as someone
announcing that they are giving away free pictures of Jamie Lynn
Spears. It's an entertaing sideshow for those with an interest in it,
but it isn't at all useful for the task at hand.
For a fourth time: It's replacement firmware. It's not an operating
system loader, nor an operating system. It's what loaders (the
so-called "payload") run on top of and use. The fact that something is
"free" and recently (re-)announced doesn't automatically make it relevant.
Jonathan de Boyne Pollard
>> loader. It's replacement firmware.
>>
> What about the reversed situation, changing/checking certain
> BIOS-settings from within the OS? Not just because of the better UI,
> but also to allow e.g. a driver to reboot ASAP if a BIOS-setting was
>
The thing is that such "BIOS settings" of that type are, in actual fact,
usually values read from NVRAM and programmed into bus chipset and I/O
chip registers by the firmware at startup. The (obviously little known)
secret is that such things are *re*-programmable by device drivers. One
doesn't need to know what the internal details of the firmware's NVRAM
variable storage is. One has one's own persistent storage for
configuration data, and one simply programs the chip registers how one
wants them, overriding the programming by the firmware. (I say "little
known". It's well-known by device driver writers. There are books on
this stuff that go into detail of the designs -- where the operating
system provides persistent storage for device settings, and what things
one should and shouldn't expect about hardware state in a device driver.)
An example: The "native mode" setting for PCI-to-ATA bridges. It's
programmable, and indeed programmed, by firmwares into the chipset
registers at POST. It's *re*-programmed by operating system device
drivers when they initialize, according to values configured in
operating system settings storage. DOS-Windows 9x and Windows NT device
drivers read a setting from the Windows Registry, for example. Linux
device drivers (would) respect a kernel command-line option, that's
stored in the bootloader configuration database. Even in humble OS/2
such a thing (were an equivalent to exist) would be a command line
option to a DANIS506.ADD line with CONFIG.SYS being the persistent
storage mechanism. The operating systems and their device drivers don't
need to know how the firmware decides whether "native mode" is on or
off, and knowing the internals of how the firmware works is completely
irrelevant to the task. They have their own "on/off" flags and their
own persistent storage and configuration mechanisms.
Many "BIOS settings" are only relevant because of this to DOS-like
operating systems. In operating systems like Windows NT, the design is
often to merely assume that the firmware has left each device in some
reasonably "safe" state, and do one's own initialization and
programming, independent of what the firmware may or may not have done.
As such, the internals of what any firmware does is completely
irrelevant. What is *highly* relevant, in contrast, is the datasheet(s)
for the device concerned.
In other words: To tweak a device into a "good" state that one likes as
a device driver, one doesn't need to restart the system and re-run the
firmware. One doesn't need to know how the firmware works, but how the
device works. And one just programs the device directly. After all,
one *is* the device driver, and that *is* one's job. (-:
Marty
>>>> Can't we learn something from it though? There will be examples of
>>>> tapping into interfaces that our loader currently has no clue about.
>>>>
>>> Once again: It's not an operating system or an operating system
>>> loader. It's replacement firmware. There won't be any "tapping into
>>> interfaces" because it isn't a loader. It's what loaders (the
>>> so-called "payload") run on top of and use.
>>>
>> "The final mainboardinit fragment is mainboard-specific, in C, called
>> romstage.c. For non-cache-as-RAM targets, it is compiled with romcc.
>> It includes and uses other C-code fragments for: [...]"
>>
>> Really? None of that is useful?
>
> Correct. None of it is useful.
Seems at odds with your other statement: "Not without a lot of work."
> What part of "is mainboard-specific" is
> unclear here?
There is a large list of supported motherboards and chipsets on the
page. Such is the nature of low-level hardware interfacing.
>> Just because this stuff is designed to execute from ROM doesn't mean
>> we can't make use of it.
>
> No-one said anything about it executing from ROM being the problem. The
> fact that it's firmware, not an operating system loader, is what makes
> it useless for the purposes of an operating system loader. It's
> firmware. It's not an operating system loader. It's code that does a
> completely different job, at a different layer of abstraction. How many
> times does this point have to be made before it sinks in?
I understood this from the start. I'm not suggesting that someone take
a code snippet and use it directly. I'm saying there's probably some
juicy tidbits that can be learned from it. Nothing more. Maybe not for
a loader... perhaps in a kernel, perhaps for a device driver. If you
don't think so, then your opinion is noted and there's not much point in
arguing further. I'm not trying to convince YOU to use it.
>>> And what's this "our loader" business? I for one don't have any stake
>>> in the IBM OS/2 kernel loader. It isn't mine. It's IBM's, last that I
>>> looked.
>>>
>> The loader that we, who use OS/2, use. If you prefer not to be
>> included in that group, then I won't complain if you don't read
>> yourself into my statement.
>
> You clearly haven't thought that through. Merely using a loader doesn't
> make your the owner of it.
Now you're just being silly and wasting everyone's time. If you thought
I was claiming ownership in some form then you're officially never
welcome in my state of California or my home state of New York.
>>> I know of only three groups outwith IBM that have stakes in
>>> OS/2-clone kernel loaders. The OSFree people have their own loader,
>>> which is (we'retold) based upon the old FreeLDR loader from David C.
>>> Zimmerli (not to be confused with the ReactOS FreeLDR). They're the
>>> only people with an interest in "our loader", and they'll tell you as
>>> I do that firmware source code doesn't show how to *use* firmware APIs.
>>>
>> I'd be mining for data from under every rock if I were them, and
>> hopefully they are not as close-minded as you seem to assume.
>
> This isn't about close-mindedness. This is about having some degree of
> Clue
No... it's really about "I felt like making a snide comment without
honestly looking to see if this could be useful." I don't fault you for
the latter if you have no interest. It's just that there was apparently
enough interest for the former.
Yes, by its manifest, there is nothing here that is appropriate. But in
its implementation details are possibilities.
I'm done.