Re: [coreboot] coreboot debugging with qemu-x86
On Sa, 2015-05-09 at 16:28 +0530, Saket Sinha wrote: HI Ajay, Try giving -m 1g Doesn't help. Same output. saket@saket-Notebook-PC:~/coreboot$ qemu-system-x86_64 -L . -bios build/coreboot.rom -nographic qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a EAX=0001 EBX= ECX= EDX=0663 ESI= EDI= EBP= ESP=fffa EIP=0009ffd6 EFL=0082 [--S] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS = 9b00 No, its not the same output. Quoting original post: EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 9b00 That is the reset vector, i.e. something going seriously wrong on the very first instruction executed. rom image being garbage or something like that. Check your build environment. Broken toolchain? Disk full? The new crash is at some completely different place, so coreboot at least starts executing. Try this ... qemu -bios coreboot.rom \ -chardev stdio,id=log \ -device isa-debugcon,iobase=0x402,chardev=log ... to see the coreboot log (assuming coreboot comes far enough to actually produce log output). cheers, Gerd -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] ASUS KFSN4-DRE Automated Test Failure
The ASUS KFSN4-DRE fails verification as of commit d2ab4e420ddfb0b14325b63b5443a0d6250076d8 The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: d2ab4e4 vboot: allow options to be selected from .config d1cf44c vboot: fix vboot_reference compilation e385b37 chromeos: add missing vboot functions bc40933 arm64: update verstage linking 52a530d arm: update verstage linking 70 commits skipped 2436bda cpu: get rid of socket source code 99cc1aa Mediawiki editing warning e9b7e25 util/xcompile/xcompile: Allow to override `HOSTCC` variable 939dc84 crossgcc: Re-download the archive if it is incomplete 6548ae9 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS` See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering tpear...@raptorengineeringinc.com regarding any issues stemming from this notification 1431368357-0-automaster.log.bz2 Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Questions on building a Coreboot ROM for the Dell Chromebook 11
To my knowledge, upstreaming boards during the Haswell days wasn't a priority, and was often done by non-Google devs (like me) who happened to have a particular device. Within the last ~6 mos this has changed significantly, and there's been a large push to keep the two in sync. I don't know if we have an official policy regarding upstreaming on this, but in our own master at https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/master we often intentionally only add a few boards for every generation (keeping the others in the respective release firmware branches like https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-wolf-4389.24.B ). The reason for that is simply to reduce clutter, since we often have a lot of different boards using the same chipset and very similar board layouts, which essentially just gives us dozens of directories with 99% copied code (e.g. see all the veyron_* boards in https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-veyron-6588.B for some of the worst offenders, which are 100% identical except for different board ID numbers). We've been talking in the past about ways to more effectively share code between boards but didn't really have time to tackle it yet. Until then, I don't expect we'll upstream any more boards than we're keeping in our own master (which is sometimes a quite arbitrary distinction based on how early we started working on that board). The best way to build upstream firmware for one of those derivative boards (like Wolf) is probably to find the corresponding lead board (in this case Falco), diff the respective two boards in the Chromium firmware branch(es), and apply that (hopefully very small) diff to the current upstream version of that lead board. 5) Despite attempting to set the boot menu key to ESC rather than F12 (and verifying the boot-menu-key and boot menu-message appeared with csfbtool), it still came up with F12 when I booted. Fortunately I have a USB keyboard handy, and was still able to boot a Lubuntu install. Did you use SeaBIOS directly as a payload, or did you build an image the Chromium way (with the depthcharge payload that chainloads SeaBIOS when you press CTRL+L)? In the latter case SeaBIOS is wrapped into its own little CBFS in a different FMAP section, and you cannot directly access it with cbfstool without extracting it first (you would instead write your files to the main coreboot CBFS where nothing is reading them from). -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on May 11, 2015 at 8:58 pm
A new post On coreboot leadership... - http://blogs.coreboot.org/blog/2015/05/11/on-coreboot-leadership/ has been published on May 11, 2015 at 8:58 pm. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
