This is from a thread "UEFI bootkit" on fedora-users mailing list
On 09/20/2012 05:09 AM, Alan Cox wrote:
> The required information for almost all X86 devices is not available.
> You can't build an open firmware for most x86 platforms from public
Is the above assertion true?
--------- Original Message --------
From: The OpenBIOS Mailinglist <openbios(a)openbios.org>
To: Andreas Tobler <andreast(a)fgznet.ch>
Cc: The OpenBIOS Mailinglist <openbios(a)openbios.org>, qemu-ppc List
<qemu-ppc(a)nongnu.org>, Andreas Färber <afaerber(a)suse.de>, Segher Boessenkool
Subject: Re: [OpenBIOS] [Qemu-ppc] FreeBSD powerpc issue
Date: 20/09/12 11:37
> On 31.08.2012, at 22:40, Andreas Tobler wrote:
> > On 27.08.12 23:51, Alexander Graf wrote:
> >> On 27.08.2012, at 13:43, Segher Boessenkool
> >>>>>> How do I flush the TLB?
> >>>>> tlbie, and perhaps tlbsync.
> >>>> The QEMU TLB only caches existing translations, never
> >>> I'm not sure what you mean here? No PowerPC hardware that I
> >>> stores a "this address doesn't go anywhere" tag in
the TLB, either
> >>> (I don't think the architecture allows that even).
> >>> I also don't see what it has to do with the problem. The
> >>> what we think is happening: the CPU has translations for the
> >>> space in its TLB, because it has run it before. The kernel
> >>> the translations but doesn't do TLBIE on those. On real
> >>> the TLB entries are still used. What does QEMU do?
> >> Ah, I see. It depends. QEMU doesn't provide any guarantees that
the TLB survives basically. We don't flush it often for book3s, but it can
still happen. Maybe try to put a printf into the tlb flush handler function?
> > Sorry for the delay, was sick for the past days :(
> > You suggest to add some printf's, am I right to do that in the
cputlb.c tlb_flush()? If not, where did you mean to do that?
> Yup. tlb_flush_page and/or tlb_flush.
Ok. I'll play in this direction.
> > And on a side note, are/were there successful boot results from other
OS's than linux with qemu and OpenBIOS on powerpc?
> Phew. With a bunch of hacks I've had Mac OS X booted into its kernel where
it was happily churning along until it realized that I'm trying to run it on
machine that was too old (g3 beige support got dropped as early as 10.3
> Apart from that, I'm not aware of any successful boots. Maybe haiku?
I got haiku boot until some sort of shell access. But I didn't bother to
play around with it. For me it was important to see that it does not access
OF after running the kernel.
This is in contrary to FreeBSD where we try to access OF after the kernel
has taken over MM.
So I need some sort of mapping or/and call-back stuff to know where I
(kernel) can call the OF routines after the kernel has taken over MM.
Thank you for the response. (And sorry for the formatting, web-mail...)
On 25.08.2012, at 03:05, Blue Swirl <blauwirbel(a)gmail.com> wrote:
> On Sat, Aug 25, 2012 at 9:47 AM, Andreas TObler <andreast(a)fgznet.ch> wrote:
>> On 08/25/12 11:00, Blue Swirl wrote:
>>> On Fri, Aug 24, 2012 at 9:45 PM, Andreas Tobler <andreast(a)fgznet.ch>
>>>> I'm trying to get FreeBSD powerpc running with qemu.
>>>> So far it loads the fbsd loader and the loader loads the kernel.
>>>> The kernel starts booting but it hangs in an endless loop. It tries to
>>>> out a fatal_trap but it looks like the 'of' doesn't work properly
>>>> at this stage.
>>>> I have a remote debugger attached to the kernel and I can see where it
>>>> hangs. But I can not figure out what caused the fatal trap here.
>>>> An 'info registers' in qemu shows the srr0=fff025a4, this, as I
>>>> points to of_client_callback from OpenBIOS. (objdump -dS
>>>> openbios-qemu.nostrip gives me this.)
>>>> qemu is on 1.1.90, iow, a git snapshot from yesterday with OpenBIOS from
>>>> 19th of aug.
>>>> Is there a possibilty to 'debug' the OpenBIOS somehow?
>>> CCing OpenBIOS list too.
>>> We have a built-in debugger in OpenBIOS (maybe not well documented).
>>> Then there's DEBUG_CIF in libopenbios/client.c and it should be
>>> possible to add debugging print statements to forth/system/ciface.fs
>> Oh, thank you. I'll take a look when I'm back on the machine.
>>>> I'm not sure whether it is a kernel issue or an OpenBIOS issue.
>>> The problem could be that there's a MMU fault when the kernel calls
>>> OpenBIOS, maybe because OpenBIOS is no longer mapped (MMU disabled?)
>>> and then the above debugging would not help.
>> Hm, from the FreeBSD kernel code view, I passed several 'of' calls to read
>> the memory regions etc. to map memory. That said, OB is working fine for the
>> I'm not sure where it happens, the fault above. It might be when I start to
>> call 'of' again after I have started the MMU on the FreeBSD kernel side.
>> So, to my understanding, you say it might be an MMU fault, that OB is no
>> longer mapped? Who would be the responsible for this mapping, the FreeBSD
>> kernel or OB?
> Assuming that SRR0 is the fault address (I'm not so familiar with
SRR0 is the fault IP. So if the fault at hand is an instruction fetch fault, yes, that would be the address at fault. If it's a data fault you would have to check DAR for the address it faults in.
It might also help to boot the guest with -d in_asm,cpu,int and check out /tmp/qemu.log afterwards. Search for the IP that faulted and see why exactly it did.
> since it's pointing to the low level entry point this could make
> At least on Sparc, the kernel should save the original MMU mappings
> and restore them on point of entry to OpenBIOS. Alternatively, you
> could try to arrange the code so that after you take control of MMU,
> OpenBIOS is not used anymore. For example, Linux builds an internal
> model of the Open Firmware tree and does not use the OF calls for OF
> tree lookup after the initial probe. I'd suppose NetBSD and OpenBSD
> kernel code could be used for reference since they work on PPC (real
> machines at least, I haven't tried on QEMU).
>> Thanks a lot!
On Sep 10, 2012, at 10:59 PM, openbios-request(a)openbios.org wrote:
> Message: 7
> Date: Sun, 09 Sep 2012 23:33:13 +0100
> From: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
> To: The OpenBIOS Mailinglist <openbios(a)openbios.org>
> Subject: Re: [OpenBIOS] Viewing files on HFS volume
> Message-ID: <504D1929.3050107(a)ilande.co.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> On 06/09/12 13:47, Programmingkid wrote:
>> I am trying to open a Macintosh CD in OpenBIOS. When I use this command to view the files: dir cd:\, I receive an error message stating that mac-parts could not determine the file system on the disc. Has any one been able to view files on a HFS disc?
> IIRC there was a bug reported in the HFS partition calculation code in
> OpenBIOS (possibly my fault after some refactoring?). It shouldn't be
> too difficult to fix, but if you're struggling then I don't mind taking
> a look if you can supply a test image.
Here is the test image you requested. It is a CD image I created in Disk Utility. I couldn't make a HFS volume, so I had to settle with an HFS+ volume. I did test it out and QEMU gave me the same error I saw with an Apple supplied CD.
Thanks for helping.
You commented on my local variable code a while back. I have remade the Array implementation it uses. Let me know what you think.
\ ****** new version *********
: ARRAY ( cellCount -- )
\ Compile-time behavior
CREATE CELLS ALLOT ( cellCount -- ) \ Creates and initializes the instance
\ Run-time behavior
DOES> ( index addr )
SWAP CELLS + ( index addr -- addr1 ) \ Calculates address to return
I'm trying to understand how the 'translations' entry (/cpus/PowerPC,G4
for example) for PPC is created. Or is it taken from a template?
When I use qemu and enter into OF I see translations only up to
80000000-800eb000. When I compare with a real PowerBook G4 I see some
more above 800eb000, for example one which I'm looking for in OpenBIOS
for the OF mapping:
0xff8000000-0xffc00000 -> 0x3fc00000-0x40000000
This mapping describes the OF code mapping/translation of this
In the code I was not able to understand the mechanics, so a hint on how
to read would really be appreciated.
I am trying to open a Macintosh CD in OpenBIOS. When I use this command to view the files: dir cd:\, I receive an error message stating that mac-parts could not determine the file system on the disc. Has any one been able to view files on a HFS disc?
I was building OpenBIOS when I had an idea. What if we had each file that was being compiled displayed in the console. I am sure most people here have seen how QEMU does this when it is being built. It displays the action it is currently doing with the file it is doing the action on. So if it is compiling C source code, you would see CC file.c. This should be what happens when compiling OpenBIOS. It would give the user some idea what is going on. Is this feature something we could implement in OpenBIOS?
On Sep 1, 2012, at 7:51 PM, openbios-request(a)openbios.org wrote:
> Message: 2
> Date: Fri, 31 Aug 2012 13:40:58 -0500
> From: Tarl Neustaedter <tarl-b2(a)tarl.net>
> To: The OpenBIOS Mailinglist <openbios(a)openbios.org>
> Subject: Re: [OpenBIOS] Fwd: [PATCH] Adds local variable support to
> Message-ID: <5041053A.90303(a)tarl.net>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> On 2012-Aug-31 09:50 , Programmingkid wrote:
>> Are you saying my-variable is better than myVariable?
I have changed all my code from camelCase to hyphens.
>> How do global variables get you in trouble in recursion? Do you have
>> an example?
> Not off-hand, we learn to avoid doing that. To construct one - let's
> take a method doing recursion properly, and break it:
> \ Correct way, using stack manipulation
> : fibonacci ( fib -- return ) recursive
> dup 2 >= if ( fib )
> dup 1- fibonnaci ( fib fib-1 )
> swap 2 - fibonnaci ( fib-1 fib-2 )
> + ( fib )
> then ( fib )
> \ Incorrect way - using variable "fib", which will get overwritten
> during recursion
> 0 value fib;
> : fibonnaci ( fib -- return ) recursive
> to fib \ to avoid stack manipulation
> fib 2 < if
> fib exit
> fib 1- fibonnaci ( fib-1)
> fib 2 - fibonnaci ( fib-1 fib-2 )
> + ( fib )
There is nothing to worry about. All the global variables in my code are only used at compile- time - not during runtime.