On Tue, Jun 13, 2017 at 10:33 AM Ivan Ivanov <qmaster...@gmail.com> wrote:
> === If you have some ideas about one or more of FILO problems, please tell > === > > %%% 1st problem - FILO is impossible to build on the modern x86_64 > system (Ubuntu 16.04.2 LTS with gcc 5.4.0) : > ... > CC build/x86/context.o > AS build/x86/switch.S.o > /bin/sh: 1: --32: not found > Makefile:177: error while executing receipt for target > «/home/owner/filo/build/x86/switch.S.o» > make: *** [/home/owner/filo/build/x86/switch.S.o] Error 127 > > No matter what crosscompiling stuff I am trying or what edits I do to > Makefile - it always fails with this error. However it compiles fine > at the 32-bit version of the same OS with the same versions of > packages except for a different architecture > > FILO is probably the only payload which has this problem - and this is > indeed a major problem, because all the major Linux distributions are > abandoning 32-bit soon. To fix this error, most likely the edits of > Makefile are needed, but sadly looks like my skills are not enough to > fix it (spent the whole day without a success) ... > Look at the xcompile script. It seems to not detect your assembler correctly. Your xcompile output should look like this: ~/git/filo/ > sh util/xcompile/xcompile # x86 TARCH_SEARCH= ..../git/filo/util/crossgcc/xgcc/bin/i386-elf- i386-elf- ..../git/filo/util/crossgcc/xgcc/bin/i386-eabi- i386-eabi- ..../git/filo/util/crossgcc/xgcc/bin/x86_64-elf- x86_64-elf- ..../git/filo/util/crossgcc/xgcc/bin/x86_64-eabi- x86_64-eabi- # elf32-i386 toolchain (i386-elf-gcc) CC_i386:=i386-elf-gcc -Wno-unused-but-set-variable -Wa,--divide -fno-stack-protector -Wl,--build-id=none -fuse-ld=bfd -march=i686 AS_i386:=i386-elf-as LD_i386:=i386-elf-ld.bfd NM_i386:=i386-elf-nm OBJCOPY_i386:=i386-elf-objcopy OBJDUMP_i386:=i386-elf-objdump READELF_i386:=i386-elf-readelf STRIP_i386:=i386-elf-strip AR_i386:=i386-elf-ar # arm TARCH_SEARCH= ..../git/filo/util/crossgcc/xgcc/bin/armv7a-elf- armv7a-elf- ..../git/filo/util/crossgcc/xgcc/bin/armv7a-eabi- armv7a-eabi- Warning: no suitable GCC for arm. IASL:=iasl # native toolchain HOSTCC:=gcc > %%% 2nd problem: There are only three "tested" SATA controllers in > FILO built-in "approved" list - and FILO does not even try to > initialize the not-listed controllers, despite that the attempt could > have been successful if tried! By default, FILO just outputs "ahci: > Not using untested SATA controller" message, without any option for a > user to try forcing its usage... The only currently available > workaround for this is to manually edit > *./coreboot/payloads/libpayload/drivers/storage/ahci.c * and remove > two " #if > IS_ENABLED(CONFIG_LP_STORAGE_AHCI_ONLY_TESTED) ... #endif " parts, > > Just disable CONFIG_LP_STORAGE_AHCI_ONLY_TESTED in your libpayload config. > %%% 3rd problem: while trying to access hard drive with commands like > filo> kernel hda:/vmlinuz I am getting the following errors: > > Disk read error dev=1 drive=0 sector=0 > Disk read error dev=1 drive=0 sector=2 > Disk read error dev=1 drive=0 sector=2 > Disk read error dev=1 drive=0 sector=128 > Disk read error dev=1 drive=0 sector=16 > Disk read error dev=1 drive=0 sector=64 > Disk read error dev=1 drive=0 sector=0 > Disk read error dev=1 drive=0 sector=64 > Disk read error dev=1 drive=0 sector=0 > Disk read error dev=1 drive=0 sector=0 > Unknown filesystem type. > > > Error 15: File not found. > > Is there any workaround for this? Or maybe I am using the wrong > commands? If so, please tell - what are the correct FILO real-hardware > commands for trying to boot a Linux kernel thats stored on FAT16 > partition at the beginning of DOS-partitioned MBR hard drive? Or this > is a problem with my hardware? > It seems you would have to look inside of a partition, not just on the raw disk. e.g. hda1:/... > > Best regards, > qmastery > Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot