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@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:
- 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.
- 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