Re: [coreboot] GPG public key for corboot release signatures

[Alexander Couzens]

Hi Laszlo,

you can find the keys on the public key servern.
I've attached the fingerprints, but gpg can also show you when trying to
verify it.

> Why are there two signatures in the GPG signature file (for release
> 4.6) and why do the signature dates differ from the release date
> (according to the website)?

More signatures are better ;). Choose your own trust anchor.
I've signed it after it was released.

Best,
lynxis

Alexander Couzens 
  Key fingerprint = 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604

Martin Roth (coreboot developer) 
  Key fingerprint = 574C E6F6 855C FDEB 7D36  8E9D 1979 6C2B 3E4F 7DF7

-- 
Alexander Couzens

mail: lyn...@fe80.eu
jabber: lyn...@fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604


pgpsA5wRMvsrd.pgp
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] FILO 0.6.0 payload bootloader - Bug Reports!

[Ivan Ivanov]

Maybe a problem is 1TB size of my hard drive? (because FILO doesn't
work even with a small /boot partition)
FILO uses libpayload storage drivers, and surprisingly - by default,
STORAGE_64BIT_LBA option is disabled at

./coreboot/payloads/libpayload/drivers/storage/Kconfig
...
config STORAGE_64BIT_LBA
bool "Use 64-bit integers to address sectors"
depends on STORAGE
default n
help
  If this is selected, sectors will be addressed by an 64-bit integer.
  Select this to support LBA-48 for ATA drives.

LBA-48 is must have for the hard drives above 137 GB, why is it still
disabled? Looks like nobody using FILO for a long time, thats why no
SATA messages and no LBA-48 by default

Thank you very much for your workaround about cross-compiling, now I
could compile FILO on x86_64 OS. But sadly there is a big new problem,
probably related to the updated gcc-6.3.0 (even with coreboot's
gcc-6.3.0) :

While booting, FILO "freezes" while relocating: ./filo/x86/segment.c ,
void relocate(void) . After enabling debug configs and inserting some
additional print messages, could clearly see that this assembly is a
problem:

__asm__ __volatile__("rep; movsb\n\t"/* copy everything */
 "lgdt %3\n\t"
 "ljmp %4, $1f\n1:\t"
 "movw %5, %%ds\n\t"
 "movw %5, %%es\n\t"
 "movw %5, %%fs\n\t"
 "movw %5, %%gs\n\t"
 "movw %5, %%ss\n":"="(d0), "="(d1),
 "="(d2)
 :"m"(gdtarg), "n"(RELOC_CS),
 "q"((unsigned short) RELOC_DS), "0"(&_start),
 "1"(new_base), "2"(prog_size));

Initially I thought that maybe my OS version of gcc-6.3.0 compiler
compiles this assembly incorrectly. But there is the same problem even
when I try using the coreboot's "pure" GCC and other "pure" coreboot's
tools

Then I thought - maybe a problem is optimization? FILO has -Os
optimization, I replaced it with -O0 to disable (also had to remove
"inline" for three functions at ./filo/fs/mini_inflate.c . -O0
increases size from previous ~110K to about 460K, but if you use LZMA
compression while adding to coreboot - it becomes just ~120K so not
problem to use

But this does not solve a problem - it still stucks at this assembly,
while half year ago - when I compiled it on x86 OS with older
compilers it didn't stuck while booting on the same hardware. Sadly I
dont have time to find out what is the last compiler version that
worked. If everyone uses GRUB and nobody is trying to use FILO except
me, I will live without FILO as well :P

Best regards,
Ivan Ivanov







Very interesting, why it is not enabled by default, because L

2017-06-14 1:13 GMT+03:00 Nico Huber :
> Hello Ivan,
>
> On 13.06.2017 23:51, Ivan Ivanov wrote:
>> Sadly "filo> kernel hda1:/vmlinuz" doesnt work as well: gives
>> Disk read error dev=1 drive=0 sector=0
>
> this sounds much like the drive wasn't detected at all, not 100% sure
> though. If you enabled the libpayload AHCI driver, it should show
> detected drives on the console (only a short moment if you enabled
> the GRUB interface). A serial log would help or if that's not pos-
> sible, you can disable the GRUB interface to see the output, IIRC.
>
>>
>> Error 15: File not found
>>
>> My current situation seems like a standard use case:
>> 1) ext2 boot partition at /dev/sda1 (or which is called "hda1" in this case),
>> size of which is 1GB and it is at DOS-partitioned MBR hard drive
>
> It could also be the size of the filesystem. IIRC, I've run into pro-
> blems with bigger partitions too, but ignored them because our OS uses
> small boot partitions. You could try the same partitioning and file
> system in QEMU.
>
>> 2) vmlinuz is at hda1:/vmlinuz , initrd is at hda1:/initrd
>>
>> But so far I am unable to even load a kernel.
>> Either I am doing something very wrong or there is a fundamental
>> problem with FILO which makes it useless outside of QEMU and maybe a
>> couple of IDE legacy systems which is really sad if indeed the
>> case :P
>>
>> By the way, when I run "probe" command it tells:
>> IDE channel 0 not found
>> IDE channel 0 not found
>> IDE channel 1 not found
>> IDE channel 1 not found
>> IDE channel 2 not found
>> IDE channel 2 not found
>> IDE channel 3 not found
>> IDE channel 3 not found
>>
>> No word about SATA, but maybe this is a correct behaviour? or not?
>
> It is expected behaviour. We've integrated the libpayload storage
> driver with little love, it just works for the file-system backend.
>
> Nico
>

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

