Talos 2 Heads fixes

[SergiiDmytruk]

Not sure if this is the right branch to send this, but it's the one used to build Heads.

The Makefile.inc change seems uncontroversial (might want a separate variable to reduce duplication, but not sure how to call it).

skiboot change might need adjustments if there were reasons for hard-coding the value.

[macpijan]

@krystian-hebel @IgorBagnucki Please review

[SergiiDmytruk]

Dropped ppc64le commit as unnecessary and merged two commits related to $(SBSIGNTOOLS) into one.

[macpijan]

@krystian-hebel Any more comments? If no, I would merge that.

[krystian-hebel]

Does it even work without manually putting keys in /tmp/keys?

[SergiiDmytruk]

Does it even work without manually putting keys in /tmp/keys?

@krystian-hebel I didn't do anything special like this and coreboot with these patches built and ran fine (loaded skiboot which then hanged on CPU initialization).

I think this copies the keys.

[macpijan]

@krystian-hebel Any more comments here?

@SergiiDmytruk We could use a rebase. Now once we got coreboot boot into Linux, we should be able to push more for merging the heads changes upstream.

[tlaurion]

@macpijan what unblocked petitboot payload boot achievement and what are the actual blockers?

[krystian-hebel]

There were many fixes required, mostly around PCIe and RNG initialization, but the final issue was different implementation of "memory" nodes in Device Tree. Specification actually gives two valid options to do this, but Skiboot expects one while coreboot provided the other:

If a system has multiple ranges of memory, multiple memory nodes can be created, or the ranges can be specified in the reg property of a single memory node.

https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3, section 3.4

Multiple memory nodes give the ability to specify associativity for NUMA systems which is likely the reason why Skiboot requires this format.

Right now kexec syscall from petitboot fails with "function not implemented". We haven't got to debugging it yet, first we want to un-hardcode DT so it can actually be used by people with different configuration than ours.

[macpijan]

@krystian-hebel Any more comments here? It would be nice if we could pick that into Dasharo. We could get rid of this patch in heads then: https://github.com/osresearch/heads/pull/1002/files?authenticity_token=1L0sPgTDozsvXSxy1qkX5YfgGWhYRToowOL1pDpv3mDCfFDqfc9kPj5GFfJWCZU5x%2Br3UD%2FJZImDZMOe%2Brzerw%3D%3D&file-filters%5B%5D=.config&file-filters%5B%5D=.patch&file-filters%5B%5D=No+extension#diff-42854acc0ba21acf791d948fc74be685766bbb2df43923daa5e8f4aa09507e1aR1

[krystian-hebel]

I think this copies the keys.

Indeed it does. I would rather change that line to cp -r .../keys/* $(KEYLOC), after appropriate mkdir so it won't break when someone changes KEYLOC. Or even better, leave that line as it is and do a conditional assignment KEYLOC?=... - that way user should be able to use custom keys (they aren't actually checked against in the current form but may be some day).

[SergiiDmytruk]

@macpijan Should I send an equivalent PR to dasharo/coreboot for merging now that it's approved?

[macpijan]

@SergiiDmytruk Yes you can. We shall use dasharo repo only from now on.