[coreboot] Intel Leafhill/Apollolake wrong CBFS header address in coreboot.rom
adurbin at google.com
Mon Mar 20 22:49:42 CET 2017
On Sun, Mar 19, 2017 at 1:20 AM, Gailu Singh <gailu96 at gmail.com> wrote:
> Failing grub code
> static void
> init_cbfsdisk (void)
> grub_uint32_t ptr;
> struct cbfs_header *head;
> ptr = *(grub_uint32_t *) 0xfffffffc;
> head = (struct cbfs_header *) (grub_addr_t) ptr;
> grub_dprintf ("cbfs", "head=%p\n", head);
> /* coreboot current supports only ROMs <= 16 MiB. Bigger ROMs will
> have problems as RCBA is 18 MiB below end of 32-bit typically,
> so either memory map would have to be rearranged or we'd need to
> reading ROMs through controller directly.
> if (ptr < 0xff000000
> || 0xffffffff - ptr < (grub_uint32_t) sizeof (*head) + 0xf
> || !validate_head (head))
> On Sun, Mar 19, 2017 at 11:47 AM, Gailu Singh <gailu96 at gmail.com> wrote:
>> Hi Experts,
>> On Intel Leafhill board grub fails to find cbfsdisk. We tried to debug and
>> found that cbfs header address validation fails.
>> According to
>> "A pointer to the location of the header will be located at offset -4 from
>> the end of the ROM. This translates to address 0xFFFFFFFC on a normal x86
>> system. The pointer will be to physical memory somewhere between -
>> 0xFFFFB000 and 0xFFFFFFF0".
>> We checked the coreboot.rom in hex editor and address in last 4 bytes is
>> all ones (FFFFFFFF) as a result grub is not able to find cbfs header.
>> We have earlier used coreboot on baytrail and in the coreboot.rom cbfs
>> header address in last 4 byte was a valid pointer.
This isn't going to fix your real problem but the value at 4 bytes
below 4GiB is actually an offset from that location:
>> What is the location grub can find cbfs header on this board?
The following 2 files detail the mapping of the spi part. The
'COREBOOT' region is where cbfs resides and where you'd find that
relative offset. However, you'd have to know where the FMAP is in
order to parse things.
The 'BIOS' region listed in the spi descriptor is what is memory
mapped into the cpu address space under 4GiB. That does not mean when
reading a SPI image like a file that the region has to be at the end
of the file. There are linear translations you can do to go back and
forth between CPU mmio addresses and SPI addresses. Again, this
doesn't fix the current assumption in the code where it think it can
just dereference an int32_t pointer with a value of 0xfffffffc.
I don't know what the leaf hill descriptor indicates for the various
regions, but if you moved COREBOOT to the very top of the fmd file
(sans DEVICE_EXTENSION and UNUSED_HOLE) then you would be closer to
the current assumptions.
> coreboot mailing list: coreboot at coreboot.org
More information about the coreboot