[coreboot] GPG public key for corboot release signatures

[László Szücs via coreboot]

Hi all!

I have a potentially silly question: I would like to use the coreboot 4.6 
release from the coreboot.org website. To be sure i would like to verify the 
GPG signature. Where can I find the appropriate public key(s) for the 
verification?

Why are there two signatures in the GPG signature file (for release 4.6) and 
why do the signature dates differ from the release date (according to the 
website)?

Thanks and apologies if I overlooked/misinterpreted something,

László-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] EDID versus VBT, and their cooperation/relationship?!

[Zoran Stojsavljevic]

Hello Coreboot folks,

I am opening the another thread, trying better to understand GFX Coreboot
architecture, as well as Linux GFX one. And relationships between these two.

Here are some rules I'll assume they are correct (my best guess), after I
started investigating this area.

 - While BSP/Coreboot (EDID not read from the actual monitor yet), the
only entity which applies for attached monitor for timings is VBT.dat (if
applied in Coreboot, assuming it does).
 - VBT.dat is passed via vBIOS or GOP (dynamically) to Linux kernel
while it boots. How and in which phase it is done, I have very little
understanding. More I do understand if vBIOS (CSM ON) is passed to kernel
(as part of Option ROM), but not really clear to me where vbt.dat (where
exactly ?) will finish after Coreboot is done.
 - No matter what and how vbt.dat is passed and where, monitor's EDID
will be read using DDC/CI protocol, while initializing kernel GFX, to
obtain all the true/natural timing data for the present monitor (if
implemented/applicable).

And here are the questions, regarding what I wrote here:
[1] Where in the kernel structures VBT.dat will be kept/held (it'll be
added on fly after BSP is done, somewhere in the allocated heap - the APIs
describing it will be somewhere here: drivers/gpu/drm/i915/)?
[2] In other words, VBT.dat will be the part of DRM (i915 GFX driver), part
of kernel space, correct?
[3] What about EDID, if it is/was successfully read? It obviously has
precedence over VBT.dat, correct?
[4] Does DRI API (DRILib, DRI -> Direct Rendering Infrastructure) as part
of X11 server, provide the only access to VBT.dat?
[5] Does DRI API (DRILib) as part of X11 server, provide the only access to
EDID, previously read from attached monitor (via DDC/CI protocol)?
[6] Alternative to [4], does DRM API (part of kernel space, top layer,
above i915 driver) provide the only access to VBT.dat?
[7] Alternative to [5], does DRM API provide the only access to EDID?
[8] Please, if you like, add your own understanding of this architecture.
[9] Whatever you have to add, subtract, change... You name it!

I really would like to open this thread in order to clear lot of fog,
created by Linux maintainers, INTEL, and Linux GFX designers, as main
reason driving this email to get much better Linux/kernel GFX
picture/architecture understanding???

Thank you all in advance!
Zoran Stojsavljevic
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot