May 2015 - coreboot - mail.coreboot.org

cmos.layout: power_on_after_fail
by Iru Cai May 2, 2015

May 2, 2015

Hi, After I set CONFIG_USE_OPTION_TABLE, my laptop will power on when I plug in the AC adapter. Then I find disabling `power_on_after_fail' will prevent my laptop from booting when AC is plugged in. So I wonder why this setting is called `power_on_after_fail' instead of `power on AC attach' as with the vendor BIOS?

1 0

Re: [coreboot] Kconfig: Move `CBFS_SIZE` out of main section
by Peter Stuge May 2, 2015

May 2, 2015

Julius Werner wrote: > > What section should > > > > (0x400000) Size of CBFS filesystem in ROM > > > > be moved to? > > The option is closely related to ROM_SIZE, so maybe put it under > 'Mainboard -->' with that? Sounds good. > > Furthermore, should it even be visible or be hidden as an expert option? > > Hiding it as an expert option probably makes sense. It is used to > restrict the amount of space coreboot (CBFS) takes up on the ROM in > case you want to put other stuff on there as well, which is probably a > pretty limited use case. I think making it depend on EXPERT is a great idea. I'd also like the interface to be friendlier. What granularity is actually supported for the option? I doubt that it's single bytes? Maybe make it decimal kb? The default value depends on ROM_SIZE, right? //Peter

3 2

Re: [coreboot] Kconfig: Move `CBFS_SIZE` out of main section
by Peter Stuge May 2, 2015

May 2, 2015

Julius Werner wrote: > > I'd also like the interface to be friendlier. What granularity is > > actually supported for the option? I doubt that it's single bytes? > > > > Maybe make it decimal kb? The default value depends on ROM_SIZE, right? > > I would very much prefer it to stay byte sized. This makes the > Makefiles that use it easier to write It's trivial to add another variable between the user interface and Makefile rules to turn the friendly value into what's convenient for the code. > and avoids confusion compared to the byte sized CONFIG_ROM_SIZE. The big difference is that users never see the actual ROM_SIZE value. They see a friendly list of common flash chip sizes, with the default being what ships with the particular board. > The actually supported granularity is anything that CBFS/cbfstool > supports as an image size, which I think is in theory arbitrary down > to individual bytes. What are the common CBFS_SIZE values? //Peter

2 1

Kconfig: Move `CBFS_SIZE` out of main section
by Paul Menzel May 1, 2015

May 1, 2015

Dear coreboot folks, commit f780c40f (CBFS: Correct ROM_SIZE for ARM boards, use CBFS_SIZE for cbfstool) [1] adds a description to the Kconfig variable `CBFS_SIZE`, which makes it, I think, visible in the Kconfig menu (`make menuconfig`). […] │ ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ General setup ---> │ │ │ │ Mainboard ---> │ │ │ │ Chipset ---> │ │ │ │ Devices ---> │ │ │ │ Display ---> │ │ │ │ Generic Drivers ---> │ │ │ │ Console ---> │ │ │ │ (0x400000) Size of CBFS filesystem in ROM │ │ │ │ System tables ---> │ │ │ │ Payload ---> │ │ │ │ Debugging ---> […] What section should (0x400000) Size of CBFS filesystem in ROM be moved to? Furthermore, should it even be visible or be hidden as an expert option? Thanks, Paul [1] http://review.coreboot.org/9619

2 1

Please be polite! (was: QEMU x86_64 Q35 Automated Test Failure)
by Paul Menzel May 1, 2015

May 1, 2015

Dear Gerd, dear Greg, sorry for the late reply. Am Dienstag, den 21.04.2015, 11:31 -0400 schrieb Gregg Levine: > On Tue, Apr 21, 2015 at 11:21 AM, Gerd Hoffmann <kraxel(a)redhat.com> wrote: > > On Di, 2015-04-21 at 02:24 -0500, Raptor Engineering Automated Test Stand wrote: > > > The QEMU x86_64 Q35 fails verification as of commit 7ab46f8085146db57699001462da871f2e4d9965 > > > > Log says at the end "RAPTOR ENGINEERING AUTOMATED TEST BOOT SUCCESS" > > > > Can you fix your test case and stop spamming the list please? > > > > > Please contact Timothy Pearson at Raptor Engineering > > > <tpearson(a)raptorengineeringinc.com> regarding any issues stemming > > > from this notification > > > > [x] done. > > Hello! > My thoughts exactly. Thank you sir. > > I suspect somehow it was supposed to be internal to hs outfit only. > And something changed with regards to the logic behind how those > annoying e-mail messages being sent to us. > > As for the test cases, they are extremely confusing to me. How many of > us also were? The confusion could be solved in the mean time, but I still want to reply. After reading both of your replies to the test stand message, I was very angry and disappointed about the bad assumptions you both made and the, in my opinion, impolite style by using words like *spamming* and *annoying*. For the future I wish that we first assume that the other side is meaning well. So I should assume, both of you meant well too. But I just wanted to get it out. In the end, in my opinion, the Raptor Engineering Automated Test Stand¹ is the best contribution to the coreboot infrastructure since the switching to a git based workflow. So big thanks to Raptor Engineering and Timothy! Thanks, Paul ¹ REATS is a strange acronym. Maybe a better name can be found. ;-)

