coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

Re: [coreboot] Porting coreboot to new board
by Zvi Vered 30 May '18

30 May '18

Hello Youness, Thank you very much for the detailed information ! Can you please tell what is the best starting point for a XEON board ? I think there are no "Intel® XEON® Processor E3-1505M v5" boards in last version of coreboot. Am I right ? Best regards, Zvika On Tue, May 29, 2018 at 9:15 PM Youness Alaoui < kakaroto(a)kakaroto.homelinux.net> wrote: > Hi, > > I suggest you read the wiki : > https://www.coreboot.org/Developer_Manual and > https://www.coreboot.org/Motherboard_Porting_Guide > I would also suggest maybe (optional) that you read my blog posts > about my own experience porting coreboot to a new motherboard : > https://puri.sm/posts/diving-back-into-coreboot-development/ > https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/ > https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/ > https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/ > https://puri.sm/posts/coreboot-on-the-librem-13-v2-part-1/ > https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2/ > > To answer your specific questions : It depends on your machine, is it > AMD or is it Intel? Is it Ivybridge or Broadwell or Skylake or > Apollolake, etc.. ? Does it have soldered RAM or does it use SODIMMs? > Depending on the CPU architecture, the CPU 'brand' and even the model > of the CPU itself, the port will be done very differently. You'd first > want to find a mainboard that is as close as your current one, and > start modifying that, there isn't "one mainboard to use as base" > because the code, files, etc.. are almost unique depending on the > CPU/northbridge/southbridge model, so use the closest one as your > base. > As far as I know, the file board_info.txt is just information about > the board, it's not getting used by coreboot, it's more of an > indication for developers. > As for the other files, it will depend once again on your board. I'd > say Kconfig and devicetree.cb are mandatory, the rest may or may not > be mandatory depending on your hardware. The cmos.layout for example > isn't mandatory, but you'd probably need it if you enable CMOS support > in your KConfig, The 'spd' files containing the RAM's SPD EEPROM > information are mandatory only if your board has soldered RAM (common > in laptops but not in desktops), but they are not needed (and actually > can't be provided) if the motherboard has SODIMM slots instead. So it > all depends. Your best bet is to look at what's there and see if you > need it or not and if you do, understand what it's for and what needs > to be changed in order to match your board. > Don't forget that before you get your board to boot with coreboot, you > will probably have to flash it and brick your board 100 times, so make > sure you have a backup of your original ROM copied somewhere safe and > that you have the hardware to re-program the SPI flash externally (and > test that it works), before you attempt to flash it. > Also, make sure you are patient, and ready to learn! > > Good luck! > Youness. > > > On Mon, May 28, 2018 at 10:31 PM, Zvi Vered <veredz72(a)gmail.com> wrote: > > Hello, > > > > I have to port coreboot to a new "Mainboard" not listed in menuconfig. > > Is there a basic "Mainboard" I should use as a starting point that will > be > > copied to my board ? > > > > The file board_info.txt contains few parameters. > > How can I know the meaning of each parameter and its possible values ? > > > > The board kontron/kt690 for example contains few files like: cmos.layout, > > devicetree.cb, etc > > Are all those files mandatory ? > > Is there a list of mandatory files or routines required in order to port > a > > board ? > > > > Your help is highly appreciated. > > Best regards, > > Zvika > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

AMD IMC open source firmware replacement
by Vincent Legoll 30 May '18

30 May '18

Hello, you can try with: lspci -vvvxxxx -- Vincent Legoll

1 0

Re: [coreboot] AMD IMC open source firmware replacement
by Rudolf Marek 30 May '18

30 May '18

Hi Mike, My firmware was just a proof of concept. It was never anything else. I was just able to run some program and that was all. Please make sure your IMC is active using info on wiki page. I suspect usually it wasnt used as laptop EC. Thanks Rudolf Dne 25.5.2018 v 14:31 Mike Banon napsal(a): > Good day Rudolf, > > This page [1] tells that you have developed a open source firmware > replacement of AMD IMC firmware and it is available under request. > Please tell, did it made to a coreboot? If not, 1) why? (stability > problems, or something else) 2) is the source code available somewhere > publicly? I have Lenovo G505S coreboot-supported laptop with AMD > Richland 15h CPU (A10-5750M) and it is probably using this IMC blob - > thats why I am curious > > [1] - https://www.coreboot.org/AMD_IMC > > Best regards, > Mike Banon >

2 1

Re: [coreboot] Who is still using a 1980's tty for coreboot development?
by Nico Huber 29 May '18

29 May '18

On 29.05.2018 14:23, Patrick Georgi wrote: > Am Fr., 25. Mai 2018 um 18:40 Uhr schrieb Nico Huber <nico.h(a)gmx.de>: >> o Set a hard limit around 100 chars (96 would be a nice number). >> o If a line doesn't contain a string literal, recommend a >> visible width <= 72 chars. > As Sam noted, it's hard to find tooling for that. > But even with 96 characters clang-format's output looks much better > than with 80. It's not that hard to grep. diff -u | grep '^+' | grep -v '^+[_a-zA-Z]\|"' | while read; do echo $REPLY | \ sed -e's/[[:space:]]*$[^[:space:]]*$[[:space:]]*/\1/' | \ wc -c done If anybody knows perl, that would probably be a two-line patch to checkpatch. > > One thing your transfer of the 72 char rule from continuous text to > code doesn't take into account is that in code, individual lines often > stand on their own. Consider the following block: It was really just based on the assumption that you don't have problems with line breaks at the first indentation level. If we'd really still have to break too many lines, we could also just use the same rule with 80 chars visible width. > > /* this function will fill the corresponding manufacturer */ > void smbios_fill_dimm_manufacturer_from_id(uint16_t mod_id, > struct smbios_type17 *t) I wasn't sure about function signatures... maybe no 72-char recommen- dation for them? Just let them run to the hard limit? (I've filtered lines starting with [_a-zA-Z] above, maybe that's enough?) We should probably define a rule for breaking signatures anyway. e.g. either align all parameters with the opening parent, or always break after it and align all parameters at one tab. The mix above makes my head ache. > { > switch (mod_id) { > case 0x2c80: > t->manufacturer = smbios_add_string(t->eos, "Crucial"); This fits on one line, even with our current rules. With a visible width of 55 chars, there would still be 17 chars space left. But that doesn't apply here anyway, because of the string-literal exception. > break; > > You'd never set a chapter in a book like this except maybe as an art > project (that I'd decline to read). > It's more readable after collapsing both the header and the add_string > call to a single line each (two "carriage returns" in the middle of a > statement less), despite passing the 72/80 character limit - except if > you're on an old-fashioned terminal where part of the line is missing > because it's too long now. > > If people write chapters full of documentation in comments, by all > means, let's limit that to a 72 character width (plus indentation for > "/* "). > Code formatters generally leave comments alone if they can help it, so > that requires a different tool if we want to enforce it. A simple script would suffice, imho. As long as the rules are kept simple. Nico

1 0

Re: [coreboot] Porting coreboot to new board
by Youness Alaoui 29 May '18

29 May '18

Hi, I suggest you read the wiki : https://www.coreboot.org/Developer_Manual and https://www.coreboot.org/Motherboard_Porting_Guide I would also suggest maybe (optional) that you read my blog posts about my own experience porting coreboot to a new motherboard : https://puri.sm/posts/diving-back-into-coreboot-development/ https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/ https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/ https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/ https://puri.sm/posts/coreboot-on-the-librem-13-v2-part-1/ https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2/ To answer your specific questions : It depends on your machine, is it AMD or is it Intel? Is it Ivybridge or Broadwell or Skylake or Apollolake, etc.. ? Does it have soldered RAM or does it use SODIMMs? Depending on the CPU architecture, the CPU 'brand' and even the model of the CPU itself, the port will be done very differently. You'd first want to find a mainboard that is as close as your current one, and start modifying that, there isn't "one mainboard to use as base" because the code, files, etc.. are almost unique depending on the CPU/northbridge/southbridge model, so use the closest one as your base. As far as I know, the file board_info.txt is just information about the board, it's not getting used by coreboot, it's more of an indication for developers. As for the other files, it will depend once again on your board. I'd say Kconfig and devicetree.cb are mandatory, the rest may or may not be mandatory depending on your hardware. The cmos.layout for example isn't mandatory, but you'd probably need it if you enable CMOS support in your KConfig, The 'spd' files containing the RAM's SPD EEPROM information are mandatory only if your board has soldered RAM (common in laptops but not in desktops), but they are not needed (and actually can't be provided) if the motherboard has SODIMM slots instead. So it all depends. Your best bet is to look at what's there and see if you need it or not and if you do, understand what it's for and what needs to be changed in order to match your board. Don't forget that before you get your board to boot with coreboot, you will probably have to flash it and brick your board 100 times, so make sure you have a backup of your original ROM copied somewhere safe and that you have the hardware to re-program the SPI flash externally (and test that it works), before you attempt to flash it. Also, make sure you are patient, and ready to learn! Good luck! Youness. On Mon, May 28, 2018 at 10:31 PM, Zvi Vered <veredz72(a)gmail.com> wrote: > Hello, > > I have to port coreboot to a new "Mainboard" not listed in menuconfig. > Is there a basic "Mainboard" I should use as a starting point that will be > copied to my board ? > > The file board_info.txt contains few parameters. > How can I know the meaning of each parameter and its possible values ? > > The board kontron/kt690 for example contains few files like: cmos.layout, > devicetree.cb, etc > Are all those files mandatory ? > Is there a list of mandatory files or routines required in order to port a > board ? > > Your help is highly appreciated. > Best regards, > Zvika > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Enabling SpeedStep for all Denverton SoC variants
by Sumo 29 May '18

29 May '18

Hi, Today denverton_core_init() is enabling the Intel SpeedStep only if turbo mode is available. As a result, the SpeedStep is not enable for the C3558 variant (and others). Any clues of why it was implemented this way? I think it is safe to remove the "if (get_turbo_state() == TURBO_ENABLED)" test and always enable the SpeedStep technology. Thanks, Sumo

1 0

Re: [coreboot] Who is still using a 1980's tty for coreboot development?
by Nico Huber 29 May '18

29 May '18

On 25.05.2018 10:15, Patrick Georgi via coreboot wrote: > That is, who would unbearably suffer from 132 characters gper line of code? Humans. Code quality. Eyes get too tired too fast. The cost of our eyes' "carriage return" grows over-linear with the line length. Although, that's hard to measure, I'm sure 132 chars would have a negative impact on review quality. The cost of comparing two views side-by-side increases too, with the distance between them. A general rule from printed text is that you should keep the column width below 70 chars on average. You can't apply that directly to fixed- width fonts and, obviously, code lines are not like running text (ide- ally a statement ends before hitting any line break). But, in every pro- ject that allows longer lines, I've seen people starting to use the extra space also for comments. And comments at 132 chars? that would really be unbearable. IMHO, the problem with 80 chars is that it is just a little too nar- row for code. It's a good length at function scope but even only two additional levels of indentation, and you have only 56 chars left. So I generally agree to lift the limit, but not too high and not uncon- ditionally. Looking at what has been written in this thread so far, I see three major cases that people care about: 1. Function signatures, 2. Code lines and 3. Code lines containing string literals[1]. Let's assume 72 chars of visible width (line length minus the inden- tation) is enough for code lines. If we say two additional indentation levels are always reasonable (a third might be too, here and there) we would be at 96 chars. So I would compromise as follows: o Set a hard limit around 100 chars (96 would be a nice number). o If a line doesn't contain a string literal, recommend a visible width <= 72 chars. Nico [1] I think we should treat the latter two separately because you can easily argue that lines with a string literal might get too long but if you apply the same rules to regular code, you'll get all the crappy stuff (too many levels of indentation, unnecessary long, less distinctive identifiers etc.).

5 4

Porting coreboot to new board
by Zvi Vered 29 May '18

29 May '18

Hello, I have to port coreboot to a new "Mainboard" not listed in menuconfig. Is there a basic "Mainboard" I should use as a starting point that will be copied to my board ? The file board_info.txt contains few parameters. How can I know the meaning of each parameter and its possible values ? The board kontron/kt690 for example contains few files like: cmos.layout, devicetree.cb, etc Are all those files mandatory ? Is there a list of mandatory files or routines required in order to port a board ? Your help is highly appreciated. Best regards, Zvika

1 0

Re: [coreboot] flashrom on osx ...
by David Hendricks 29 May '18

29 May '18

Jean-Marie Verdun sent a patch which I've uploaded here: https://review.coreboot.org/c/directhw/+/26655 I couldn't get the .dmg to install on High Sierra, though. Perhaps someone with experience developing on Mac can take a look. On Fri, May 11, 2018 at 11:45 AM, ron minnich <rminnich(a)gmail.com> wrote: > not late enough, sadly, and why the heck won't this build from github repo > ... uses packagemanager which is no longer a thing. > > On Fri, May 11, 2018 at 11:07 AM Alberto Bursi <alberto.bursi(a)outlook.it> > wrote: > >> >> On 11/05/2018 19:42, ron minnich wrote: >> > if I just want to use a dediprog sf100 what's the best way to build >> > flashrom on osx? >> > >> > besides "throw the macbook in the trash and get a real computer" :-) >> > >> > ron >> > >> > >> >> There is "homebrew" package manager for OSX/MacOS, see here >> https://brew.sh/ >> >> They have latest flashrom https://formulae.brew.sh/formula/flashrom >> among a big list of other commandline stuff you might find useful. >> >> -Alberto >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?
by Ivan Ivanov 28 May '18

28 May '18

Maybe it just AMD's microcode versioning got messed up and this is indeed the latest microcode despite its' lower number, but the only way to check it - is to test both microcodes for their degree of vulnerability to the Spectres. It does not make much sense to release an outdated microcode, assuming its' not an accidental mistake by AMD - so I hope that AMD guy would notice your messages Ivan 2018-05-27 13:17 GMT+03:00 Mike Banon <mikebdp2(a)gmail.com>: > Hi Rudolf, > > Please could you try contacting this AMD person again, regarding the > problems with this recent microcode update? Because it looks like he > noticed your messages since he at least tried to fix, but haven't > noticed mine for some reason (regarding the lack of updated 16h > microcode; why only 15h and 17h are being updated while 16h is > forgotten - I could not understand, and this is relevant since there > are some coreboot-supporting 16h boards) > > Best regards, > Mike Banon > > On Sat, May 26, 2018 at 7:13 PM, Rudolf Marek <r.marek(a)assembler.cz> wrote: >> Hi again, >> >> Dne 23.5.2018 v 21:52 Rudolf Marek napsal(a): >>> For some reason this firmware update deletes microcode for Trinity CPUs, I tried to contact the person who commit this >>> without any luck. As I have previously written the github page has even newer microcode. >> >> This was fixed, however the old (same) microcode was provided again. >> >> Thanks >> Rudolf >> >> >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

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 May 2018