Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Cameron Craig]

Hi Ahwan,

>​I have requested FSP MR2 but yet to receive it.
>But I checked the FSP file included in ​Apollo_Lake_CB_MR3 release and it has
>the same cksum with the FSP MR3 I have.
>And this Apollo_Lake_CB_MR3 pre-compiled coreboot image is bootable on
>my CRB! :( Confusing...

Yes, it is strange.
Something has changed between coreboot MR3 (not sure which cb version that 
corresponds with) and coreboot 4.6 that breaks compatibility with FSP MR3.

>BTW, I notice this in your config:-
>  CONFIG_CPU_UCODE_BINARIES="blobs/microcode_patch_1.bin"
>
>I didn't set this in my previous configuration.
>Is this from FIT tool?
>I noticed there are 2 files after decomposing with FIT tool, "uCode Patch 
>1.bin"
>& "uCode Patch 2.bin"
>But you only need 1 file here?

Yeah, I must have renamed "uCode Patch 1.bin"  to "microcode_patch_1.bin".
Strictly speaking (to operate within spec) I should probably have the other 
microcode blob there too.

Cheers,
Cameron


Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:  | mobile: 
e: cameron.cr...@exterity.com | w: www.exterity.com



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[ahW@n via coreboot]

Hi Cameron

​
> I have attached the coreboot config and a coreboot patch (originally
provided by Mario, thanks Mario).
> I removed the Oxbow Hill parts of the patch.
>
> My working combination:
> - Coreboot v4.6 (with patch)
> - Apollo Lake FSP MR2
> - Tianocore commit 315d9d08fd77db1024ccc5307823da8aaed85e2f (with patches)

​I have requested FSP MR2 but yet to receive it.
But I checked the FSP file included in ​Apollo_Lake_CB_MR3 release and it
has the same cksum with the FSP MR3 I have.
And this Apollo_Lake_CB_MR3 pre-compiled coreboot image is bootable on my
CRB! :( Confusing...
Anyway, good to know that your FSP MR2 is working.
I think will just wait for the MR2 and check again.

BTW, I notice this in your config:-
  CONFIG_CPU_UCODE_BINARIES="blobs/microcode_patch_1.bin"
I didn't set this in my previous configuration.
Is this from FIT tool?
I noticed there are 2 files after decomposing with FIT tool, "uCode Patch
1.bin" & "uCode Patch 2.bin"
But you only need 1 file here?

Thank you.
​-ahwan​
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Cameron Craig]

Hi Tahnia,

>Which version of Tianocore did you use? Did you make any changes to
>Tianocore to get it to work (because it still doesn't work for me)? E.g. did 
>you
>have to change debug console port settings (similar to those needed for
>SeaBIOS to use MMIO serial)?
>
>Did you specify the GOP driver in coreboot, and if so, which file did you use?
>Or did you include the GOP driver in the Tianocore build?
>
>Would you by any chance be willing to share the coreboot and Tianocore
>config files for your working combination?
>
>Regards,
>Tahnia

I have attached the coreboot config and a coreboot patch (originally provided 
by Mario, thanks Mario).
I removed the Oxbow Hill parts of the patch.

My working combination:
- Coreboot v4.6 (with patch)
- Apollo Lake FSP MR2
- Tianocore commit 315d9d08fd77db1024ccc5307823da8aaed85e2f (with patches)

Other Tianocore versions may also work, but I haven't tested them.
I don't get any serial output from Tianocore so I suspect I don't have serial 
configured correctly.

Coreboot 4.6 does the fetch and patch of Tianocore for you, and it just worked.

Cheers,
Cameron



Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:  | mobile: 
e: cameron.cr...@exterity.com | w: www.exterity.com



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


changes.diff
Description: changes.diff


coreboot_config
Description: coreboot_config
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Tahnia Lichtenstein]

Hi Cameron,

Which version of Tianocore did you use? Did you make any changes to
Tianocore to get it to work (because it still doesn't work for me)? E.g.
did you have to change debug console port settings (similar to those needed
for SeaBIOS to use MMIO serial)?

Did you specify the GOP driver in coreboot, and if so, which file did you
use? Or did you include the GOP driver in the Tianocore build?

Would you by any chance be willing to share the coreboot and Tianocore
config files for your working combination?

Regards,
Tahnia

On Thu, Nov 9, 2017 at 4:53 PM, Cameron Craig 
wrote:

> Hi Ahwan,
>
> >So, we can only expect Intel to solve this issue with new FSP package?
> >Please keep us update, thank you.
>
> I managed to get my hands on APL FSP MR2 and I can confirm that it just
> works. I have tested it with Tianocore.
> This is at least a short term solution. I have not looked in to why MR3
> doesn’t work and currently have no plans on doing so.
>
> Cheers,
> Cameron
>
>
> Cameron Craig | Graduate Software Engineer | Exterity Limited
> tel: +44 1383 828 250 | fax:  | mobile:
> e: cameron.cr...@exterity.com | w: www.exterity.com
>
>
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Cameron Craig]

Hi Ahwan,

>So, we can only expect Intel to solve this issue with new FSP package?
>Please keep us update, thank you.

I managed to get my hands on APL FSP MR2 and I can confirm that it just works. 
I have tested it with Tianocore.
This is at least a short term solution. I have not looked in to why MR3 doesn’t 
work and currently have no plans on doing so.

Cheers,
Cameron


Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:  | mobile: 
e: cameron.cr...@exterity.com | w: www.exterity.com



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Zoran Stojsavljevic]

> The vbt.dat (5kB) is need by GOP driver. But we haven’t done anything
with that yet.


Mario,


Your English is much better, as I remembered it. Way! ;-)


And from me the present/gift for/to the cause:
https://en.wikipedia.org/wiki/Coreboot/VBT


Zoran

On Mon, Nov 6, 2017 at 10:32 AM, Scheithauer, Mario <
mario.scheitha...@siemens.com> wrote:

> Hi all,
>
>
>
> > •Are you able to boot Yocto with the current combination you
> have?
>
> We haven’t tested Yocto, but we can boot a Lubuntu.
>
> > Where did you obtain a VBIOS file?
>
> Intel provides the VBIOS in its MRx packages for the CRBs. You need to
> contact Intel for this.
>
> > •Is it specifically VBIOS, or is it a VBT.dat file? Or are you
> running SeaVGABIOS?
>
> I think you need a complete VBIOS bxt_1003.dat (64kB) for SeaBios.
>
> The vbt.dat (5kB) is need by GOP driver. But we haven’t done anything with
> that yet.
>
>
>
> Mario
>
>
>
>
>
> *Von:* Tahnia Lichtenstein [mailto:unl...@gmail.com]
> *Gesendet:* Freitag, 3. November 2017 13:46
> *An:* Scheithauer, Mario (DF MC MTS R&D SWRT 4); coreboot@coreboot.org
>
> *Betreff:* Re: [coreboot] Problems changing payload on Intel Leaf Hill
>
>
>
> Hi Mario,
>
>
>
> Thank you very much for sharing, that already helps a lot!! I can spot
> quite a lot of differences to my own build settings.
>
>
>
> I've been pursuing a Grub2 payload in the meantime (no success so far),
> will now return to SeaBIOS and try and incorporate the necessary changes
> you suggested.
>
>
>
> Just a couple of questions so far:
>
>- Are you able to boot Yocto with the current combination you have?
>- I have all the blobs around coreboot, except the VBIOS... I have
>tried all the options in https://www.coreboot.org/VGA_support, but I
>suspect the reference bootloader images provided by Intel does not use a
>VBIOS file. I also cannot find a suitable VBIOS on Intel's website. (By the
>way, thanks for the FIT decomposition tip, I did not know this was
>possible... I took great pains to find the correct blobs on Intel's
>website, would have been much easier to just use FIT!) Where did you obtain
>a VBIOS file?
>- Is it specifically VBIOS, or is it a VBT.dat file? Or are you
>running SeaVGABIOS?
>
> Many thanks again!
>
>
>
> Best regards,
>
> Tahnia
>
>
>
> On Fri, Nov 3, 2017 at 2:01 PM, Scheithauer, Mario <
> mario.scheitha...@siemens.com> wrote:
>
>
> Hi Cameron,
>
> > Did you modify the FSP blobs at all?
> Yes, we made some adjustments for our mainboard (mc_apl1).
> But they shouldn’t play a decisive role (power states, PCIe settings).
>
> > The reason I ask is that my coreboot build hangs in the FspSiliconInit().
> Then you will get pretty far.
> We are currently still using the MR2 FSP package for APL-I.
> As IFWI template we use the BIOS version v178.10 for the CRBs.
> These components are provided by Intel.
> That’s it. The CRB should boot with this combination.
>
> Mario
>
> > -Ursprüngliche Nachricht-
> > Von: Cameron Craig [mailto:cameron.cr...@exterity.com]
> > Gesendet: Freitag, 3. November 2017 11:51
> > An: Scheithauer, Mario (DF MC MTS R&D SWRT 4); ahW@n
> > Cc: coreboot@coreboot.org
> > Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill
>
> >
> > Hi Mario,
> >
> > I've been attempting to build coreboot(master) for the Leaf Hill CRB,
> with no
> > success so far.
> >
> > Did you modify the FSP blobs at all?
> > I had a look at your config, the filenames "FSP_MR2_M_ECC_MOD" caught my
> > eye.
> >
> > The reason I ask is that my coreboot build hangs in the FspSiliconInit().
> >
> > Cheers,
> > Cameron
> >
> >
> >
> > Cameron Craig | Graduate Software Engineer | Exterity Limited
> > tel: +44 1383 828 250 | fax:  | mobile:
> > e: cameron.cr...@exterity.com | w: www.exterity.com
> >
> >
> >
> > 
> > __
> > This email has been scanned by the Symantec Email Security.cloud service.
> > For more information please visit http://www.symanteccloud.com
> > 
> > __
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[ahW@n via coreboot]

