coreboot March 2017

coreboot@coreboot.org

79 participants
267 discussions

Re: [coreboot] Coreboot wiki: what license is the content under?
by Martin Roth 21 Mar '17

21 Mar '17

Hey Sam. You're absolutely right, and I appreciate you pointing this out. We need to get this fixed. Actually, as part of coreboot joining the Software Freedom Conservancy, our documentation NEEDS an open license of one sort or another. Is there a reason we shouldn't switch to CC BY 4.0? - Do we really need BY-SA? How much of the coreboot documentation is applicable anywhere else? Why not just go with the least restrictive license? - Do we really care what Stack Exchange or any other group is using? How much are we copying from them? Here are the CC licenses: https://creativecommons.org/licenses/ Discussion of CC BY-SA vs GFDL :https://wiki.creativecommons.org/wiki/GFDL_versus_CC-by-sa Once we decide which license to switch to, I think we're going to have to remove or rewrite any documentation contributions from people who don't want to agree to the license or who can't be reached. Martin On Tue, Mar 21, 2017 at 10:53 AM, Sam Kuper <sam.kuper(a)uclmail.net> wrote: > On 17/03/2017, Sam Kuper <sam.kuper(a)uclmail.net> wrote: >> Also: sanity check. Does anyone else here besides me and Timothy feel >> that making the wiki documentation available under a free culture >> license would be a good idea? > > A few other wiki users agreed with us, which is great: > > https://www.coreboot.org/User:GNUtoo#Wiki_contributions > > https://www.coreboot.org/User:Samnob > > https://www.coreboot.org/User_talk:Kl3 > > The relative silence about this topic on this mailing list makes me > wonder, though: does anyone here think it would be a *bad* idea for > the Coreboot wiki contents to be under a free culture license? If you > do, would you mind explaining why? > > Thanks! > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Add me_cleaner to automated tests?
by Martin Roth 21 Mar '17

21 Mar '17

Most of our current automated testing is just build testing, although we're working to expand that. The boot testing we DO have doesn't currently include any boards with an ME - they're currently all boards that don't require any blobs. Martin On Tue, Mar 21, 2017 at 10:12 AM, Sam Kuper <sam.kuper(a)uclmail.net> wrote: > I am still very new to Coreboot. > > I understand that Coreboot has an automated test system, so that each > push to the repo builds and tests the result automatically. > > I also see that me_cleaner is now part of the Coreboot repo, under > coreboot/util/me_cleaner/ . > > Instead of relying on manual test reports for me_cleaner,[0] would it > be possible for Coreboot's automated test system to be extended such > that it additionally attempts to apply me_cleaner, and to test the > results? > > That way, incompatibilities between Coreboot and me_cleaner might be > more readily discovered and fixed.[1] > > Thanks, > > Sam > > [0] E.g. https://github.com/corna/me_cleaner/issues/3 > > [1] E.g. https://www.coreboot.org/pipermail/coreboot/2017-March/083686.html > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Coreboot wiki: what license is the content under?
by Sam Kuper 21 Mar '17

21 Mar '17

On 17/03/2017, Sam Kuper <sam.kuper(a)uclmail.net> wrote: > Also: sanity check. Does anyone else here besides me and Timothy feel > that making the wiki documentation available under a free culture > license would be a good idea? A few other wiki users agreed with us, which is great: https://www.coreboot.org/User:GNUtoo#Wiki_contributions https://www.coreboot.org/User:Samnob https://www.coreboot.org/User_talk:Kl3 The relative silence about this topic on this mailing list makes me wonder, though: does anyone here think it would be a *bad* idea for the Coreboot wiki contents to be under a free culture license? If you do, would you mind explaining why? Thanks!

1 0

Add me_cleaner to automated tests?
by Sam Kuper 21 Mar '17

21 Mar '17

I am still very new to Coreboot. I understand that Coreboot has an automated test system, so that each push to the repo builds and tests the result automatically. I also see that me_cleaner is now part of the Coreboot repo, under coreboot/util/me_cleaner/ . Instead of relying on manual test reports for me_cleaner,[0] would it be possible for Coreboot's automated test system to be extended such that it additionally attempts to apply me_cleaner, and to test the results? That way, incompatibilities between Coreboot and me_cleaner might be more readily discovered and fixed.[1] Thanks, Sam [0] E.g. https://github.com/corna/me_cleaner/issues/3 [1] E.g. https://www.coreboot.org/pipermail/coreboot/2017-March/083686.html

1 0

Re: [coreboot] Lenovo Thinkpad X201: Coreboot incompatible with me_cleaner
by Sam Kuper 21 Mar '17

21 Mar '17

On 21/03/2017, Sam Kuper <sam.kuper(a)uclmail.net> wrote: > I have been investigating booting my X201 on two axes: > > - Coreboot vs stock BIOS > > - Intel Management Engine left alone vs neutralised with me_cleaner. > > Of the four quadrants created by those two axes, only one quadrant > does not work: Coreboot + neutralised ME Apologies if that was confusingly-worded. What I meant was this: | OEM BIOS | Coreboot | ---------------|----------|--------------| Stock ME | Works | Works | Neutralised ME | Works | Doesn't work | Best wishes, Sam

1 0

Lenovo Thinkpad X201: Coreboot incompatible with me_cleaner
by Sam Kuper 21 Mar '17

21 Mar '17

Dear all, I have been investigating booting my X201 on two axes: - Coreboot vs stock BIOS - Intel Management Engine left alone vs neutralised with me_cleaner. Of the four quadrants created by those two axes, only one quadrant does not work: Coreboot + neutralised ME: - Stock BIOS: boots fine. - Stock BIOS, neutralised: doesn't boot boots fine after a delay of <1 minute. - Coreboot with SeaBIOS payload, based on descriptor & ME regions from stock BIOS: boots fine. - Coreboot with SeaBIOS payload, based on descriptor & ME regions from neutralised BIOS: **doesn't boot**. See additional details here, including the output of intelmetool: https://github.com/corna/me_cleaner/issues/24 . Nicola Corna pointed out to me that adding a timeout at https://github.com/coreboot/coreboot/blob/master/src/northbridge/intel/neha… might solve this problem. (I guess the idea is that instead of waiting indefinitely for the ME to load, Coreboot should instead just wait for a defined amount of time and then plough on regardless.) I am not a C programmer, so am not competent to add that timeout. Please can anyone here provide a suitable patch for me to test, or failing that, point me to a similar timeout in another architecture's raminit that I might use as a starting point? Thanks, Sam

1 0

Re: [coreboot] Some errors by compiling romstage (I am a newbie)
by Maxim Gusev 21 Mar '17

21 Mar '17

Thanks a lot. Our compiler didn't support these options. Our developers deal with this issue. I think I will move in this matter soon. Regards, Maxim. -------- Original Message -------- Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie) Local Time: 3 Марта 2017 г. 9:22 вечера UTC Time: 3 Марта 2017 г. 18:22 From: adurbin(a)google.com To: Maxim Gusev <mail(a)maximgusev.com> coreboot(a)coreboot.org <coreboot(a)coreboot.org> On Fri, Mar 3, 2017 at 11:23 AM, Maxim Gusev <mail(a)maximgusev.com> wrote: > Yes, Aaron. I tried to figure it all out. > Some option doesn't works correctly. But the compiler and the linker are > supporting these options. > There is a log of "readelf -e imd_cbmem.o": http://pastebin.com/G5y36uU4 The above is indicating that -ffunction-sections and -fdata-sections is not working. All your symbols are in .text and .data so when you attempt to link it'll try to pull in everything which is why you are a getting the link error. > I also have a warning: cannot find entry symbol start; defaulting to > 0000000100187000 before undefined refference errors (but I think it doesn't > affect). > > I have also tried to compile the simple code by gcc: > http://pastebin.com/AYnxTjZx (the compilation string, code and the readelf > log). > I'm not doing something wrong, because I don't see sections with the name of > the function. There is the same with my compiler. > Maybe these options work only in conjunction with others? No. They work on all of our supported architectures as standalone options. > > If I will compile some sources of supported mainboard by coreboot, the > readelf log and sections will be good with appropriate title > (.text.function). > > Thanks a lot! > Regards, Maxim > > > > -------- Original Message -------- > Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie) > Local Time: 3 Марта 2017 г. 5:54 вечера > UTC Time: 3 Марта 2017 г. 14:54 > From: adurbin(a)google.com > To: Maxim Gusev <mail(a)maximgusev.com>, Coreboot <coreboot(a)coreboot.org> > > On Fri, Mar 3, 2017 at 8:37 AM, Maxim Gusev <mail(a)maximgusev.com> wrote: >> It doesn't work any case. >> As I understood these options remove the unreferenced symbols, but I have >> referenced symbols (the error is undefined reference). >> The definition of the used functions is in the file that is missing at >> this >> stage but all works on other archs. >> > > The symbol might be referenced in one function in that compilation > unit, but if the symbol of the function using the undefined symbols is > not referenced from any of the root symbols then it should be removed. > The fact that it isn't suggests -gc-sections isn't working *or* > -f(data|function)-sections isn't working. As I requested previously, > readelf -e from one of the romstage .o files would confirm the latter. > As it stands now I can't speculate as to what is happening because the > code you are working on isn't published so I can't do anything beyond > request the information I've already requested. > >> >> >> -------- Original Message -------- >> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie) >> Local Time: 3 Марта 2017 г. 4:54 дня >> UTC Time: 3 Марта 2017 г. 13:54 >> From: adurbin(a)google.com >> To: Maxim Gusev <mail(a)maximgusev.com>, Coreboot <coreboot(a)coreboot.org> >> >> On Fri, Mar 3, 2017 at 6:41 AM, Maxim Gusev <mail(a)maximgusev.com> wrote: >>> These options are supported. >>> But the option -fno-pie is not supported (Don’t produce a position >>> independent executable). >>> Is it the reason of the fault? >> >> >> I wouldn't think so. If you remove that option does it magically work? >> From the errors you showed -gc-sections along with -fdata-sections and >> -ffunction-sections would have removed the unreferenced symbols and >> not cause a link error. To prove that -f(data|function)-sections are >> working can you provide the readelf -e output from an intermediate .o >> file you compiled for romstage? >> >>> >>> >>> >>> -------- Original Message -------- >>> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie) >>> Local Time: 2 Марта 2017 г. 6:01 вечера >>> UTC Time: 2 Марта 2017 г. 15:01 >>> From: adurbin(a)google.com >>> To: Maxim Gusev <mail(a)maximgusev.com> >>> coreboot(a)coreboot.org <coreboot(a)coreboot.org> >>> >>> On Thu, Mar 2, 2017 at 8:33 AM, Maxim Gusev <mail(a)maximgusev.com> wrote: >>>> Hello, Aaron! >>>> >>>> I am compiling sourses of my arch e2k. >>>> I have compiled bootblock with my sources. There aren't my sources in >>>> other >>>> stages. I have create arch directory and mainboard directory where the >>>> sources are located. >>>> >>>> >>>> >>>> Log: >>>> >>>> /home/maxim/coreboot/util/crossgcc/xgcc/bin/linux-ld: warning: cannot >>>> find >>>> entry symbol start; defaulting to 0000000100187000 >>>> build/romstage/lib/imd_cbmem.o: In function `cbmem_add_bootmem': >>>> /home/maxim/coreboot/src/lib/imd_cbmem.c:287: undefined reference to >>>> `bootmem_add_range' >>>> build/romstage/lib/imd_cbmem.o: In function >>>> `cbmem_add_records_to_cbtable': >>>> /home/maxim/coreboot/src/lib/imd_cbmem.c:314: undefined reference to >>>> `lb_new_record' >>>> make: *** [build/cbfs/fallback/romstage.debug] Error 1 >>>> >>> >>> Does your arch's compiler support -ffuncation-sections and >>> -fdata-sections? As well as your linker supporting --gc-sections ? All >>> the architectures we support have those flags. See Makefile.inc which >>> provides those in CFLAGS_common and LDFLAGS_common. That support >>> allows us to not sprinkle #ifdef's all around in the code when the >>> same source file is compiled for different stages. >>> >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: [coreboot] Some errors by compiling romstage (I am a >>>> newbie) >>>> Local Time: 2 Марта 2017 г. 5:22 вечера >>>> UTC Time: 2 Марта 2017 г. 14:22 >>>> From: adurbin(a)google.com >>>> To: Maxim Gusev <mail(a)maximgusev.com> >>>> coreboot(a)coreboot.org <coreboot(a)coreboot.org> >>>> >>>> On Thu, Mar 2, 2017 at 7:24 AM, Maxim Gusev via coreboot >>>> <coreboot(a)coreboot.org> wrote: >>>>> Hi everbody! >>>>> >>>>> I have a question. Very hope for your help. >>>>> >>>>> When I am compiling the romstage there are 2 errors by the linker: >>>>> Undefined refference to 'bootmem_add_range' >>>>> Undefined refference to 'lb_new_record' in the imd_cbmem.c file (it is >>>>> included in src/lib/Makefile.inc romstage). >>>>> >>>>> The definitions of these functions are in lib/bootmem.c and >>>>> lib/coreboot_table.c accordingly. >>>>> But I can't see the inclusion of these files in romstage in >>>>> src/Makefile.inc >>>>> (only in ramstage): >>>>> ramstage-y += bootmem.c >>>>> ramstage-y += coreboot_table.c >>>>> >>>>> How to solve this problem? >>>>> The inclusion of these files produces a number of other errors, but >>>>> nowhere >>>>> in the code no one does it? Why only I am having this error. >>>> >>>> >>>> What board are you building? Are you working on local patches to your >>>> setup only? What does the build log indicate? >>>> >>>>> >>>>> In General, I don't even need these stages (romstage and ramstage) - I >>>>> want >>>>> to check the performance on real hardware the work of the bootblock, >>>>> but >>>>> the >>>>> toolchain requires me to compile other stages. And the error occurs >>>>> even >>>>> not >>>>> in my code, but my ignorance. >>>>> >>>>> Thanks a lot! >>>>> Regards, Maxim >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> coreboot mailing list: coreboot(a)coreboot.org >>>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>> >>>> >>> >>> >> >> > >

1 0

Re: [coreboot] ASUS F2A85-M ROM Stage Behavior
by Berj K Chilingirian 20 Mar '17

20 Mar '17

Hi Kyösti, Building coreboot with HUDSON_LEGACY_FREE disabled fixed it! Thank you for your help and fast reply! Best, Berj On Mar 20, 2017, at 7:27 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com<mailto:kyosti.malkki@gmail.com>> wrote: On Mon, Mar 20, 2017 at 11:51 AM, Berj K Chilingirian <berjc(a)mit.edu<mailto:berjc@mit.edu>> wrote: Dear Coreboot Community,I also have a serial port adapter (to USB) so that I can see the output of the coreboot process. Using this setup I am able to start up the machine with coreboot and get to the coreinfo screen (which I can then interact with). I am confused, however, by the output I am seeing from the boot process (attached). Specifically, it appears that the AmdInitReset procedure never exits, as shown below. coreboot-4.5-1349-g41dded3-dirty Mon Mar 20 03:04:09 UTC 2017 romstage starting... POST: 0x34 BSP Family_Model: 00610f21 cpu_init_detectedx = 00000000 POST: 0x37 AmdInitReset: Start *** !!AGESA cb_AgesaV0.0.0.1 *** FCH Reset Data Block Allocation: [0x0], Ptr = 0x004001e0 Fch OEM config in INIT RESET Done PCI: 00:14.4 bridge ctrl <- 0003 PCI: 00:14.4 cmd <- 00 PCI: 00:14.5 subsystem <- 1022/1410 PCI: 00:14.5 cmd <- 02 PCI: 00:15.0 bridge ctrl <- 0003 PCI: 00:15.0 cmd <- 00 PCI: 00:15.1 bridge ctrl <- 0003 … Hi I think this is just a case that the routing of serial port IO address range to LPC bus and further down to the UART is blocked as part of AmdInitReset. And we recover it as part of device resource assignment late in ramstage. Try build with HUDSON_LEGACY_FREE=n, should be visible "System is legacy free" choice in menuconfig. The help text there does not really match what it does and default setting seems incorrect for all the cases where board has super-io and serial port. Kyösti

1 0

Thinkpad X230 Thinklight always on
by Gert Menke 20 Mar '17

20 Mar '17

Hi, I just got my new backlit keyboard and ran into a slight annoyance. When I set the backlight option in nvram to "Both" or "Thinklight only", it works as expected: Fn+Space toggles the Thinklight or Turns on the keyboard backlight, then the Thinklight, then off. However, when I set it to backlight="Keyboard only", the Thinklight lights up on power on, and stays on forever. The keyboard backlight behaves as expected, though. Normally, the Thinklight lights up for about a second when the system is powered on. I suspect that coreboot tells the EC to disregard the Thinklight somewhere within this timepsan, so the EC never bothers to turn it off again. Does that make sense? I looked into h8.c and found the place where the relevant bit of EC configuration happens (it's bit 3 and 2 of address 0x01). But I have no idea how to fix this. A workaround for now is to set backlight="Both" and use "ectool -w 0x01 -z 0x05" in /etc/rc.local. Any ideas how to fix this properly? Cheers Gert

1 0

Re: [coreboot] Intel Leafhill/Apollolake wrong CBFS header address in coreboot.rom
by Aaron Durbin 20 Mar '17

20 Mar '17

On Sun, Mar 19, 2017 at 1:20 AM, Gailu Singh <gailu96(a)gmail.com> wrote: > Failing grub code > ------------------------------------------ > static void > init_cbfsdisk (void) > { > grub_uint32_t ptr; > struct cbfs_header *head; > > ptr = *(grub_uint32_t *) 0xfffffffc; > head = (struct cbfs_header *) (grub_addr_t) ptr; > grub_dprintf ("cbfs", "head=%p\n", head); > > /* coreboot current supports only ROMs <= 16 MiB. Bigger ROMs will > have problems as RCBA is 18 MiB below end of 32-bit typically, > so either memory map would have to be rearranged or we'd need to > support > reading ROMs through controller directly. > */ > if (ptr < 0xff000000 > || 0xffffffff - ptr < (grub_uint32_t) sizeof (*head) + 0xf > || !validate_head (head)) > return; > ------------------------------------------ > > On Sun, Mar 19, 2017 at 11:47 AM, Gailu Singh <gailu96(a)gmail.com> wrote: >> >> Hi Experts, >> >> On Intel Leafhill board grub fails to find cbfsdisk. We tried to debug and >> found that cbfs header address validation fails. >> >> According to >> https://github.com/mrnuke/coreboot/blob/master/documentation/cbfs.txt, >> "A pointer to the location of the header will be located at offset -4 from >> the end of the ROM. This translates to address 0xFFFFFFFC on a normal x86 >> system. The pointer will be to physical memory somewhere between - >> 0xFFFFB000 and 0xFFFFFFF0". >> >> >> We checked the coreboot.rom in hex editor and address in last 4 bytes is >> all ones (FFFFFFFF) as a result grub is not able to find cbfs header. >> >> >> We have earlier used coreboot on baytrail and in the coreboot.rom cbfs >> header address in last 4 byte was a valid pointer. >> This isn't going to fix your real problem but the value at 4 bytes below 4GiB is actually an offset from that location: https://review.coreboot.org:4430/cgit/coreboot.git/tree/src/lib/cbfs.c?id=r… >> >> What is the location grub can find cbfs header on this board? The following 2 files detail the mapping of the spi part. The 'COREBOOT' region is where cbfs resides and where you'd find that relative offset. However, you'd have to know where the FMAP is in order to parse things. src/mainboard/intel/leafhill/leafhill.16384.fmd src/mainboard/intel/leafhill/leafhill.8192.fmd The 'BIOS' region listed in the spi descriptor is what is memory mapped into the cpu address space under 4GiB. That does not mean when reading a SPI image like a file that the region has to be at the end of the file. There are linear translations you can do to go back and forth between CPU mmio addresses and SPI addresses. Again, this doesn't fix the current assumption in the code where it think it can just dereference an int32_t pointer with a value of 0xfffffffc. I don't know what the leaf hill descriptor indicates for the various regions, but if you moved COREBOOT to the very top of the fmd file (sans DEVICE_EXTENSION and UNUSED_HOLE) then you would be closer to the current assumptions. >> >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
27
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 March 2017