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@…
[View More]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
[View Less]
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 …
[View More]available in the
list? Just add it to the description as it’s the same board?
Thanks,
Paul
[View Less]
@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.…
[View More]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
>>
>
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]board status repository.
• asrock/e350m1/4.4-1119-g35cca5a
• asrock/e350m1/4.4-1123-g5d41949
Thanks,
Paul
[View Less]
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
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 …
[View More]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
[View Less]
> 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 …
[View More]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
>
[View Less]
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!
&…
[View More]gt; 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/
>
[View Less]