[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":"=&S"(d0), "=&D"(d1),
                 "=&c"(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 <nico.h at gmx.de>:
> 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
>