Hi Tahnia,

I didn't aware of this Apollo_Lake_CB_MR package at all. Thanks for your
info.
As for the CONFIG_VGA_BIOS_FILE=bxt_1003.dat, after some studies I think I
can extract this video rom from a bootable bios.
But I still not sure CONFIG_VBT_FILE referring to Vbt.bin which i can
obtain from Apollo_Lake_FSP_MR3/Vbt
I will try out.


Cameron,
You are right.
It shouldn't be wrong as it checks through the image.
So, we can only expect Intel to solve this issue with new FSP package?
Please keep us update, thank you.

Maybe I have to ask my FAE if they still able to send me previous
Apollo_Lake_CB_MR
package as what Tahnia mentioned. ***Cross finger***

- ahwan


On Tue, Nov 7, 2017 at 6:00 PM, Cameron Craig 
wrote:

> Hi Ahwan,
>
> >Checked the postcodes and yes, last code is 0x93.
> >And from the debug I noticed there are a lot of "CBFS:  Unmatched x"
> >print out.
> >Do you get similar outputs from yours?
>
> Yes, I get a similar output (attached).
>
> I'm not concerned about the "CBFS: Unmatched..." debug messages (still
> returns 0 for "Success") [1].
> But what I would be concerned about is if you get a log message "xxx not
> found".
> If it describes something you are expecting it to find, then there is a
> problem.
>
> [1]: https://github.com/coreboot/coreboot/blob/
> fec0328c5f653233859d4aec7dae0b94acb67e97/src/commonlib/cbfs.c#L204
>
> Cheers,
> Cameron
>
>
> Cameron Craig | Graduate Software Engineer | Exterity Limited
> tel: +44 1383 828 250 | fax:  | mobile:
> e: cameron.cr...@exterity.com | w: www.exterity.com
>
>
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Cameron Craig]

Hi Ahwan,

>Checked the postcodes and yes, last code is 0x93.
>And from the debug I noticed there are a lot of "CBFS:  Unmatched x"
>print out.
>Do you get similar outputs from yours?

Yes, I get a similar output (attached).

I'm not concerned about the "CBFS: Unmatched..." debug messages (still returns 
0 for "Success") [1]. 
But what I would be concerned about is if you get a log message "xxx not found".
If it describes something you are expecting it to find, then there is a problem.

[1]: 
https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b94acb67e97/src/commonlib/cbfs.c#L204

Cheers,
Cameron


Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:  | mobile: 
e: cameron.cr...@exterity.com | w: www.exterity.com



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
coreboot-4.6-1941-g383ef6e-dirty Wed Nov  1 21:59:08 UTC 2017 bootblock 
starting...
FMAP: Found "FLASH" version 1.1 at 30.
FMAP: base = 0 size = 100 #areas = 11
FMAP: area COREBOOT found @ 300800 (12179456 bytes)
CBFS @ 300800 size b9d800
CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
CBFS: Locating 'fallback/romstage'
CBFS: Found @ offset 80 size 72f4


coreboot-4.6-1941-g383ef6e-dirty Wed Nov  1 21:59:08 UTC 2017 romstage 
starting...
pm1_sts: 8100 pm1_en:  pm1_cnt: 
gpe0_sts[0]:  gpe0_en[0]: 8000
gpe0_sts[1]:  gpe0_en[1]: 
gpe0_sts[2]:  gpe0_en[2]: 
gpe0_sts[3]:  gpe0_en[3]: 
prsts:  tco_sts: 0008
gen_pmcon1: 08004000 gen_pmcon2: 3a00 gen_pmcon3: 
prev_sleep_state 0
FMAP: Found "FLASH" version 1.1 at 30.
FMAP: base = 0 size = 100 #areas = 11
FMAP: area COREBOOT found @ 300800 (12179456 bytes)
CBFS @ 300800 size b9d800
CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
CBFS: Locating 'fspm.bin'
CBFS: Found @ offset 18780 size 59000
POST: 0x34
FMAP: area RW_MRC_CACHE found @ eae000 (65536 bytes)
REGF fail reading first metadata block.
MRC: region file invalid in 'RW_MRC_CACHE'
FMAP: area RW_VAR_MRC_CACHE found @ ebe000 (4096 bytes)
REGF fail reading first metadata block.
MRC: region file invalid in 'RW_VAR_MRC_CACHE'
Calling FspMemoryInit: 0xfef403f0
0xfef03cb0: raminit_upd
0xfef04d14: &hob_list_ptr
POST: 0x92
POST: 0x98
FspMemoryInit returned 0x
CBMEM:
IMD: root @ 7afff000 254 entries.
IMD: root @ 7affec00 62 entries.
External stage cache:
IMD: root @ 7b7ff000 254 entries.
IMD: root @ 7b7fec00 62 entries.
CPU: frequency set to 2000 MHz
WEAK: src/soc/intel/apollolake/romstage.c/mainboard_save_dimm_info called
MTRR Range: Start=7a00 End=7b00 (Size 100)
MTRR Range: Start=ff00 End=0 (Size 100)
MTRR Range: Start=7b00 End=7b80 (Size 80)
FMAP: area COREBOOT found @ 300800 (12179456 bytes)
CBFS @ 300800 size b9d800
CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
CBFS: Locating 'fallback/postcar'
CBFS: Found @ offset ad2c0 size 421c
Decompressing stage fallback/postcar @ 0x7abc6fc0 (33544 bytes)
Loading module at 7abc7000 with entry 7abc7000. filesize: 0x3fd0 memsize: 0x82c8
Processing 124 relocs. Offset value of 0x78bc7000


coreboot-4.6-1941-g383ef6e-dirty Wed Nov  1 21:59:08 UTC 2017 postcar 
starting...
FMAP: Found "FLASH" version 1.1 at 30.
FMAP: base = 0 size = 100 #areas = 11
FMAP: area COREBOOT found @ 300800 (12179456 bytes)
CBFS @ 300800 size b9d800
CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset 7440 size 10daf
Decompressing stage fallback/ramstage @ 0x7ab90fc0 (213040 bytes)
Loading module at 7ab91000 with entry 7ab91000. filesize: 0x22838 memsize: 
0x33ff0
Processing 2146 relocs. Offset value of 0x7aa91000


coreboot-4.6-1941-g383ef6e-dirty Wed Nov  1 21:59:08 UTC 2017 ramstage 
starting...
POST: 0x39
POST: 0x80
POST: 0x70
BS: BS_PRE_DEVICE times (us): entry 2 run 1172 exit 0
POST: 0x71
FMAP: Found "FLASH" version 1.1 at 30.
FMAP: base = 0 size = 100 #areas = 11
FMAP: area COREBOOT found @ 300800 (12179456 bytes)
CBFS @ 300800 size b9d800
CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
CBFS: Locating 'fsps.bin'
CBFS: Found @ offset 717c0 size 2a000
FMAP: area COREBOOT found @ 300800 (12179456 bytes)
CBFS @ 300800 size b9d800
CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
CBFS: Locating 'vbt.bin'
CBFS: Found @ offset 9b800 size 1a00
Calling FspSiliconInit: 0x7ab6658a
0x7abb7b70: upd
POST: 0x93-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Tahnia Lichtenstein]

Hi Mario, Cameron, coreboot folks,

Thank you all so much for the help!! I managed to get SeaBIOS to work
(technically it was running all along, there was just no output and hence
no evidence to believe it ran.)

As I mentioned previously, I am not running coreboot master branch, instead
using the Intel-distributed variant based on an outdated coreboot commit
(Apollo_Lake_CB_MR1). So my config might not be useful to all who are using
coreboot master. But it is attached nonetheless.

I had previously tried including the bxt_1003.dat, when this didn't work I
tried using vbt.dat, but I think I might have configured them in the wrong
places. It works when I include both.

Also, Craig, thanks! I previously used the wrong bootloader image to try
and extract the VBIOS with the UEFItool (tried using Intel's precompiled
coreboot image with UEFI payload, named "coreboot.release.SPI.Bx.Win.bin",
which does not contain any VBIOS image, for some reason). It does work when
I extract it from Intel's UEFI image, named
"APLI_IFWI_X64_R_113_40E_SPI.bin".

On my build, it was not necessary to manually update the CBFS locations for
SeaBIOS.

But it was necessary to update the MMIO mapping for debug UART output.
Brilliant, I would never have figured this out.

In which document do I find the MMIO mapping again? I think I did read it
at some point but it got lost between the mass of information! (I'm new to
Intel architecture, coreboot, all payloads, and bootloader development in
general! Massive learning curve, too much information to absorb at once!)

I suspect similar changes would be required to witness output from
Tianocore, will try that soon.

Thanks to all again, I really really appreciate it! (Would send virtual
beer by manner of thanks, is that acceptable?)

Tahnia


On Mon, Nov 6, 2017 at 11:32 AM, Scheithauer, Mario <
mario.scheitha...@siemens.com> wrote:

> Hi all,
>
>
>
> > •Are you able to boot Yocto with the current combination you
> have?
>
> We haven’t tested Yocto, but we can boot a Lubuntu.
>
> > Where did you obtain a VBIOS file?
>
> Intel provides the VBIOS in its MRx packages for the CRBs. You need to
> contact Intel for this.
>
> > •Is it specifically VBIOS, or is it a VBT.dat file? Or are you
> running SeaVGABIOS?
>
> I think you need a complete VBIOS bxt_1003.dat (64kB) for SeaBios.
>
> The vbt.dat (5kB) is need by GOP driver. But we haven’t done anything with
> that yet.
>
>
>
> Mario
>
>
>
>
>
> *Von:* Tahnia Lichtenstein [mailto:unl...@gmail.com]
> *Gesendet:* Freitag, 3. November 2017 13:46
> *An:* Scheithauer, Mario (DF MC MTS R&D SWRT 4); coreboot@coreboot.org
> *Betreff:* Re: [coreboot] Problems changing payload on Intel Leaf Hill
>
>
>
> Hi Mario,
>
>
>
> Thank you very much for sharing, that already helps a lot!! I can spot
> quite a lot of differences to my own build settings.
>
>
>
> I've been pursuing a Grub2 payload in the meantime (no success so far),
> will now return to SeaBIOS and try and incorporate the necessary changes
> you suggested.
>
>
>
> Just a couple of questions so far:
>
>- Are you able to boot Yocto with the current combination you have?
>- I have all the blobs around coreboot, except the VBIOS... I have
>tried all the options in https://www.coreboot.org/VGA_support, but I
>suspect the reference bootloader images provided by Intel does not use a
>VBIOS file. I also cannot find a suitable VBIOS on Intel's website. (By the
>way, thanks for the FIT decomposition tip, I did not know this was
>possible... I took great pains to find the correct blobs on Intel's
>website, would have been much easier to just use FIT!) Where did you obtain
>a VBIOS file?
>- Is it specifically VBIOS, or is it a VBT.dat file? Or are you
>running SeaVGABIOS?
>
> Many thanks again!
>
>
>
> Best regards,
>
> Tahnia
>
>
>
> On Fri, Nov 3, 2017 at 2:01 PM, Scheithauer, Mario <
> mario.scheitha...@siemens.com> wrote:
>
>
> Hi Cameron,
>
> > Did you modify the FSP blobs at all?
> Yes, we made some adjustments for our mainboard (mc_apl1).
> But they shouldn’t play a decisive role (power states, PCIe settings).
>
> > The reason I ask is that my coreboot build hangs in the FspSiliconInit().
> Then you will get pretty far.
> We are currently still using the MR2 FSP package for APL-I.
> As IFWI template we use the BIOS version v178.10 for the CRBs.
> These components are provided by Intel.
> That’s it. The CRB should boot with this combination.
>
> Mario
>
> > -Ursprüngliche Nachricht-
> > Von: Cameron Craig [mailto:cameron.cr...@exterity.com]
> > Gesendet: 

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Tahnia Lichtenstein]

Hi Ahwan,

CONFIG_VGA_BIOS_ID="1106,3230"  (how to know and confirm this is my ID? is
this important?)

Run a linux instance on the board (using the BIOS/bootloader that came with
the board) and run the following command in a linux terminal:
lspci -nn

This will give you a list of PCI devices with their device ID's, search for
the VGA device in this list. On my Oxbow Hill the VGA device's ID
is 8086,5a84 (I think most onboard Intel devices start with 8086, and I
think Intel's display devices are standardised to be either 5a84 or 5a85...
but I am speaking under correction).

I have this configured (and at last it's working, yay Much joy!)
CONFIG_VGA_BIOS_ID="8086,5a84"
# CONFIG_ONBOARD_VGA_IS_PRIMARY is not set
CONFIG_VGA_BIOS=y
CONFIG_VGA_BIOS_FILE="../intel/fsp/mainboard/leafhill/bxt_1003.dat" (this
file came with the Intel distribution of coreboot,
named Apollo_Lake_CB_MR1, Apollo_Lake_CB_MR2 or Apollo_Lake_CB_MR3. You can
ask your FAE for these folders, as I think the links are no longer
available for download anymore.)
CONFIG_GOP_SUPPORT=y
CONFIG_VBT_FILE="../intel/fsp/mainboard/leafhill/vbt.dat"

My config file is attached, but I am not currently using coreboot master, I
am using the above mentioned Intel variants of coreboot (based on very
outdated coreboot commit!) So there will be drastic differences with
regards to coreboot architecture, and not sure if my VGA setup will work
with coreboot master branch. Not sure yet if I am going to migrate to
coreboot master branch.

Good luck :)

Tahnia

On Tue, Nov 7, 2017 at 5:59 AM, ahW@n via coreboot 
wrote:

> Hi Cameron,
>
> Checked the postcodes and yes, last code is 0x93.
> And from the debug I noticed there are a lot of *"CBFS:  Unmatched x"*
> print out.
> Do you get similar outputs from yours?
>
> BTW, still wondering I was using the correct binaries in my config or not.
> What about yours settings for these ... :-
>CONFIG_VGA_BIOS_ID="1106,3230"  (how to know and confirm this is my
> ID? is this important?)
>
> CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/intel/apollolake_rvp/Vbt.bsf"
> (I have Vbt.bin and Vbt.bsf downloaded from Intel FSP_MR3, am I pionting to
> the correct one?)
>CONFIG_FMDFILE="src/mainboard/intel/leafhill/
> leafhill.$(CONFIG_COREBOOT_ROMSIZE_KB).fmd" (OK to use fmd from leafhill?)
>CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/
> intel/apollolake_rvp/Vbt.bin"
>
> CONFIG_CHECKLIST_DATA_FILE_LOCATION="src/vendorcode/intel/fsp/fsp2_0/checklist"
> (I actually didn't see this file exist, is this important?)
>
> ​Thank you.
> - ahwan​
>
>
> On Mon, Nov 6, 2017 at 10:45 PM, Cameron Craig  > wrote:
>
>> Hi Ahwan,
>>
>> >coreboot-4.6-1941-g383ef6e-dirty Wed Nov  1 21:59:08 UTC 2017 ramstage
>> >starting...
>> >BS: BS_PRE_DEVICE times (us): entry 2 run 2 exit 0
>> >FMAP: Found "FLASH" version 1.1 at 30.
>> >FMAP: base = 0 size = 100 #areas = 11
>> >FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size
>> >b9d800
>> >CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
>> >CBFS: Locating 'fsps.bin'
>> >CBFS: Found @ offset 717c0 size 2a000
>> >FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size
>> >b9d800
>> >CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
>> >CBFS: Locating 'vbt.bin'
>> >CBFS: Found @ offset 9b800 size 1a00
>> >
>> >
>> >I think I totally lost :(
>> >please let me know if you have any idea on how I can debug further.
>> >Thank you.
>> >
>> >-ahwan
>>
>> To me this looks like the FspSiliconInit() hang that a few of us are
>> experiencing with the ApolloLake FSP MR3.
>>
>> This has been raised with Intel. In the meantime I'm trying to get my
>> hands on the MR2 FSP (which should just work) through my Intel rep.
>>
>> You could turn on postcodes in the coreboot menuconfig, and if the last
>> postcode is 0x93 (about to call FspSiliconInit()), then you might have the
>> same problem.
>>
>> Cheers,
>> Cameron
>>
>>
>>
>>
>> Cameron Craig | Graduate Software Engineer | Exterity Limited
>> tel: +44 1383 828 250 | fax:  | mobile:
>> e: cameron.cr...@exterity.com | w: www.exterity.com
>>
>>
>>
>> __
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com
>> __
>>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>


coreboot_seabios_vga_working.config
Description: XML document
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[ahW@n via coreboot]

Hi Cameron,

Checked the postcodes and yes, last code is 0x93.
And from the debug I noticed there are a lot of *"CBFS:  Unmatched x"*
print out.
Do you get similar outputs from yours?

BTW, still wondering I was using the correct binaries in my config or not.
What about yours settings for these ... :-
   CONFIG_VGA_BIOS_ID="1106,3230"  (how to know and confirm this is my ID?
is this important?)
   CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/intel/apollolake_rvp/Vbt.bsf"
(I have Vbt.bin and Vbt.bsf downloaded from Intel FSP_MR3, am I pionting to
the correct one?)
   
CONFIG_FMDFILE="src/mainboard/intel/leafhill/leafhill.$(CONFIG_COREBOOT_ROMSIZE_KB).fmd"
(OK to use fmd from leafhill?)
   CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/intel/ap
ollolake_rvp/Vbt.bin"
   
CONFIG_CHECKLIST_DATA_FILE_LOCATION="src/vendorcode/intel/fsp/fsp2_0/checklist"
(I actually didn't see this file exist, is this important?)

​Thank you.
- ahwan​


On Mon, Nov 6, 2017 at 10:45 PM, Cameron Craig 
wrote:

> Hi Ahwan,
>
> >coreboot-4.6-1941-g383ef6e-dirty Wed Nov  1 21:59:08 UTC 2017 ramstage
> >starting...
> >BS: BS_PRE_DEVICE times (us): entry 2 run 2 exit 0
> >FMAP: Found "FLASH" version 1.1 at 30.
> >FMAP: base = 0 size = 100 #areas = 11
> >FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size
> >b9d800
> >CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
> >CBFS: Locating 'fsps.bin'
> >CBFS: Found @ offset 717c0 size 2a000
> >FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size
> >b9d800
> >CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
> >CBFS: Locating 'vbt.bin'
> >CBFS: Found @ offset 9b800 size 1a00
> >
> >
> >I think I totally lost :(
> >please let me know if you have any idea on how I can debug further.
> >Thank you.
> >
> >-ahwan
>
> To me this looks like the FspSiliconInit() hang that a few of us are
> experiencing with the ApolloLake FSP MR3.
>
> This has been raised with Intel. In the meantime I'm trying to get my
> hands on the MR2 FSP (which should just work) through my Intel rep.
>
> You could turn on postcodes in the coreboot menuconfig, and if the last
> postcode is 0x93 (about to call FspSiliconInit()), then you might have the
> same problem.
>
> Cheers,
> Cameron
>
>
>
>
> Cameron Craig | Graduate Software Engineer | Exterity Limited
> tel: +44 1383 828 250 | fax:  | mobile:
> e: cameron.cr...@exterity.com | w: www.exterity.com
>
>
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
>


coreboot.3.log
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Cameron Craig]

Hi Ahwan,

>coreboot-4.6-1941-g383ef6e-dirty Wed Nov  1 21:59:08 UTC 2017 ramstage
>starting...
>BS: BS_PRE_DEVICE times (us): entry 2 run 2 exit 0
>FMAP: Found "FLASH" version 1.1 at 30.
>FMAP: base = 0 size = 100 #areas = 11
>FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size
>b9d800
>CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
>CBFS: Locating 'fsps.bin'
>CBFS: Found @ offset 717c0 size 2a000
>FMAP: area COREBOOT found @ 300800 (12179456 bytes) CBFS @ 300800 size
>b9d800
>CBFS: 'IAFW Locator' located CBFS at [300800:e9e000)
>CBFS: Locating 'vbt.bin'
>CBFS: Found @ offset 9b800 size 1a00
>
>
>I think I totally lost :(
>please let me know if you have any idea on how I can debug further.
>Thank you.
>
>-ahwan

To me this looks like the FspSiliconInit() hang that a few of us are 
experiencing with the ApolloLake FSP MR3.

This has been raised with Intel. In the meantime I'm trying to get my hands on 
the MR2 FSP (which should just work) through my Intel rep.

You could turn on postcodes in the coreboot menuconfig, and if the last 
postcode is 0x93 (about to call FspSiliconInit()), then you might have the same 
problem.

Cheers,
Cameron




Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:  | mobile: 
e: cameron.cr...@exterity.com | w: www.exterity.com



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Scheithauer, Mario]

Hi all,

> •Are you able to boot Yocto with the current combination you have?
We haven’t tested Yocto, but we can boot a Lubuntu.
> Where did you obtain a VBIOS file?
Intel provides the VBIOS in its MRx packages for the CRBs. You need to contact 
Intel for this.
> •Is it specifically VBIOS, or is it a VBT.dat file? Or are you 
> running SeaVGABIOS?
I think you need a complete VBIOS bxt_1003.dat (64kB) for SeaBios.
The vbt.dat (5kB) is need by GOP driver. But we haven’t done anything with that 
yet.

Mario


Von: Tahnia Lichtenstein [mailto:unl...@gmail.com]
Gesendet: Freitag, 3. November 2017 13:46
An: Scheithauer, Mario (DF MC MTS R&D SWRT 4); coreboot@coreboot.org
Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill

Hi Mario,

Thank you very much for sharing, that already helps a lot!! I can spot quite a 
lot of differences to my own build settings.

I've been pursuing a Grub2 payload in the meantime (no success so far), will 
now return to SeaBIOS and try and incorporate the necessary changes you 
suggested.

Just a couple of questions so far:

  *   Are you able to boot Yocto with the current combination you have?
  *   I have all the blobs around coreboot, except the VBIOS... I have tried 
all the options in https://www.coreboot.org/VGA_support, but I suspect the 
reference bootloader images provided by Intel does not use a VBIOS file. I also 
cannot find a suitable VBIOS on Intel's website. (By the way, thanks for the 
FIT decomposition tip, I did not know this was possible... I took great pains 
to find the correct blobs on Intel's website, would have been much easier to 
just use FIT!) Where did you obtain a VBIOS file?
  *   Is it specifically VBIOS, or is it a VBT.dat file? Or are you running 
SeaVGABIOS?
Many thanks again!

Best regards,
Tahnia

On Fri, Nov 3, 2017 at 2:01 PM, Scheithauer, Mario 
mailto:mario.scheitha...@siemens.com>> wrote:

Hi Cameron,

> Did you modify the FSP blobs at all?
Yes, we made some adjustments for our mainboard (mc_apl1).
But they shouldn’t play a decisive role (power states, PCIe settings).

> The reason I ask is that my coreboot build hangs in the FspSiliconInit().
Then you will get pretty far.
We are currently still using the MR2 FSP package for APL-I.
As IFWI template we use the BIOS version v178.10 for the CRBs.
These components are provided by Intel.
That’s it. The CRB should boot with this combination.

Mario

> -Ursprüngliche Nachricht-
> Von: Cameron Craig 
> [mailto:cameron.cr...@exterity.com<mailto:cameron.cr...@exterity.com>]
> Gesendet: Freitag, 3. November 2017 11:51
> An: Scheithauer, Mario (DF MC MTS R&D SWRT 4); ahW@n
> Cc: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
> Betreff: RE: [coreboot] Problems changing payload on Intel Leaf Hill
>
> Hi Mario,
>
> I've been attempting to build coreboot(master) for the Leaf Hill CRB, with no
> success so far.
>
> Did you modify the FSP blobs at all?
> I had a look at your config, the filenames "FSP_MR2_M_ECC_MOD" caught my
> eye.
>
> The reason I ask is that my coreboot build hangs in the FspSiliconInit().
>
> Cheers,
> Cameron
>
>
>
> Cameron Craig | Graduate Software Engineer | Exterity Limited
> tel: +44 1383 828 250 | fax:  | mobile:
> e: cameron.cr...@exterity.com<mailto:cameron.cr...@exterity.com> | w: 
> www.exterity.com<http://www.exterity.com>
>
>
>
> 
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> 
> __
--
coreboot mailing list: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[ahW@n via coreboot]

ally lost :(
please let me know if you have any idea on how I can debug further.
Thank you.

-ahwan


On Fri, Nov 3, 2017 at 6:18 PM, Scheithauer, Mario <
mario.scheitha...@siemens.com> wrote:

> Hi Ahwan,
>
>
>
> Oh sorry, I forgot to attach the .config file for coreboot in my previous
> mail.
>
> We have adjusted the memory settings (romstage.c) in the leafhill
> directory for the Oxbow Hill CRB. With these settings the memory
> initialization should work for Juniper Hill and Oxbow Hill CRB. Both CRBs
> use the same memory modules – DDR3L. But for the Leaf Hill CRB you need
> different settings, because there are other DIMM modules on it – LPDDR4.
>
>
>
> Mario
>
>
>
>
>
> *Von:* coreboot [mailto:coreboot-boun...@coreboot.org] *Im Auftrag von *
> ahW@n via coreboot
> *Gesendet:* Freitag, 3. November 2017 08:38
> *An:* coreboot@coreboot.org
> *Betreff:* Re: [coreboot] Problems changing payload on Intel Leaf Hill
>
>
>
> Hi Mario,
>
>
>
> I read your reply and saw you have APL CRB Oxbow Hill with coreboot +
> SeaBios running.
>
> I am using the same board and wanted to build the coreboot but failed.
>
> I think I have the required files ready (bootable UEFI BIOS file,
> fitimage.bin, Fsp.fd ...)
>
> But still failed to build my coreboot.
>
> I wonder I am having correct .config settings.
>
> Can you share your settings?
>
> I check the attachment in previous list but all that is for leafhill, I
> wonder are they same and valid for both Oxbox Hill and Leafhill?
>
> Please advise, thank you.
>
>
>
> - ahwan
>
>
>
>
>
> > Scheithauer, Mario Mario.Scheithauer at siemens.com
>
> > Wed Nov 1 16:28:45 CET 2017
>
> > Previous message (by thread): [coreboot] Coreboot support on H8SGL-F
>
> > Next message (by thread): [coreboot] Problems changing payload on Intel
> Leaf Hill
>
> > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>
> > Hi Tahnia,
>
> >
>
> > We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) +
> SeaBios (master) running.
>
> > Attached are all necessary coreboot adaptions and the config file for
> SeaBios.
>
> > After the generation, a hack in coreboot.rom is still necessary so that
> SeaBios can find the VBIOS.
>
> > SeaBios expects at the end of the CBFS the address from the beginning of
> the CBFS section (see SeaBiosPointer.jpg).
>
> > Furthermore you have to pay attention to the IGD PCI ID. Intel uses
> different PCI Device IDs in different CPU versions for IGD (5a84 or 5a85).
>
> > The console output only works via MMIO on the CRB. Therefore you need
> the LPSS UART0 Micro USB port.
>
> > With all these adjustments we can boot a system on the CRB and have full
> console output.
>
> > Now you just need all the necessary blobs around coreboot (IFWI, FSP,
> VBIOS, uCode).
>
> > You can use the Intel FIT tool to separate the most of the components
> from the original BIOS.
>
> >
>
> > Hope that helps,
>
> > Mario
>


coreboot.2.log
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[ahW@n via coreboot]

ally lost :(
please let me know if you have any idea on how I can debug further.
Thank you.

-ahwan


On Fri, Nov 3, 2017 at 6:18 PM, Scheithauer, Mario <
mario.scheitha...@siemens.com> wrote:

> Hi Ahwan,
>
>
>
> Oh sorry, I forgot to attach the .config file for coreboot in my previous
> mail.
>
> We have adjusted the memory settings (romstage.c) in the leafhill
> directory for the Oxbow Hill CRB. With these settings the memory
> initialization should work for Juniper Hill and Oxbow Hill CRB. Both CRBs
> use the same memory modules – DDR3L. But for the Leaf Hill CRB you need
> different settings, because there are other DIMM modules on it – LPDDR4.
>
>
>
> Mario
>
>
>
>
>
> *Von:* coreboot [mailto:coreboot-boun...@coreboot.org] *Im Auftrag von *
> ahW@n via coreboot
> *Gesendet:* Freitag, 3. November 2017 08:38
> *An:* coreboot@coreboot.org
> *Betreff:* Re: [coreboot] Problems changing payload on Intel Leaf Hill
>
>
>
> Hi Mario,
>
>
>
> I read your reply and saw you have APL CRB Oxbow Hill with coreboot +
> SeaBios running.
>
> I am using the same board and wanted to build the coreboot but failed.
>
> I think I have the required files ready (bootable UEFI BIOS file,
> fitimage.bin, Fsp.fd ...)
>
> But still failed to build my coreboot.
>
> I wonder I am having correct .config settings.
>
> Can you share your settings?
>
> I check the attachment in previous list but all that is for leafhill, I
> wonder are they same and valid for both Oxbox Hill and Leafhill?
>
> Please advise, thank you.
>
>
>
> - ahwan
>
>
>
>
>
> > Scheithauer, Mario Mario.Scheithauer at siemens.com
>
> > Wed Nov 1 16:28:45 CET 2017
>
> > Previous message (by thread): [coreboot] Coreboot support on H8SGL-F
>
> > Next message (by thread): [coreboot] Problems changing payload on Intel
> Leaf Hill
>
> > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>
> > Hi Tahnia,
>
> >
>
> > We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) +
> SeaBios (master) running.
>
> > Attached are all necessary coreboot adaptions and the config file for
> SeaBios.
>
> > After the generation, a hack in coreboot.rom is still necessary so that
> SeaBios can find the VBIOS.
>
> > SeaBios expects at the end of the CBFS the address from the beginning of
> the CBFS section (see SeaBiosPointer.jpg).
>
> > Furthermore you have to pay attention to the IGD PCI ID. Intel uses
> different PCI Device IDs in different CPU versions for IGD (5a84 or 5a85).
>
> > The console output only works via MMIO on the CRB. Therefore you need
> the LPSS UART0 Micro USB port.
>
> > With all these adjustments we can boot a system on the CRB and have full
> console output.
>
> > Now you just need all the necessary blobs around coreboot (IFWI, FSP,
> VBIOS, uCode).
>
> > You can use the Intel FIT tool to separate the most of the components
> from the original BIOS.
>
> >
>
> > Hope that helps,
>
> > Mario
>


.config
Description: XML document
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Cameron Craig]

Hi Tahnia,

>*  I have all the blobs around coreboot, except the VBIOS... I have tried
>all the options in https://www.coreboot.org/VGA_support
> , but I suspect the reference
>bootloader images provided by Intel does not use a VBIOS file. I also cannot
>find a suitable VBIOS on Intel's website. (By the way, thanks for the FIT
>decomposition tip, I did not know this was possible... I took great pains to 
>find
>the correct blobs on Intel's website, would have been much easier to just use
>FIT!) Where did you obtain a VBIOS file?

I did manage to get something that *could* be the right vbios blob by using the 
instructions in the link you just provided.
I used UEFITool to open the UEFI BIOS that came with the Leafhill CRB and 
searched for "VGA Compatible BIOS".
I could then extract the blob to a file.

As far as I can tell the file that Mario used (vbt.dat) is from the Coreboot 
package available from Intel.
Mario will be able to correct me if I'm wrong.

The exact location to download this package escapes me :)
Now that I think of it, if anyone does know the Intel website to download the 
coreboot package (Apollo_Lake_CB_MR3),
a reminder of the link would be greatly appreciated.


Cheers,
Cameron


Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:  | mobile: 
e: cameron.cr...@exterity.com | w: www.exterity.com



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Tahnia Lichtenstein]

Hi Mario,

Thank you very much for sharing, that already helps a lot!! I can spot
quite a lot of differences to my own build settings.

I've been pursuing a Grub2 payload in the meantime (no success so far),
will now return to SeaBIOS and try and incorporate the necessary changes
you suggested.

Just a couple of questions so far:

   - Are you able to boot Yocto with the current combination you have?
   - I have all the blobs around coreboot, except the VBIOS... I have tried
   all the options in https://www.coreboot.org/VGA_support, but I suspect
   the reference bootloader images provided by Intel does not use a VBIOS
   file. I also cannot find a suitable VBIOS on Intel's website. (By the way,
   thanks for the FIT decomposition tip, I did not know this was possible... I
   took great pains to find the correct blobs on Intel's website, would have
   been much easier to just use FIT!) Where did you obtain a VBIOS file?
   - Is it specifically VBIOS, or is it a VBT.dat file? Or are you running
   SeaVGABIOS?

