[OpenBIOS] Apple's Open Firmware.

[Jd Lyons]

Now you guys are just talking shop;-)

Just for a lark, I ran detok on a G4 Firmware update.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: g4.fcode
Type: application/octet-stream
Size: 128262 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/openbios/attachments/20180403/93a7ba1b/attachment-0001.obj>
-------------- next part --------------


I?ll have to try and find why it?s finishing prematurely around 27853 bytes.

> On Apr 3, 2018, at 6:09 AM, Joe van Tunen <joevt at shaw.ca> wrote:
> 
> On 4/2/18, 5:30 PM, "Segher Boessenkool" <segher at kernel.crashing.org> wrote:
> 
>    On Mon, Apr 02, 2018 at 11:28:43AM -0700, Joe van Tunen wrote:
>> You couldn't add Apple fcode support because the Apple fcode drivers use different tokens in different firmwares.
> 
>    They use FCode numbers < 800, and they are the same everywhere.  For some
>    reason the didn't use the vendor space (600..7ff) though, but instead
>    reserved FCode #s.
> 
>    (You're right things changed around a bit before NewWorld.  Does
>    anyone care?  Historians, perhaps.)
> 
>    Oh that reminds me...  They do this 16-bit FCode # thing as well, if
>    memory serves lead by an 0f4 token (followed by two bytes).
> 
> 
>    Segher
> 
> I've seen that the compiled fcode has token numbers greater than 0xFFF in the New World Macs. I didn't find the fcode that they are compiled from (need to decompress some parts of rom), and therefore hadn't come to realize that they would need to be tokenized in a special way (if they were sourced from fcode).
> 
> I found the code that checks for 0xF4 in the `get-fc function in the PowerMac G5 compiled fcode. So tokens have three ways to be encoded:
> 
> 0x00, 0x10-0xFF = one byte    0x??
> 0x100-0xFFF     = two bytes   0x0???
> 0x????          = three bytes 0xF4????
> 
> 
>