coreboot August 2016

coreboot@coreboot.org

53 participants
132 discussions

Mistery of the function: static void enable_rom_caching(void)
by Zoran Stojsavljevic 08 Aug '16

08 Aug '16

Hello community, I was/got again today in Coreboot directory src/soc/intel/braswell/bootblock/bootblock.c looking at static void enable_rom_caching(void). Then, since Paul Menzel have announcement ([ANNOUNCEMENT] Support for Intel Kaby Lake), I went to look into src/soc/intel/skylake/bootblock/bootblock.c, but I did not find this function. Kaby Lake patches do not support this function as well. Then I did the following on my WIN 10 (using VMware workstation 12) VM Fedora 24: [zoran@localhost intel]$ pwd /home/zoran/projects/coreboot/coreboot/src/soc/intel [zoran@localhost intel]$ git describe 4.4-1038-gdd65ef8 [zoran@localhost intel]$ ls -al total 48 drwxrwxr-x. 12 4096 Aug 1 10:02 . drwxrwxr-x. 14 4096 Aug 1 10:02 .. drwxrwxr-x. 5 4096 Aug 1 10:02 apollolake drwxrwxr-x. 6 4096 Aug 1 10:02 baytrail drwxrwxr-x. 6 4096 Aug 1 10:02 braswell drwxrwxr-x. 6 4096 Aug 1 10:02 broadwell drwxrwxr-x. 3 4096 Aug 1 10:02 common drwxrwxr-x. 7 4096 Aug 1 10:02 fsp_baytrail drwxrwxr-x. 7 4096 Aug 1 10:02 fsp_broadwell_de drwxrwxr-x. 5 4096 Aug 1 10:02 quark drwxrwxr-x. 3 4096 Aug 1 10:02 sch drwxrwxr-x. 7 4096 Aug 1 10:02 skylake [zoran@localhost intel]$ grep -r enable_rom * baytrail/bootblock/bootblock.c:static void enable_rom_caching(void) baytrail/bootblock/bootblock.c: enable_rom_caching(); braswell/bootblock/bootblock.c:static void enable_rom_caching(void) braswell/bootblock/bootblock.c: enable_rom_caching(); broadwell/bootblock/cpu.c:static void enable_rom_caching(void) broadwell/bootblock/cpu.c: enable_rom_caching(); fsp_baytrail/bootblock/bootblock.c:static void enable_rom_caching(void) fsp_baytrail/bootblock/bootblock.c: enable_rom_caching(); [zoran@localhost intel]$ We see here that from skylake (also does not exists in apollolake) this function is dropped. Any logical explanation for this mismatch? Thank you, Zoran

1 0

How to add Medion AKOYA S2013 (google/veyron_jaq)
by Paul Menzel 07 Aug '16

07 Aug '16

Dear coreboot folks, I got the Rockchip RK3288 based Google Chromebook Medion AKOYA S2013 which is or is based on the google/veyron_jaq board. In the tree, there is currently the Haier Chromebook 11, also based on `google/veyron_jaq`. `src/mainboard/google/veyron/Kconfig.name` contains: 5 config BOARD_GOOGLE_VEYRON_JAQ 6 bool "Haier Chromebook 11 (Veyron_Jaq)" 7 select BOARD_GOOGLE_VEYRON 8 select SYSTEM_TYPE_LAPTOP How can the Medion AKOYA S2013 be added, so that it is available in the list? Just add it to the description as it’s the same board? Thanks, Paul

3 2

Re: [coreboot] Strange postcodes
by Łukasz Dobrowolski 07 Aug '16

07 Aug '16

@Zoran: You are right. I just didn't know where those codes mean. After adding VGA BIOS i got to see the result. @Patrick: Seems that I haven't searched well enough. Sorry for the noise. In the thread Zoran pointed me to there was a nice idea to redirect normal postcodes to different address or disable them. If something else was writting postcodes then i would be easy to confirm that. Thanks You for Your help Zoran, Patrick! On 8/7/16, Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote: >> 79 24 98 7A A8 *F8* >>... >> Any thoughts? > > If you came to 0xF8 postcode, you successfully booted Coreboot. So, your > question is not too clear to me?! > > You can also read this thread, it might help you: > https://www.mail-archive.com/coreboot@coreboot.org/msg46341.html > > Zoran > > On Sun, Aug 7, 2016 at 10:11 AM, Łukasz Dobrowolski > <spectrallynx(a)gmail.com> > wrote: > >> Hello! >> I'm porting cb to ThinkPad X120e. I've used code from asrock/e350m1 as >> basis and made some small changes. >> >> I'm getting following postcodes. Those are after "50" so romstage.c >> finished executing. (System sometimes goes this far, other times it >> hangs earlier.) >> 79 24 98 7A A8 F8 >> >> I tried to find them in like this: >> grep -R 'post_code(0x24);' >> I've only found "24", it's in device/pci_device.c:1113. Whatever is >> sending the rest of the postcodes is not using post_code() function. >> >> I can think of 3 explanations: >> Payload is sending those postcodes. -> Seams unlikely, I'm >> using Seabios. I've read some of the code and can't find any places >> that would send the codes. >> ASM parts of cb/AGESA. >> EC(ITE IT8518E) is sending the codes. >> >> Any thoughts? >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> >

1 0

ASUS KFSN4-DRE (K8) Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 07 Aug '16

07 Aug '16

The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit 5d4194978275c2e3acf09788f80887023ca9ffe8 The following tests failed: BOOT_FAILURE Commits since last successful test: 5d41949 soc/intel/skylake: Add Kabylake device Ids dfb3735 google/reef: Enable I2C2 for use in bootblock 3731903 acpi: Generate object for coreboot table region d89bcf2 drivers/intel/fsp1_1: only set a base address for FSP in COREBOOT CBFS 35cca5a drivers/intel/fsp2_0: Ensure EC is in right mode before memory init <24 commits skipped> d1a0051 google/gale: Add more board ID variants 40d62f3 google/gru: Add code to support I2C TPM for Kevin 5e6771b google/gru: Add support for Gru rev1 47ca65a payloads/coreinfo: Set KCONFIG_CONFIG value 5fafc6a soc/intel/quark: Support access to CPU CR registers See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE (K8) test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

[ANNOUNCEMENT] Support for Intel Kaby Lake
by Paul Menzel 07 Aug '16

07 Aug '16

Dear coreboot folks, Intel has started to submit change sets adding support for the new chipset Intel Kaby Lake [1]. > Kaby Lake is Intel's codename for the upcoming 14 nanometer successor > to the Skylake microarchitecture. Kaby Lake began shipping to > manufacturers and OEMs in the second quarter of 2016, though volume > production for the retail channel is anticipated late-2016. > > Skylake was to be succeeded by the 10 nanometer Cannonlake, but it > was announced on July 16, 2015, that Cannonlake has been delayed > until the second half of 2017. As it’s very similar to Intel Skylake, the goal is to adapt the Intel Skylake code, so that it supports both chipsets. [2][3] Thanks, Paul [1] https://en.wikipedia.org/wiki/Kaby_Lake [2] https://review.coreboot.org/15768 [3] https://review.coreboot.org/16049 [4] https://review.coreboot.org/16050

2 1

ASRock E350M1 boots fine with GCC 6.1.1 from Debian Sid/unstable
by Paul Menzel 07 Aug '16

07 Aug '16

Dear coreboot folks, I just wanted to let you know, that the AMD Fusion board ASRock E350M1 boots fine with a coreboot firmware image with a SeaBIOS payload, built with GCC 6.1.1 from Debian Sid/unstable. ``` $ gcc --version gcc (Debian 6.1.1-11) 6.1.1 20160802 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` The logs can be found in the board status repository. • asrock/e350m1/4.4-1119-g35cca5a • asrock/e350m1/4.4-1123-g5d41949 Thanks, Paul

1 0

[ANNOUNCEMENT] Removal of NVIDIA Tegra T132 devices
by Paul Menzel 07 Aug '16

07 Aug '16

Dear coreboot folks, this is just a notification, that the development boards google/rush [1] and google/rush_ruy [2] using the NVIDIA Tegra T132 chipset are going to be removed, as these development boards are not available anymore, and never made it into a product. The chipset code is also removed, as there are no users left [3]. Thanks, Paul [1] https://review.coreboot.org/16106 [2] https://review.coreboot.org/16107 [3] https://review.coreboot.org/16108

1 0

Re: [coreboot] Grub payload on X220: Reboot when trying to load Fedora with grub payload, works with SeaBIOS.
by Paul Menzel 07 Aug '16

07 Aug '16

Dear Evan, Am Sonntag, den 31.07.2016, 21:20 -0700 schrieb Evan Cramer: > I've gotten pretty far along with coreboot on my X220 running Fedora 23. > I've extracted a VGA option ROM, and it loads correctly. I have grub > configured as the primary payload, which can chainload SeaBIOS from its > memdisk. The grub.cfg in cbfs can find and load the grub.cfg in /boot on my > ssd. > > However, here's my problem. While grub finds the grub.cfg on the ssd and > presents me with a list of Fedora kernels to boot, when I select one, the > screen turns black and the system appears to reboot displaying "Welcome to > GRUB!", and then drops me back to grub, presenting the options in my > (cbfsdisk)/etc/grub.cfg menu. > > However, if I chainload SeaBIOS, it correctly finds grub in the MBR on the > ssd which loads the grub.cfg on the ssd, and when I select the Fedora > kernel, it drops me at the LUKS password prompt as expected, and boots > Fedora just fine after I enter my FDE password. > > As mentioned before, I have extracted a working VGA option ROM and included > it in the image. Since graphics in SeaBIOS works now I'm confident that's > working. I have configured coreboot to load the VGA option ROM itself, as > when I set native graphics initialization but included the option ROM in > the cbfs disk, I got no video output in SeaBIOS. This is probably because > SeaBIOS is in the Grub2 memdisk, not cbfs, and can't reach the option ROM. To my knowledge, you can either use native graphics initialization with SeaVGABIOS or the proprietary vendor Video BIOS, but not both together. > Also mentioned before, I'm using LUKS full disk encryption. Grub doesn't > complain about any missing modules, and my grub mkstandalone invocation is > as follows: > > ../grub-mkstandalone \ > --grub-mkimage=../grub-mkimage -O i386-coreboot -o ../grub2-X220.elf \ > --modules='ahci ehci uhci usb_keyboard usbms part_msdos xfs ext2 fat > at_keyboard part_gpt usbserial_usbdebug cbfs minix_be minix minix3_be > minix3 minix2_be minix2 ufs2 ufs1_be ufs1 udf romfs procfs odc nilfs2 > newc iso9660 cpio exfat cpio_be afs video_bochs password png keystatus > sleep loopback gfxterm_background' \ > --install-modules='syslinuxcfg bsd ls cat echo linux linux16 search > configfile normal cbtime cbls memrw iorw minicmd lsmmap lspci halt > reboot hexdump pcidump regexp setpci lsacpi chain test lvm crypto > cryptodisk luks gzio gfxterm all_video' \ > --fonts= \ > --themes= \ > --locales= \ > -d ../grub-core/ \ > /boot/grub/grub.cfg=../coreboot.cfg \ > $(find -type f) > > I'm including luks, crypto, cryptodisk, and lvm, among many of things, so I > don't think it's an issue with not having the modules necessary for > mounting an encrypted disk. I'm not really sure where to go from here. I > don't have any usb_serial or serial interfaces to do debug, but since I > have video by this point I'm not really sure this would give me any more > information. Is there some way I can get grub to print what problems it is > having that makes it reboot? I suspect it's some kind of problem with > video, since the prompt for the LUKS password has a background image. And > since it works fine on SeaBIOS... > > Also, if it helps, this is my config as extracted from the ROM. > > This image was built using coreboot 4.4-523-gd71cfd2-dirty Your source is marked as dirty. What changes do you have in coreboot? (`git status`, `git diff` or `git diff --cached` should give a hint.) > CONFIG_BOOTSPLASH_IMAGE=y > CONFIG_BOOTSPLASH_FILE="~/Projects/blobs/bootsplash.png" > CONFIG_VENDOR_LENOVO=y > CONFIG_VGA_BIOS=y > CONFIG_VGA_BIOS_FILE="~/Projects/blobs/vgabios.bin" > CONFIG_HAVE_IFD_BIN=y > CONFIG_HAVE_ME_BIN=y > CONFIG_HAVE_GBE_BIN=y > CONFIG_BOARD_LENOVO_X220=y > # CONFIG_S3_VGA_ROM_RUN is not set > CONFIG_FRAMEBUFFER_SET_VESA_MODE=y > CONFIG_BOOTSPLASH=y > CONFIG_PAYLOAD_ELF=y > CONFIG_PAYLOAD_FILE="/home/ecramer/Projects/grub/grub2-X220.elf" > CONFIG_COREINFO_SECONDARY_PAYLOAD=y > CONFIG_DEBUG_CBFS=y > > Also, here is a link to my grub configs http://pastebin.com/CSitTf34 Please attach text files to messages. Use paste sites just for IRC. > The first is the grub.cfg in /boot/grub2 and the second is the grub.cfg > included in the CBFS in coreboot.rom > > Does anybody have any tips of where I should go from here? I'm out of ideas > on how to debug this. More debugging messages are needed. Does `set debug=all` [1] – I think that’s the syntax – help? What happens if you enter the lines from the config manually on the GRUB command line? Do you see on what line it reboots? Thanks, Paul [1] https://www.gnu.org/software/grub/manual/html_node/debug.html

1 0

Re: [coreboot] Strange postcodes
by Zoran Stojsavljevic 07 Aug '16

07 Aug '16

> 79 24 98 7A A8 *F8* >... > Any thoughts? If you came to 0xF8 postcode, you successfully booted Coreboot. So, your question is not too clear to me?! You can also read this thread, it might help you: https://www.mail-archive.com/coreboot@coreboot.org/msg46341.html Zoran On Sun, Aug 7, 2016 at 10:11 AM, Łukasz Dobrowolski <spectrallynx(a)gmail.com> wrote: > Hello! > I'm porting cb to ThinkPad X120e. I've used code from asrock/e350m1 as > basis and made some small changes. > > I'm getting following postcodes. Those are after "50" so romstage.c > finished executing. (System sometimes goes this far, other times it > hangs earlier.) > 79 24 98 7A A8 F8 > > I tried to find them in like this: > grep -R 'post_code(0x24);' > I've only found "24", it's in device/pci_device.c:1113. Whatever is > sending the rest of the postcodes is not using post_code() function. > > I can think of 3 explanations: > Payload is sending those postcodes. -> Seams unlikely, I'm > using Seabios. I've read some of the code and can't find any places > that would send the codes. > ASM parts of cb/AGESA. > EC(ITE IT8518E) is sending the codes. > > Any thoughts? > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] ARM Trusted Firmware build issue
by Paul Kocialkowski 07 Aug '16

07 Aug '16

Hey, Le mercredi 03 août 2016 à 09:18 -0600, Martin Roth a écrit : > I'll get that patch tested and replace the current patch with it if it > works. I just did over the week-end (building elm, but obviously couldn't test on the device) and the patch proposed by upstream solves the issue as well. It was merged in binutils in the meantime: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ea12e5c3ad54da4… I'll update the patch we have in crossgcc ASAP. Thanks! > On Tue, Aug 2, 2016 at 9:51 AM, Paul Kocialkowski <contact(a)paulk.fr> wrote: > > > > Le mercredi 20 juillet 2016 à 19:33 -0700, Stefan Reinauer a écrit : > > > > > > Martin produced a binutils fix for the issue. Whether the binutils > > > people will find it to be the "right" fix is still to be found out, but > > > it seems to allow compiling the latest, unmodified ARM TF. > > > > Upstream just answered with a comprehensive description of what is happening > > and > > a patch to solve the issue, at: > > https://sourceware.org/bugzilla/show_bug.cgi?id=20364 > > > > Could someone try that and report back (either here directly on the tracker) > > whether it solves the issue? There's a chance this fix will be accepted > > upstream > > if it works. > > > > Cheers, > > > > -- > > Paul Kocialkowski, developer of low-level free software for embedded devices > > > > Website: https://www.paulk.fr/ > > Coding blog: https://code.paulk.fr/ > > Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ >

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2016