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?
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
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
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
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. ;-)
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.
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