1 0

Re: [coreboot] Regarding the timestamp in coreboot.
by Paul Menzel May 1, 2015

May 1, 2015

Dear Rajashaker welcome to coreboot! Am Donnerstag, den 23.04.2015, 11:03 +0800 schrieb rajashaker Goud: > I can see the CONFIG_COLLECT_TIMESTAMPS macro in the source of coreboot, > but am unable to get the clear picture of it. if you select this option, build a coreboot based image and boot to GNU/Linux, you can read the time stamps with `sudo cbmem -t`. $ cd util/cbmem $ make $ sudo ./cbmem -t > I want to collect all the timestamps of the drivers and to find out BOOT > TIME. What board do you use? Note, AMD AGESA boards currently do *not* support storing romstage time stamps, so they cannot be read out and are lost during the boot. Also remember that the payloads, at least GRUB 2, SeaBIOS and FILO, do not write store time stamps in CBMEM. There is also timing information, which coreboot only puts in its console log (`sudo ./cbmem -c`). Search for *BS:* and *usec* for example. Please report back, if that helped you. Thanks, Paul PS: The official spelling of the project name is *coreboot*, that means it’s one word.

1 0

build failure on amd64 host:- help
by sibu May 1, 2015

May 1, 2015

Greetings, I am new to this list. I am trying to learn how to compile coreboot. My host has these: ---cpu: AMD64 3 cores ---OS: linux (BLFS) linux-3.10.32, ( pure 64-bit ), gcc-4.8.1. IASL ( downloaded as tbb41_201305160ss ) A ) I fetched coreboot fron the git repository B ) I unpacked the downloaded in /usr/src C ) I ran 'make menuconfig' and selected 'build with any toolchain' D ) I then ran 'make' which ended as follows:- ###################### mv build/coreboot.pre1.tmp build/coreboot.pre1 LINK cbfs/fallback/romstage_null.debug ld.bfd -b elf32-i386 -melf_i386 --gc-sections -nostdlib -nostartfiles -static -o build/cbfs/fallback/romstage_null.debug -Lbuild --wrap __divdi3 --wrap __udivdi3 --wrap __moddi3 --wrap __umoddi3 --start-group build/generated/crt0.romstage.o build/mainboard/emulation/qemu- i440fx/static.romstage.o build/arch/x86/boot/boot.romstage.o build/arch/x86/boot/cbmem.romstage.o build/arch/x86/lib/cbfs_and_run.romstage.o build/arch/x86/lib/memcpy.romstage.o build/arch/x86/lib/memmove.romstage.o build/arch/x86/lib/memset.romstage.o build/arch/x86/lib/rom_media.romstage.o build/console/console.romstage.o build/console/die.romstage.o build/console/init.romstage.o build/console/post.romstage.o build/console/printk.romstage.o build/console/vtxprintf.romstage.o build/cpu/x86/car.romstage.o build/cpu/x86/lapic/boot_cpu.romstage.o build/device/device_romstage.romstage.o build/device/pci_early.romstage.o build/drivers/emulation/qemu/qemu_debugcon.romstage.o build/drivers/pc80/mc146818rtc.romstage.o build/drivers/pc80/mc146818rtc_early.romstage.o build/drivers/uart/uart8250io.romstage.o build/drivers/uart/util.romstage.o build/lib/bootmode.romstage.o build/lib/cbfs.romstage.o build/lib/cbfs_core.romstage.o build/lib/cbmem_common.romstage.o build/lib/cbmem_console.romstage.o build/lib/clog2.romstage.o build/lib/compute_ip_checksum.romstage.o build/lib/dynamic_cbmem.romstage.o build/lib/gcc.romstage.o build/lib/halt.romstage.o build/lib/hexdump.romstage.o build/lib/loaders/cbfs_ramstage_loader.romstage.o build/lib/loaders/load_and_run_ramstage.romstage.o build/lib/lzma.romstage.o build/lib/lzmadecode.romstage.o build/lib/memchr.romstage.o build/lib/memcmp.romstage.o build/lib/prog_ops.romstage.o build/lib/ramtest.romstage.o build/lib/version.romstage.o build/southbridge/intel/i82371eb/early_pm.romstage.o build/southbridge/intel/i82371eb/early_smbus.romstage.o /usr/lib/gcc/x86_64- unknown-linux-gnu/4.8.1/libgcc.a --end-group -T build/generated/romstage_null.ld build/lib/gcc.romstage.o: In function `__wrap___udivdi3': /usr/src/coreboot_GIT170415/src/lib/gcc.c:37: undefined reference to `__udivdi3' build/lib/gcc.romstage.o: In function `__wrap___umoddi3': /usr/src/coreboot_GIT170415/src/lib/gcc.c:39: undefined reference to `__umoddi3' make: *** [build/cbfs/fallback/romstage_null.debug] Error 1 rm build/cbfs/fallback/bootblock.elf ######### I am running on a pure 64-bit host but it seems coreboot is attempting to link 32-bit binaries. Help to successfuly build coreboot will be appreciated. Yours sincerely Sibu

3 2