Many thanks again!

Best regards,
Tahnia

On Fri, Nov 3, 2017 at 2:01 PM, Scheithauer, Mario <
mario.scheitha...@siemens.com> wrote:

>
> Hi Cameron,
>
> > Did you modify the FSP blobs at all?
> Yes, we made some adjustments for our mainboard (mc_apl1).
> But they shouldn’t play a decisive role (power states, PCIe settings).
>
> > The reason I ask is that my coreboot build hangs in the FspSiliconInit().
> Then you will get pretty far.
> We are currently still using the MR2 FSP package for APL-I.
> As IFWI template we use the BIOS version v178.10 for the CRBs.
> These components are provided by Intel.
> That’s it. The CRB should boot with this combination.
>
> Mario
>
> > -Ursprüngliche Nachricht-
> > Von: Cameron Craig [mailto:cameron.cr...@exterity.com]
> > Gesendet: Freitag, 3. November 2017 11:51
> > An: Scheithauer, Mario (DF MC MTS R&D SWRT 4); ahW@n
> > Cc: coreboot@coreboot.org
> > Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill
> >
> > Hi Mario,
> >
> > I've been attempting to build coreboot(master) for the Leaf Hill CRB,
> with no
> > success so far.
> >
> > Did you modify the FSP blobs at all?
> > I had a look at your config, the filenames "FSP_MR2_M_ECC_MOD" caught my
> > eye.
> >
> > The reason I ask is that my coreboot build hangs in the FspSiliconInit().
> >
> > Cheers,
> > Cameron
> >
> >
> >
> > Cameron Craig | Graduate Software Engineer | Exterity Limited
> > tel: +44 1383 828 250 | fax:  | mobile:
> > e: cameron.cr...@exterity.com | w: www.exterity.com
> >
> >
> >
> > 
> > __
> > This email has been scanned by the Symantec Email Security.cloud service.
> > For more information please visit http://www.symanteccloud.com
> > 
> > __
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Scheithauer, Mario]

Hi Cameron,

> Did you modify the FSP blobs at all?
Yes, we made some adjustments for our mainboard (mc_apl1).
But they shouldn’t play a decisive role (power states, PCIe settings).

> The reason I ask is that my coreboot build hangs in the FspSiliconInit().
Then you will get pretty far.
We are currently still using the MR2 FSP package for APL-I.
As IFWI template we use the BIOS version v178.10 for the CRBs.
These components are provided by Intel.
That’s it. The CRB should boot with this combination.

Mario

> -Ursprüngliche Nachricht-
> Von: Cameron Craig [mailto:cameron.cr...@exterity.com]
> Gesendet: Freitag, 3. November 2017 11:51
> An: Scheithauer, Mario (DF MC MTS R&D SWRT 4); ahW@n
> Cc: coreboot@coreboot.org
> Betreff: RE: [coreboot] Problems changing payload on Intel Leaf Hill
> 
> Hi Mario,
> 
> I've been attempting to build coreboot(master) for the Leaf Hill CRB, with no
> success so far.
> 
> Did you modify the FSP blobs at all?
> I had a look at your config, the filenames "FSP_MR2_M_ECC_MOD" caught my
> eye.
> 
> The reason I ask is that my coreboot build hangs in the FspSiliconInit().
> 
> Cheers,
> Cameron
> 
> 
> 
> Cameron Craig | Graduate Software Engineer | Exterity Limited
> tel: +44 1383 828 250 | fax:  | mobile:
> e: cameron.cr...@exterity.com | w: www.exterity.com
> 
> 
> 
> 
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> 
> __
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Cameron Craig]

Hi Mario,

I've been attempting to build coreboot(master) for the Leaf Hill CRB, with no 
success so far.

Did you modify the FSP blobs at all?
I had a look at your config, the filenames "FSP_MR2_M_ECC_MOD" caught my eye.

The reason I ask is that my coreboot build hangs in the FspSiliconInit().

Cheers,
Cameron



Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:  | mobile: 
e: cameron.cr...@exterity.com | w: www.exterity.com



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Scheithauer, Mario]

Hi Ahwan,

Oh sorry, I forgot to attach the .config file for coreboot in my previous mail.
We have adjusted the memory settings (romstage.c) in the leafhill directory for 
the Oxbow Hill CRB. With these settings the memory initialization should work 
for Juniper Hill and Oxbow Hill CRB. Both CRBs use the same memory modules – 
DDR3L. But for the Leaf Hill CRB you need different settings, because there are 
other DIMM modules on it – LPDDR4.

Mario


Von: coreboot [mailto:coreboot-boun...@coreboot.org] Im Auftrag von ahW@n via 
coreboot
Gesendet: Freitag, 3. November 2017 08:38
An: coreboot@coreboot.org
Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill

Hi Mario,

I read your reply and saw you have APL CRB Oxbow Hill with coreboot + SeaBios 
running.
I am using the same board and wanted to build the coreboot but failed.
I think I have the required files ready (bootable UEFI BIOS file, fitimage.bin, 
Fsp.fd ...)
But still failed to build my coreboot.
I wonder I am having correct .config settings.
Can you share your settings?
I check the attachment in previous list but all that is for leafhill, I wonder 
are they same and valid for both Oxbox Hill and Leafhill?
Please advise, thank you.

- ahwan


> Scheithauer, Mario Mario.Scheithauer at siemens.com<http://siemens.com>
> Wed Nov 1 16:28:45 CET 2017
> Previous message (by thread): [coreboot] Coreboot support on H8SGL-F
> Next message (by thread): [coreboot] Problems changing payload on Intel Leaf 
> Hill
> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> Hi Tahnia,
>
> We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) + SeaBios 
> (master) running.
> Attached are all necessary coreboot adaptions and the config file for SeaBios.
> After the generation, a hack in coreboot.rom is still necessary so that 
> SeaBios can find the VBIOS.
> SeaBios expects at the end of the CBFS the address from the beginning of the 
> CBFS section (see SeaBiosPointer.jpg).
> Furthermore you have to pay attention to the IGD PCI ID. Intel uses different 
> PCI Device IDs in different CPU versions for IGD (5a84 or 5a85).
> The console output only works via MMIO on the CRB. Therefore you need the 
> LPSS UART0 Micro USB port.
> With all these adjustments we can boot a system on the CRB and have full 
> console output.
> Now you just need all the necessary blobs around coreboot (IFWI, FSP, VBIOS, 
> uCode).
> You can use the Intel FIT tool to separate the most of the components from 
> the original BIOS.
>
> Hope that helps,
> Mario


ATT75539.config
Description: ATT75539.config
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Zoran Stojsavljevic]

>> ahwan writes
>> Please advise, thank you.

Mario (Werner),

You should offer to this guy job (Siemens Motion Control) in DE (Bayern).
He is tough guy, as I read/percept. I am (dead) serious.

Zoran Stojsavljevic

On Fri, Nov 3, 2017 at 8:37 AM, ahW@n via coreboot 
wrote:

> Hi Mario,
>
> I read your reply and saw you have APL CRB Oxbow Hill with coreboot +
> SeaBios running.
> I am using the same board and wanted to build the coreboot but failed.
> I think I have the required files ready (bootable UEFI BIOS file,
> fitimage.bin, Fsp.fd ...)
> But still failed to build my coreboot.
> I wonder I am having correct .config settings.
> Can you share your settings?
> I check the attachment in previous list but all that is for leafhill, I
> wonder are they same and valid for both Oxbox Hill and Leafhill?
> Please advise, thank you.
>
> - ahwan
>
>
> > Scheithauer, Mario Mario.Scheithauer at siemens.com
> > Wed Nov 1 16:28:45 CET 2017
> > Previous message (by thread): [coreboot] Coreboot support on H8SGL-F
> > Next message (by thread): [coreboot] Problems changing payload on Intel
> Leaf Hill
> > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> > Hi Tahnia,
> >
> > We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) +
> SeaBios (master) running.
> > Attached are all necessary coreboot adaptions and the config file for
> SeaBios.
> > After the generation, a hack in coreboot.rom is still necessary so that
> SeaBios can find the VBIOS.
> > SeaBios expects at the end of the CBFS the address from the beginning of
> the CBFS section (see SeaBiosPointer.jpg).
> > Furthermore you have to pay attention to the IGD PCI ID. Intel uses
> different PCI Device IDs in different CPU versions for IGD (5a84 or 5a85).
> > The console output only works via MMIO on the CRB. Therefore you need
> the LPSS UART0 Micro USB port.
> > With all these adjustments we can boot a system on the CRB and have full
> console output.
> > Now you just need all the necessary blobs around coreboot (IFWI, FSP,
> VBIOS, uCode).
> > You can use the Intel FIT tool to separate the most of the components
> from the original BIOS.
> >
> > Hope that helps,
> > Mario
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[ahW@n via coreboot]

Hi Mario,

I read your reply and saw you have APL CRB Oxbow Hill with coreboot +
SeaBios running.
I am using the same board and wanted to build the coreboot but failed.
I think I have the required files ready (bootable UEFI BIOS file,
fitimage.bin, Fsp.fd ...)
But still failed to build my coreboot.
I wonder I am having correct .config settings.
Can you share your settings?
I check the attachment in previous list but all that is for leafhill, I
wonder are they same and valid for both Oxbox Hill and Leafhill?
Please advise, thank you.

- ahwan


> Scheithauer, Mario Mario.Scheithauer at siemens.com
> Wed Nov 1 16:28:45 CET 2017
> Previous message (by thread): [coreboot] Coreboot support on H8SGL-F
> Next message (by thread): [coreboot] Problems changing payload on Intel
Leaf Hill
> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> Hi Tahnia,
>
> We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) +
SeaBios (master) running.
> Attached are all necessary coreboot adaptions and the config file for
SeaBios.
> After the generation, a hack in coreboot.rom is still necessary so that
SeaBios can find the VBIOS.
> SeaBios expects at the end of the CBFS the address from the beginning of
the CBFS section (see SeaBiosPointer.jpg).
> Furthermore you have to pay attention to the IGD PCI ID. Intel uses
different PCI Device IDs in different CPU versions for IGD (5a84 or 5a85).
> The console output only works via MMIO on the CRB. Therefore you need the
LPSS UART0 Micro USB port.
> With all these adjustments we can boot a system on the CRB and have full
console output.
> Now you just need all the necessary blobs around coreboot (IFWI, FSP,
VBIOS, uCode).
> You can use the Intel FIT tool to separate the most of the components
from the original BIOS.
>
> Hope that helps,
> Mario
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Scheithauer, Mario]

Hi Kevin,

Yes, we had to make another adjustment.
I think SeaBios is expecting a pointer at this position to the beginning of the 
CBFS.
But coreboot doesn't enter anything there, because everything works over the 
FMAP.
But it may also be that we are still doing something wrong.

-> CONFIG_CBFS_LOCATION = top of memory (0x) - SPI Flash size + CBFS 
end position (FMAP) + DEVICE_EXTENSION size (FMAP) + UNUSED_HOLE size (FMAP)
-> At this position there is only 0x and SeaBios has a problem with 
that.
-> 0xff401838 = top of memory (0x) - SPI Flash size + DEVICE_EXTENSION 
size (FMAP) + UNUSED_HOLE size (FMAP) + CBFS master header size (0x38)
-> It all depends on the FMAP
-> If we put into the pointer there, SeaBios will also find the CBFS and 
everything is fine

Regards,
Mario

> -Ursprüngliche Nachricht-
> Von: Kevin O'Connor [mailto:ke...@koconnor.net]
> Gesendet: Donnerstag, 2. November 2017 00:45
> An: Scheithauer, Mario (DF MC MTS R&D SWRT 4)
> Cc: Tahnia Lichtenstein; coreboot@coreboot.org
> Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill
> 
> On Wed, Nov 01, 2017 at 03:28:45PM +, Scheithauer, Mario wrote:
> > Hi Tahnia,
> >
> > We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) +
> SeaBios (master) running.
> > Attached are all necessary coreboot adaptions and the config file for 
> > SeaBios.
> > After the generation, a hack in coreboot.rom is still necessary so that 
> > SeaBios can
> find the VBIOS.
> > SeaBios expects at the end of the CBFS the address from the beginning of the
> CBFS section (see SeaBiosPointer.jpg).
> 
> When you say "a hack in coreboot.rom", are you referring to the
> CONFIG_CBFS_LOCATION=0xfff9f000 seabios setting or was some additional
> change necessary?
> 
> -Kevin

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Kevin O'Connor]

On Wed, Nov 01, 2017 at 03:28:45PM +, Scheithauer, Mario wrote:
> Hi Tahnia,
> 
> We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) + SeaBios 
> (master) running.
> Attached are all necessary coreboot adaptions and the config file for SeaBios.
> After the generation, a hack in coreboot.rom is still necessary so that 
> SeaBios can find the VBIOS.
> SeaBios expects at the end of the CBFS the address from the beginning of the 
> CBFS section (see SeaBiosPointer.jpg).

When you say "a hack in coreboot.rom", are you referring to the
CONFIG_CBFS_LOCATION=0xfff9f000 seabios setting or was some additional
change necessary?

-Kevin

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Cameron Craig]

Hi Tahnia et al,

Have you had any luck with Tianocore or SeaBIOS on Leaf Hill?

I would be interested to know if you (or anyone!) have managed to get any of 
these working on Leaf Hill.
We are now also considering these, as U-Boot on Leaf Hill looks like a fair bit 
of work.

Cheers,
Cameron

>

Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:  | mobile:
e: cameron.cr...@exterity.com | w: www.exterity.com


-Original Message-
>From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Nico
>Huber
>Sent: 10 October 2017 15:12
>To: Tahnia Lichtenstein; coreboot@coreboot.org
>Subject: Re: [coreboot] Problems changing payload on Intel Leaf Hill
>
>Hi Tahnia,
>
>On 10.10.2017 10:29, Tahnia Lichtenstein wrote:
>> ...
>>
>> Then I built this version of coreboot with a self-compiled payload,
>> such as Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the
>> .confg files provided by Intel for UEFI payloads or legacy payloads
>> respectively (just modified for specific payload type and path, and
>> disabling verified and measured boot). I stitched the coreboot output
>> with the Intel-provided blobs using the exact same method as before.
>> Then, in run-time, coreboot transitions to the payload and nothing
>> happens from then on (i.e. no further serial debug messages, no change to
>display monitor).
>
>you've only attached config files for your coreboot but not for the payloads.
>It's hard to tell what output to expect without that (e.g.
>do you have serial output enabled in your SeaBIOS build? if you let the
>coreboot build environment configure SeaBIOS it is enabled expli- citly). So
>with the current information you've provided, it could just be that the
>payloads don't try to output anything on serial.
>
>Output on a monitor is a little more complicated and depends on each
>payload. SeaBIOS expects a Video BIOS to be present. This can either be an
>option ROM from a gfx adapter card (looking at your logs, you don't seem to
>have one), a Video BIOS file in CBFS matching the inte- grated gfx adapter, or,
>in case coreboot already configured a frame- buffer, a Video BIOS shim called
>SeaVGABIOS (aka. cbvga in this case, it's a separate component in the SeaBIOS
>source).
>
>Current CorebootPayloadPkg *should* be able to use a preconfigured
>framebuffer. I never tried it, though, and there are reports that it doesn't
>always work... It's generally possible that Intel's precom- piled UEFI payload
>has it's own gfx driver (GOP) built in.
>
>> ...
>> Am I not specifying the correct configuration options for Tianocore
>> and SeaBIOS? I.e. is there more to it than just selecting the payload
>> type and specifying the payload path? Do I need to configure or update
>> memory addresses or ranges to match payload sizes, or some such? Do I
>> need to make specific changes to the payloads' source code to support
>> the platform? Any advice on how/where to start debugging?
>
>Usually there is nothing more to specify. The best option, IMO, is to get one 
>of
>the simpler payloads (SeaBIOS should do) to output on serial.
>You can also test your SeaBIOS binary in QEMU to make sure it does out- put
>something.
>
>Hope that helps,
>Nico
>
>--
>coreboot mailing list: coreboot@coreboot.org
>https://mail.coreboot.org/mailman/listinfo/coreboot
>
>___
>___
>This email has been scanned by the Symantec Email Security.cloud service.
>For more information please visit http://www.symanteccloud.com
>___
>___

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Tahnia Lichtenstein]

