[OpenPower-Firmware] HDAT documentation

Mon May 24 21:21:58 AEST 2021

On 24.05.2021 07:25, Vasant Hegde wrote:
> On 5/23/21 2:58 AM, Stewart Smith wrote:
>> On Fri, May 21, 2021, at 10:58 AM, Krystian Hebel wrote:
>>> On 20.05.2021 17:29, Stewart Smith wrote:
>>>> On Thu, May 20, 2021, at 8:09 AM, Krystian Hebel wrote:
>>>>> Hi,
>>>>>
>>>>> We are working on coreboot support for POWER9.
>>>>> Recently we have achieved the milestone where we could initialize the
>>>>> memory on the Talos II platform and start the coreboot ramstage 
>>>>> phase [1].
>>>> Oh, that's really cool!
>>>>
>>>> I'd love to know more and any thoughts on getting it going on a 
>>>> Blackbird.
>>>
>>> First we have to finish work on Talos, then we'll see. Given that 
>>> Blackbird
>>> is by design using one CPU and what we did so far is "only" RAM
>>> initialization
>>> it may even be better supported by the current state of code than 
>>> Talos,
>>> unless there are more subtle differences in hardware. Unfortunately, we
>>> don't have access to that platform so we have no way of testing.
>>
>> I'd be tempted to give it a try on mine tbh. Keeping the SBE 
>> code/entry-point?

Right now we keep even the hostboot bootloader, it is what loads 
coreboot from PNOR.
Basically, just HBB partition is replaced with coreboot, as described here:
https://github.com/3mdeb/openpower-coreboot-docs/blob/release_doc/devnotes/documentation.md#running-the-coreboot-on-talos-ii

Starting directly from SEEPROM is on our TODO list (with partial success 
- we had to get rid of
some debugging to fit), but for development keeping everything in one 
place is just easier.

Don't expect too much, at the best you would just get to "Payload not 
loaded" part :)

>>>>> What we would like to achieve next is to start skiboot from coreboot.
>>>>>
>>>>> We can see that there is this HDAT interface between Hostboot and 
>>>>> skiboot
>>>>> [2] which we probably would need to reimplement.
>>>>>
>>>>> Sadly, the documentation says that "The HDAT specification is 
>>>>> currently
>>>>> not public.".
>>>>> Any idea why is that? Can we get some more information about
>>>>> the HDAT somewhere (apart from reading the Hostboot code)?
>>>> I have even better news: skiboot will *happily* take Device Tree 
>>>> instead.
>>>>
>>>> I'd solidly recommend just producing a dtb Device Tree blob for 
>>>> skiboot. It'll save you significant pain.
>>> That is great news! There is support for Device Tree for Arm in 
>>> coreboot.
>>> I'm not sure how much of it is actually implemented, coreboot tends to
>>> keep code base as small as possible, but this is still better than 
>>> nothing.
>>
>> libdtb and libdevicetree are fairly small and self contained, and 
>> using these to serialize out whatever way you keep track of what 
>> hardware exists shouldn't be too difficult if it isn't there already.
>>
>>> Is there any list of the minimal set of entries required in such Device
>>> Tree?
>>> So far I've seen only documentation about the DT produced by 
>>> skiboot, not
>>> the one consumed by it.
>>
>> Yeah, that we never really documented :) >
>> So, you're basically going to want to end up with a device tree 
>> equivalent to what exists after parse_hdat() in core/init.c - which 
>> you can get from a live machine either by hacking skiboot to save off 
>> a dtb somewhere after parse_hdat() and looking at the result, or 
>> dumping out the HDAT and using the skiboot hdat_to_dt unit test in 
>> hdat/test/ (there's a test there for a Witherspoon, but not any other 
>> P9 platform... patches are probably welcome).
>
>
> Patches are most welcome :-)
>
> Other source is: in POWER8 hostboot created device tree and passed it 
> to skiboot. Look into
> /usr/src/devtree  directory under `master-p8` branch of hostboot. This 
> has code to generate device tree for P8 systems.
>
> If you still need HDAT spec please contact Dean (in CC). He should be 
> able to help you.
>
Thanks for the contact. However, if the device tree is possible we will 
probably go that way.
>
>>
>> You'll at least need CPU nodes, xscom and lpc to boot... but doing 
>> the above would likely give you a goal to get full functionality at 
>> runtime.
>>
>> Skiboot should be pretty good at complaining on anything essential 
>> that's missing (we'll assert on it), and also really forgiving of 
>> missing bits (it'll just skip that bit of code).
>>
>>>> Background:
>>>> During initial bringup on POWER7 machines, the FSP would generate 
>>>> HDAT, and thus we had to read it in skiboot (there was no way we 
>>>> were going to convince everyone else to change for something that 
>>>> was just a bit of research at the time), and this was also true for 
>>>> POWER8 when it was a bit of a mixed responsibility between Hostboot 
>>>> and the FSP to generate HDAT. On OpenPOWER POWER8 systems, we got a 
>>>> device tree from hostboot, but this mean Hostboot was producing two 
>>>> data structures with roughly the same data, but sometimes the DT 
>>>> was missing things... and it wasn't as fun as we would have liked. 
>>>> For POWER9, we said "just give us HDAT, it's fine" as a compromise, 
>>>> as at least it's only one bit of code for Hostboot to maintain.
>>>> There are places where P9 skiboot gets everything in DT such as 
>>>> some simulation environments, and pdbg also will use device tree 
>>>> exclusively.
>>>
>>> Thanks for this background. It is exactly this transition from DT on 
>>> POWER8
>>> to no DT on POWER9 that made me believe HDAT is the way to go.
>>
>> I have no idea where POWER10 may be going, but I'd expect skiboot to 
>> always be able to deal with device tree as an input as it's just 
>> soooo much nicer for humans to construct for use in simulation or 
>> alternate ways of IPLing the box.
>
> Yes. skiboot should be able to deal with device tree. Let us know if 
> you hit any issue with that.
Will do. So far in preliminary discovery I did most of the issues are in 
parts not strictly related
to device tree - usually endianness issues in coreboot itself, with 
occasional HRMOR
miscalculation.
> -Vasant
>
>> _______________________________________________
>> OpenPower-Firmware mailing list
>> OpenPower-Firmware at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/openpower-firmware
>>
>
-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com