coreboot September 2014

coreboot@coreboot.org

51 participants
90 discussions

Re: [coreboot] Linux-kernel as payload
by John Lewis 08 Sep '14

08 Sep '14

Hi, You have to use mkelfImage to convert the bzImage to elf format. It's in the utils folder of coreboot. John. On 08/09/14 09:25, Werner Zeh wrote: > Hi. > I try to use the linux kernel as payload in coreboot. I use a bzImage of > the kernel. > When I compile, I get the following message: > OBJCOPY cpu/x86/smm/smm_wrap.ramstage.o > CC generated/ramstage.o > CC cbfs/fallback/ramstage.debug > OBJCOPY cbfs/fallback/ramstage.elf > CBFS coreboot.rom > PAYLOAD ../bzImage (compression: none) > E: The stage file is not in ELF format! > CONFIG .config > CBFSPRINT coreboot.rom > coreboot.rom: 4096 kB, bootblocksize 848, romsize 4194304, offset 0x0 > alignment: 64 bytes > Name Offset Type Size > fallback/romstage 0x0 stage 20906 > fallback/ramstage 0x5200 stage 62994 > fallback/payload 0x14880 payload 1392465 > config 0x168840 raw 3366 > (empty) 0x1695c0 null 2713240 > Am I wrong assumimg that the image may be a real (compressed) bzImage? > Should I use a vmlinuz better? Or is my bzImage is not suitable (maybe > parts of it are compressed or so)? > Thanks. > >

3 6

AMD R-series APU based boards
by sanjeev chauhan 08 Sep '14

08 Sep '14

Hi all, I am wondering if there are any AMD R-series APU (not SoC) based boards supported by coreboot. I know some AMD G-series APU based boards are supported but am specifically interested in R-series APUs because of their higher processing power. Thanks, sanjeev

1 0

Re: [coreboot] Linux-kernel as payload
by Patrick Georgi 08 Sep '14

08 Sep '14

Am 08.09.2014 um 10:25 schrieb Werner Zeh: > PAYLOAD ../bzImage (compression: none) > E: The stage file is not in ELF format! Well, that's certainly true, isn't it? :-) (technical details: we have three payload parsers - ELF, bzImage and special-Tianocore, of which the ELF parser is the first. If it fails, it whines a bit on the console, then the others get a chance). > Am I wrong assumimg that the image may be a real (compressed) bzImage? > Should I use a vmlinuz better? Or is my bzImage is not suitable (maybe > parts of it are compressed or so)? Using a bzImage is the most recently tested approach to making a payload out of a linux kernel, so this is the way to go. Patrick

1 0

Linux-kernel as payload
by Werner Zeh 08 Sep '14

08 Sep '14

1 0

Re: [coreboot] bug YT as EHCI gadget for coreboot
by Denis 'GNUtoo' Carikli 07 Sep '14

07 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 03 Sep 2014 16:43:36 +0200 Marek Doležel <xdolez67(a)stud.feec.vutbr.cz> wrote: > Hello, > > I noticed you are in connection with buglabs community. > > I couldn't find any option to buy this device. I guess the device is > developed only for "Big players" as mentioned on website. > > It would be great if I could get hands on that device. You have one > right? How hard can it be to get DEMO or to get option to purchase one > from them? > > As mentioned in subject I am trying some coreboot now. I keep track > of what I do here > http://www.stud.feec.vutbr.cz/~xdolez67/coreboot/coreboot-porting.html > I use ThinkPad X200 image/source code as reference (don't have it) to > make coreboot work on ThinkPad R400/T400. However I tried many times > and can't get serial output(I am not hardcore embedded guy yet). So I > realized I need to get EHCI gadget to get any further and if that also > fails I need to also get ThinkPad X200. Coreboot mailing list probably has good hints here. I've cc-ed the list for that. > I see this options: > 1. get for free or purchase bug device, > 2. get 2x LCSoft FX2LP (soldering required:( but cheap ) > 3. get bbb (too expensive 90$ incl. shipping to czech 4. Use your rasberry and try to make g_dbgp work there, to test use the linux kernel with earlyprintk=dbgp. Note that earlyprintk=dbgp doesn't work out of the box on all distro's kernels, you need the right compilation options to make it work. Denis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUCVViAAoJENWQk6o21VqZ/gwQAKC2IfJEFav03Q/2QFjABJiB D5zLqRGzuR3JwgxS1qAPnsC+BcuGy+TIpl5AujrCLSlUD/HWXJAqoiFVxdNxacgl /dBG5TeCJeU31BE6bl2zsKLXUGSlJGiokWXcl46sA8B/bTTpHOqU2LyIXnjYq9J7 hwCnYJBUZ3CCyy+8BOuQj4MJPflIIzn2RyCDN0f3e1HDVNbC7jQEuuHkXLxDvj5a UuQiqvDfNH45efW0Ioh/W68xy2agoEYDLieBkAjlhBGtS79BBVtlaNBJGyA3dJun 0NIPjmYSDm+uW8Wfk/kt0pECNQv+wXe24+V59lc1SP8SjZlcd2qPdiYOqvyXNHkP LOtNZAhS3mPlODCk5gu67VqMbA4GOnWSiTgOQ7EUUs4pK0f9JHs1nIhWdtfY0juU JAJUiYX45DDrD9sM4K7voTWc2KwfKK4DauroT6YcKT6PxslfPD6yj53RH0y8uKZl VdX/QVQyscMm7WhP78kjJFmZvNLV8jsfacK217FRxv3+2LBRTsXmVIi4ocmtUcU9 df50fywdPBh3yG9M75xSynsb1NlaviTES1gnRMEAG0cFIh+EQlT1NPwQaQwKJWu8 UX40rsV+WT+RDKrKq24xoH1KOXiR24sL8yGHl1zLVADheopsAek3gnUlUwzXjc23 tKTWbbN2q9PAIIraEtoP =l5Qd -----END PGP SIGNATURE-----

3 4

[PATCH] x86: add coreboot framebuffer support
by Gerd Hoffmann 05 Sep '14

05 Sep '14

Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- arch/x86/Kconfig | 12 +++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/coreboot.c | 232 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 245 insertions(+) create mode 100644 arch/x86/kernel/coreboot.c diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 778178f..3aeb038 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2372,6 +2372,18 @@ config X86_SYSFB If unsure, say Y. +config COREBOOT + bool "coreboot" + depends on X86_SYSFB + depends on FB_SIMPLE + help + Add coreboot framebuffer support to the linux kernel. Say Y here + if you want the linux kernel find and use the firmware framebuffer + initialized by coreboot. Useful when using the linux kernel as + coreboot payload. + + If unsure, or if you don't know what coreboot is, say N. + endmenu diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index ada2e2d..4b30b0e 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -103,6 +103,7 @@ obj-$(CONFIG_UPROBES) += uprobes.o obj-y += sysfb.o obj-$(CONFIG_X86_SYSFB) += sysfb_simplefb.o obj-$(CONFIG_EFI) += sysfb_efi.o +obj-$(CONFIG_COREBOOT) += coreboot.o obj-$(CONFIG_PERF_EVENTS) += perf_regs.o obj-$(CONFIG_TRACING) += tracepoint.o diff --git a/arch/x86/kernel/coreboot.c b/arch/x86/kernel/coreboot.c new file mode 100644 index 0000000..44ed3fa --- /dev/null +++ b/arch/x86/kernel/coreboot.c @@ -0,0 +1,232 @@ +/* + * Find and parse coreboot tables. Register framebuffer if present. + * See src/include/boot/coreboot_tables.h in coreboot source tree. + */ + +#include <linux/kernel.h> +#include <linux/slab.h> +#include <linux/mm.h> +#include <linux/screen_info.h> +#include <linux/platform_device.h> +#include <linux/platform_data/simplefb.h> +#include <video/vga.h> + +#include <asm/checksum.h> +#include <asm/io.h> +#include <asm/sysfb.h> + +struct cb_header { + u32 signature; + u32 header_bytes; + u32 header_checksum; + u32 table_bytes; + u32 table_checksum; + u32 table_entries; +}; + +#define CB_TAG_MAINBOARD 0x0003 +#define CB_TAG_VERSION 0x0004 +#define CB_TAG_FORWARD 0x0011 +#define CB_TAG_FRAMEBUFFER 0x0012 + +struct cb_mainboard { + u8 vendor_idx; + u8 part_idx; + char strings[0]; +}; + +struct cb_framebuffer { + u64 physical_address; + u32 x_resolution; + u32 y_resolution; + u32 bytes_per_line; + u8 bits_per_pixel; + u8 red_mask_pos; + u8 red_mask_size; + u8 green_mask_pos; + u8 green_mask_size; + u8 blue_mask_pos; + u8 blue_mask_size; + u8 reserved_mask_pos; + u8 reserved_mask_size; +}; + +struct cb_entry { + u32 tag; + u32 size; + union { + char string[0]; + u64 forward; + struct cb_mainboard mb; + struct cb_framebuffer fb; + } u; +}; + +#define CB_SIGNATURE 0x4f49424C /* "LBIO" */ + +/* Try to locate the coreboot header in a given address range. */ +static __init struct cb_header *coreboot_find_header(u32 addr, int len) +{ + struct cb_header *cbh, *copy; + int offset; + void *map; + + map = ioremap(addr, len); + for (offset = 0; offset < len; offset += 16) { + cbh = map + offset; + if (!cbh) + continue; + if (cbh->signature != CB_SIGNATURE) + continue; + if (!cbh->table_bytes) + continue; + if (ip_compute_csum(cbh, sizeof(*cbh)) != 0) + continue; + if (ip_compute_csum(cbh + 1, cbh->table_bytes) + != cbh->table_checksum) + continue; + pr_debug("coreboot: header found at 0x%x\n", + addr + offset); + copy = kzalloc(sizeof(*cbh) + cbh->table_bytes, GFP_KERNEL); + memcpy(copy, cbh, sizeof(*cbh) + cbh->table_bytes); + iounmap(map); + return copy; + } + iounmap(map); + return NULL; +} + +static __init bool check_vga_text_mode(void) +{ + uint8_t reg; + + if (screen_info.orig_video_isVGA != 1) + return false; + + reg = inb(VGA_GFX_I); + if (reg == 0xff) + /* no vga present */ + return false; + + outb(VGA_GFX_MISC, VGA_GFX_I); + reg = inb(VGA_GFX_D); + if (reg & 0x01) + /* vga is in gfx mode */ + return false; + + return true; +} + +static __init void coreboot_fb_init(struct cb_framebuffer *fb) +{ + const char *reason = ""; + struct simplefb_platform_data mode; + struct screen_info si; + struct resource res; + + pr_info("coreboot: framebuffer: %dx%d, %d bpp, at %llx\n", + fb->x_resolution, + fb->y_resolution, + fb->bits_per_pixel, + fb->physical_address); + + if (screen_info.orig_video_isVGA == VIDEO_TYPE_VLFB) { + reason = "have vesa lfb"; + goto skip; + } + if (screen_info.orig_video_isVGA == VIDEO_TYPE_EFI) { + reason = "have efi gop"; + goto skip; + } + if (check_vga_text_mode()) { + reason = "vga is in text mode"; + goto skip; + } + + memset(&si, 0, sizeof(si)); + si.orig_video_isVGA = VIDEO_TYPE_VLFB; + si.lfb_width = fb->x_resolution; + si.lfb_height = fb->y_resolution; + si.lfb_depth = fb->bits_per_pixel; + si.lfb_base = fb->physical_address; + si.lfb_linelength = fb->bytes_per_line; + si.lfb_size = + (fb->y_resolution * fb->bytes_per_line + 65535) / 65536; + si.pages = 1; + si.red_size = fb->red_mask_size; + si.red_pos = fb->red_mask_pos; + si.green_size = fb->green_mask_size; + si.green_pos = fb->green_mask_pos; + si.blue_size = fb->blue_mask_size; + si.blue_pos = fb->blue_mask_pos; + si.rsvd_size = fb->reserved_mask_size; + si.rsvd_pos = fb->reserved_mask_pos; + if (!parse_mode(&si, &mode)) { + reason = "mode not compatible"; + goto skip; + } + + memset(&res, 0, sizeof(res)); + res.flags = IORESOURCE_MEM | IORESOURCE_BUSY; + res.name = "coreboot-fb"; + res.start = si.lfb_base; + res.end = si.lfb_base + si.lfb_size * 65536 - 1; + + pr_info("coreboot: setting up simplefb\n"); + platform_device_register_resndata(NULL, "simple-framebuffer", 0, + &res, 1, &mode, sizeof(mode)); + return; + +skip: + pr_info("coreboot: skipping framebuffer setup (%s)\n", reason); + return; +} + +static __init int coreboot_detect(void) +{ + struct cb_header *cbh; + struct cb_entry *cbe; + u64 addr = 0; + void *next; + int i; + +newheader: + cbh = coreboot_find_header(addr, 0x1000); + if (!cbh) + return 0; + + next = cbh + 1; + for (i = 0; i < cbh->table_entries; i++) { + cbe = next; + next += cbe->size; + switch (cbe->tag) { + case CB_TAG_MAINBOARD: + pr_info("coreboot: mainboard: %s / %s\n", + cbe->u.mb.strings + cbe->u.mb.vendor_idx, + cbe->u.mb.strings + cbe->u.mb.part_idx); + break; + case CB_TAG_VERSION: + pr_info("coreboot: version: %s\n", + cbe->u.string); + break; + case CB_TAG_FORWARD: + pr_debug("coreboot: forward to 0x%llx\n", + cbe->u.forward); + addr = cbe->u.forward; + kfree(cbh); + goto newheader; + case CB_TAG_FRAMEBUFFER: + coreboot_fb_init(&cbe->u.fb); + break; + default: + pr_debug("%s: unhandled tag 0x%x (size %d)\n", + __func__, cbe->tag, cbe->size); + break; + } + } + + kfree(cbh); + return 0; +} + +device_initcall(coreboot_detect); -- 1.8.3.1

5 8

Re: [coreboot] X201i RAM upgrade not working
by Mono 05 Sep '14

05 Sep '14

I was not hot plugging them, but powering off and removing the battery as well during each change with the DIMMs. I absolutely don't know why it did not work before using the second slot separately. It might just have been random? greets Mono On Fri, Sep 05, 2014 at 01:57:36PM -0700, ron minnich wrote: > Or are you booting with the second slot full, powering off, loading > both slots, and it works because of the MRC cache? > > On Fri, Sep 5, 2014 at 1:57 PM, ron minnich <rminnich(a)gmail.com> wrote: > > On Fri, Sep 5, 2014 at 1:56 PM, Mono <lists+coreboot(a)donderklumpen.de> wrote: > >> um, I tested the second slot separately as suggested by phcoder and after that they work together too. > >> thanks! > > > > I don't understand. > > > > The second slot works separately, and now both slots work? What's the > > "after" mean? Are you hot plugging the DIMM? > > > > ron

2 1

Re: [coreboot] X201i RAM upgrade not working
by ron minnich 05 Sep '14

05 Sep '14

Or are you booting with the second slot full, powering off, loading both slots, and it works because of the MRC cache? On Fri, Sep 5, 2014 at 1:57 PM, ron minnich <rminnich(a)gmail.com> wrote: > On Fri, Sep 5, 2014 at 1:56 PM, Mono <lists+coreboot(a)donderklumpen.de> wrote: >> um, I tested the second slot separately as suggested by phcoder and after that they work together too. >> thanks! > > I don't understand. > > The second slot works separately, and now both slots work? What's the > "after" mean? Are you hot plugging the DIMM? > > ron

1 0

X201i RAM upgrade not working
by Mono 05 Sep '14

05 Sep '14

Hallo all, Is anyone successfuly running the x201 port with two RAM modules installed? I am using it (commit 8128a56c0ec7e147d4ad68e6ba55979e9ead25ae from Sep 18) for booting a x201i computer with only one RAM module (2GB). As soon as I insert a second RAM module (2GB) it does not boot anymore. The screen stays black, grub is not showing up. Both modules work when just one of them is installed. Do I need to change anything in the coreboot configuration for supporting two RAM modules? any help is much appreciated! Mono

2 2

Re: [coreboot] How to translate a PCI_DEV macro to struct device (device_t)?
by Aaron Durbin 04 Sep '14

04 Sep '14

On Thu, Sep 4, 2014 at 2:57 PM, Ricardo Menzer <ricardomenzer(a)gmail.com> wrote: > Hi guys, > I'm trying to port an old Intel version of coreboot for tunnelcreek to > a newer version of the coreboot code. > > I'm stuck at a point in which the boot stops at get_pbus(device_t dev) > because dev is NULL (0x0). > > I think the problem is in a function that calls pci_write_config32, > but using PCI_DEV(0,0,0) to access the bus 0, device 0, function 0. > PCI_DEV(0,0,0) evaluates to 0x0, which get_pbus interprets as a NULL > pointer. This is used in the 'dev' parameter of pci_write_config32. get_pbus() is only used in ramstage which uses struct device * (device_t). Depending on where you are wanting to call this you may already have a device_t. If not you'll need to do the lookup using dev_find_slot(). > > > I looked at the source code and in the mailing list, but couldn't find > a way to pass a correct dev parameter to the function. > I'm also not so sure I am in the right path. I may be confusing thing > a little, since I'm no so experienced in x86 hardware and firmware > levels. I'm also learning coreboot at my own, it's a lot of > information at the same time being pushed at my brain! ;) > > I appreciate any help and clarifications! > > Thank you very much! > > > Ricardo Menzer > ricardomenzer(a)gmail.com > +55 (32) 8865-8805 > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2014