Thanks for all the replies so far! Many things to consider and try out, I
am busy investigating and will get back once I have more details!

Much appreciated!
Tahnia


On Wed, Oct 11, 2017 at 3:35 AM, Melissa Yi  wrote:

> Hi Tahnia,
>  Have you tried 32-bit UEFI payload? I met  this problem in Denverton
> platfrom too with 64-bitUEFI payload.
>
> Thanks.
>
> Regards,
> Melissa Yi
>
> BIOS Lead Engineer
> Celestica(Shanghai) R&D Center, China
>
> www.celestica.com
> Solid Partners, Flexible Solutions
>
> 2017-10-10 16:29 GMT+08:00 Tahnia Lichtenstein :
>
>> Hi,
>>
>> I am trying to build coreboot for the Intel Apollo Lake-I reference board
>> (Oxbow Hill, similar to Leaf Hill).
>>
>> Intel has provided an implementation for this reference board based on an
>> outdated coreboot version.
>>
>> Along with the coreboot implementation, they provided a compatible
>> pre-compiled UEFI payload (with no source, but run-time boot menu looks
>> like Tianocore's) and a compatible pre-compiled U-Boot payload (with links
>> to U-Boot source on Github along with patch so as to reproduce the
>> pre-compiled binary). The pre-compiled binaries have associated .config
>> files for coreboot integration. When building coreboot with either of the
>> precompiled binaries, and stitching the coreboot output binaries together
>> with Intel-provided blobs (using Intel provided FIT application) to produce
>> the final firmware image, the firmware works as expected.
>>
>> Then I built this version of coreboot with a self-compiled payload, such
>> as Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the .confg files
>> provided by Intel for UEFI payloads or legacy payloads respectively (just
>> modified for specific payload type and path, and disabling verified and
>> measured boot). I stitched the coreboot output with the Intel-provided
>> blobs using the exact same method as before. Then, in run-time, coreboot
>> transitions to the payload and nothing happens from then on (i.e. no
>> further serial debug messages, no change to display monitor).
>>
>> I also built U-Boot from github, applying Intel's patch to match Intel's
>> precompiled binary, and this self-compiled binary works in run-time (well,
>> sort of, there are a couple of problems but point is the payload runs). A
>> notable build difference is that this build uses the .config file provided
>> by Intel as is, and that the payload that was built is the binary
>> equivalent of the Intel pre-compiled binary.
>>
>> Am I not specifying the correct configuration options for Tianocore and
>> SeaBIOS? I.e. is there more to it than just selecting the payload type and
>> specifying the payload path? Do I need to configure or update memory
>> addresses or ranges to match payload sizes, or some such? Do I need to make
>> specific changes to the payloads' source code to support the platform? Any
>> advice on how/where to start debugging?
>>
>> (Serial debug logs and .config files attached.)
>>
>> Best regards,
>> Tahnia
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Melissa Yi]

Hi Tahnia,
 Have you tried 32-bit UEFI payload? I met  this problem in Denverton
platfrom too with 64-bitUEFI payload.

Thanks.

Regards,
Melissa Yi

BIOS Lead Engineer
Celestica(Shanghai) R&D Center, China

www.celestica.com
Solid Partners, Flexible Solutions

2017-10-10 16:29 GMT+08:00 Tahnia Lichtenstein :

> Hi,
>
> I am trying to build coreboot for the Intel Apollo Lake-I reference board
> (Oxbow Hill, similar to Leaf Hill).
>
> Intel has provided an implementation for this reference board based on an
> outdated coreboot version.
>
> Along with the coreboot implementation, they provided a compatible
> pre-compiled UEFI payload (with no source, but run-time boot menu looks
> like Tianocore's) and a compatible pre-compiled U-Boot payload (with links
> to U-Boot source on Github along with patch so as to reproduce the
> pre-compiled binary). The pre-compiled binaries have associated .config
> files for coreboot integration. When building coreboot with either of the
> precompiled binaries, and stitching the coreboot output binaries together
> with Intel-provided blobs (using Intel provided FIT application) to produce
> the final firmware image, the firmware works as expected.
>
> Then I built this version of coreboot with a self-compiled payload, such
> as Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the .confg files
> provided by Intel for UEFI payloads or legacy payloads respectively (just
> modified for specific payload type and path, and disabling verified and
> measured boot). I stitched the coreboot output with the Intel-provided
> blobs using the exact same method as before. Then, in run-time, coreboot
> transitions to the payload and nothing happens from then on (i.e. no
> further serial debug messages, no change to display monitor).
>
> I also built U-Boot from github, applying Intel's patch to match Intel's
> precompiled binary, and this self-compiled binary works in run-time (well,
> sort of, there are a couple of problems but point is the payload runs). A
> notable build difference is that this build uses the .config file provided
> by Intel as is, and that the payload that was built is the binary
> equivalent of the Intel pre-compiled binary.
>
> Am I not specifying the correct configuration options for Tianocore and
> SeaBIOS? I.e. is there more to it than just selecting the payload type and
> specifying the payload path? Do I need to configure or update memory
> addresses or ranges to match payload sizes, or some such? Do I need to make
> specific changes to the payloads' source code to support the platform? Any
> advice on how/where to start debugging?
>
> (Serial debug logs and .config files attached.)
>
> Best regards,
> Tahnia
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Nico Huber]

Hi Tahnia,

On 10.10.2017 10:29, Tahnia Lichtenstein wrote:
> ...
> 
> Then I built this version of coreboot with a self-compiled payload, such as
> Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the .confg files
> provided by Intel for UEFI payloads or legacy payloads respectively (just
> modified for specific payload type and path, and disabling verified and
> measured boot). I stitched the coreboot output with the Intel-provided
> blobs using the exact same method as before. Then, in run-time, coreboot
> transitions to the payload and nothing happens from then on (i.e. no
> further serial debug messages, no change to display monitor).

you've only attached config files for your coreboot but not for the
payloads. It's hard to tell what output to expect without that (e.g.
do you have serial output enabled in your SeaBIOS build? if you let
the coreboot build environment configure SeaBIOS it is enabled expli-
citly). So with the current information you've provided, it could
just be that the payloads don't try to output anything on serial.

Output on a monitor is a little more complicated and depends on each
payload. SeaBIOS expects a Video BIOS to be present. This can either
be an option ROM from a gfx adapter card (looking at your logs, you
don't seem to have one), a Video BIOS file in CBFS matching the inte-
grated gfx adapter, or, in case coreboot already configured a frame-
buffer, a Video BIOS shim called SeaVGABIOS (aka. cbvga in this case,
it's a separate component in the SeaBIOS source).

Current CorebootPayloadPkg *should* be able to use a preconfigured
framebuffer. I never tried it, though, and there are reports that it
doesn't always work... It's generally possible that Intel's precom-
piled UEFI payload has it's own gfx driver (GOP) built in.

> ...
> Am I not specifying the correct configuration options for Tianocore and
> SeaBIOS? I.e. is there more to it than just selecting the payload type and
> specifying the payload path? Do I need to configure or update memory
> addresses or ranges to match payload sizes, or some such? Do I need to make
> specific changes to the payloads' source code to support the platform? Any
> advice on how/where to start debugging?

Usually there is nothing more to specify. The best option, IMO, is to
get one of the simpler payloads (SeaBIOS should do) to output on serial.
You can also test your SeaBIOS binary in QEMU to make sure it does out-
put something.

Hope that helps,
Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot