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

2017-06-24 Thread 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

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

2017-06-13 Thread 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

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

2017-06-13 Thread Ivan Ivanov 
Sadly "filo> kernel hda1:/vmlinuz" doesnt work as well: gives
Disk read error dev=1 drive=0 sector=0

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
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?
Please tell me what extra info do you need, and I will try my best to
extract and provide it

Best regards,
Ivan Ivanov aka qmastery

2017-06-13 20:40 GMT+03:00 Stefan Reinauer :
>
>
> On Tue, Jun 13, 2017 at 10:33 AM Ivan Ivanov  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

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

2017-06-13 Thread Stefan Reinauer via coreboot 
On Tue, Jun 13, 2017 at 10:33 AM Ivan Ivanov  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

[coreboot] FILO 0.6.0 payload bootloader - Bug Reports!

2017-06-13 Thread Ivan Ivanov 
=== 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) ...

%%% 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,

%%% 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?

Best regards,
qmastery

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