Re: [coreboot] soc/amd/stoneyridge

[ron minnich]

After last week's meeting I did have one thought: keeping a 'best of breed'
example board for each generation of DRAM might be useful. E.g. one good
board for SDRAM, DDR2, DDR3. Just pick a really good one and mark it as an
example.

I realize it's all in git but out of sight is out of mind. My old favorite
would the first sis630 board or the intel/l440gx simply because they were
the very first ones and because of sdram.

To this day I think the work Stefan did on the getac and i945 is a great
read for memory training.

ron

On Tue, Jun 13, 2017 at 4:02 PM taii...@gmx.com  wrote:

> I don't think that trying to support every 10+ year old board is worth
> it, but at least a few from each genre (desktop, server/workstation and
> embedded) should be required to be ported for a style change to occur
> rather than everything simply abandoned as there wasn't anyone willing
> to update it.
>
> AFAIK as of now every non-development AMD board will be dropped in a few
> release cycles, I am not a firmware developer but I can't understand as
> to how a code style change makes that worth it especially considering
> many of those are the last and latest owner controlled x86 devices.
>
> In terms of vendor support (for the very few that do that); the majority
> of coreboot boards are in the expensive server or the embedded category
> so I don't think that it is unreasonable to expect the hypothetical
> vendor that releases code and advertises coreboot support to directly
> support for both initial release equivalent functionality and security
> it for 2x the hw warranty (as that is generally a useful life for most
> hardware)
>
> The "standard" 3 and now even 1 year update lifecycle that comes with
> hardware is creating a massive internet security issue.
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] soc/amd/stoneyridge

[taii...@gmx.com]

I don't think that trying to support every 10+ year old board is worth 
it, but at least a few from each genre (desktop, server/workstation and 
embedded) should be required to be ported for a style change to occur 
rather than everything simply abandoned as there wasn't anyone willing 
to update it.


AFAIK as of now every non-development AMD board will be dropped in a few 
release cycles, I am not a firmware developer but I can't understand as 
to how a code style change makes that worth it especially considering 
many of those are the last and latest owner controlled x86 devices.


In terms of vendor support (for the very few that do that); the majority 
of coreboot boards are in the expensive server or the embedded category 
so I don't think that it is unreasonable to expect the hypothetical 
vendor that releases code and advertises coreboot support to directly 
support for both initial release equivalent functionality and security 
it for 2x the hw warranty (as that is generally a useful life for most 
hardware)


The "standard" 3 and now even 1 year update lifecycle that comes with 
hardware is creating a massive internet security issue.



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

Re: [coreboot] AMD EPYC and PSP

[taii...@gmx.com]

On 06/08/2017 10:48 AM, Johnysecured88 via coreboot wrote:


Does anyone anticipate the new EPYC cpus not having PSP?

Sent with [ProtonMail](https://protonmail.com) Secure Email.

I see no reason why they wouldn't.

It doesn't really matter, for the price they'll be sold for you might as 
well buy POWER as you'd be getting better performance (8 threads/core) 
and an actual owner controlled device.


I can't understand as to why everyone complains that power is expensive 
when they're comparing it to low end x86 processors, in terms of raw 
compute power you'd spend just as much with an off the shelf equivalent 
dell/hpe - the high end xeon CPU's alone are 2K+ if you DIY.


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

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

[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] How to give control to bootable USB

[taii...@gmx.com]

On 06/13/2017 10:22 AM, Dhanasekar Jaganathan wrote:


Hi All,

I am trying to install ONIE from USB which has ONIE installer. Actually, I
am using GRUB2 as a payload.  If Coreboot display list of bootable device,I
can select USB which will install a OS in the hard disk.  As I understood
that Coreboot won't display list of available bootable device (not like
vendor bios).I don't know how to give control to bootable USB or boot a
bootable USB by coreboot. Can you please help me on this?.


Thanks,
Dhanasekar

Assuming you are booting a standard linux distro iso:
syslinux_configfile (*TAB* to see what is available

then simply for instance syslinux_configfile 
(usb0,msdos1)/isolinux/syslinux.cfg (or w/e)


also configfile (ahci0,msdos1)/grub2/grub.cfg to load a grub cfg

Ideally you would add a grub cfg to the coreboot image that does 
something like load a config file from a specified local disk so that it 
is easy to update (ie: no re-flashing) instructions for that are on the 
wiki.


SeaBIOS would provide the classic AMI style F12 selection menu, but I 
don't like it due to how many times I have accidentally enabled option 
rom execution by forgetting to include the configuration file.


--
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]

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!

[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!

[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

[coreboot] How to give control to bootable USB

[Dhanasekar Jaganathan]

Hi All,

I am trying to install ONIE from USB which has ONIE installer. Actually, I
am using GRUB2 as a payload.  If Coreboot display list of bootable device,I
can select USB which will install a OS in the hard disk.  As I understood
that Coreboot won't display list of available bootable device (not like
vendor bios).I don't know how to give control to bootable USB or boot a
bootable USB by coreboot. Can you please help me on this?.


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