Re: [coreboot] call on AMD to release src+specs+datasheets for ryzen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Ron, On 03/03/17 23:26, ron minnich wrote: > We could target putting a meeting with AMD together at the Denver > meeting or the one in the fall. ron Yes, this is what I'm banking on. If coreboot can arrange that, and get AMD in its meetings then that would be great. That, plus raising public awareness and showing demand from the public. That's what I'm trying to do here, but we need people in coreboot to help out since coreboot has better relations with AMD that libreboot does. - -- Leah Rowe Libreboot developer Use free software. Free as in freedom. https://en.wikipedia.org/wiki/Free_software Use a free operating system, GNU+Linux. https://libreboot.org/docs/distros/ Or BSD: https://libreboot.org/docs/bsd/ Use a free BIOS. https://libreboot.org/ Support computer user freedom. https://peers.community/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: https://minifree.org/ -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAli6IjMACgkQ/0W3TPnR z5Tt8wf+KjSBw+Ghkq4szfcafAhlhhctrZQaMdVq8of4kK/dgDTqIuTHTzyad7Ab VFRsBeiEHRQGqp57EUZkfc5zKAdxuSZcSQvZx8bGpnSUnej83IXQytA7YurTpvBo aEInxqgh8m27QBFgu71OJvnZPP8TuN9qbTlZIHkRWr5uxR73OwmbubqUOaf4MHw5 yPMSMWj3qEAstKiKJy/xrc9RyaiGqGJi+sO5HIUQM6N24QGTWdMu1cLKya5ilnWd GCoWT53AsD2cammg5bNamOPoCqvhsMxUbMOLGsp9q+vlkstBkpgP7JzAFdq8BHjB GIDPrbtFOAt58y/b6HvDnblKRcyfJQ== =ajuw -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Reminder: The maiing list vs forum poll closes in just under 24 hours.
Wasn't Martin suggesting to add the results to the poll anonymously, without revealing the originator's identity? Come on, guys, Google is a major contributor and benefactor of coreboot, give it some slack! ;) --vb On Fri, Mar 3, 2017 at 2:38 PM, wrote: > I would also really prefer a non-google poll. > Taiidan wrote "I also do not like contributing to machine learning or > advertising databases." > > You wrote "If people want to just email me responses, I can fill them into > the form on their behalf." > > Thats exactly what he didnt want. He didnt want to feed skynet. Of course > he also didnt want that you feed it for him with the data he provide to > anyone. > > Would be really great if some free software running on the coreboot > servers is been used for coreboot polls. > > > 3. Mar 2017 20:27 by gauml...@gmail.com: > > > Hey Talidan, > If someone wants to suggest a different site for doing polls, I'd be > glad to take a look, but I'm probably not going to change away from Google > forms unless we find something comparable. It's easy to make the forms, > easy to take the poll, and easy to collect, analyze, and view the data. > > As a compromise, for future polls that I send out, I can send out a list > of the questions out to the mailing list as well. If people want to just > email me responses, I can fill them into the form on their behalf. That > way you don't have to deal with the site, but we can still use something > that's easy to work with. > > Would that work for you? > > Martin > > On Fri, Mar 3, 2017 at 3:03 AM, taii...@gmx.com wrote: > >> On 03/03/2017 01:45 AM, Martin Roth wrote: >> >> As brought up in the previous coreboot community meeting, the coreboot >>> project >>> is discussing the idea of switching from the mailing list to a forum. >>> This >>> idea did not originate with the coreboot leadership, but from a request >>> by >>> members of the community. >>> >>> I know many people have some strong feelings about this one way or the >>> other. Right now we're just collecting data on how people feel about it, >>> and looking for suggestions on ways to either improve the mailing list or >>> set up a well-run forum. >>> >>> Here's the poll about the switch. I will close the poll tomorrow, >>> March 3, 2017. >>> >>> https://goo.gl/9Hd569 >>> >>> Martin >>> >>> Thank you for reminding me. >> >> For future reference I would really prefer a non-google poll - the use of >> google services requires javascript and I don't like enabling javascript >> due to how easily exploitable it is. I also do not like contributing to >> machine learning or advertising databases. >> >> As I have said before, most forum software discriminates against people >> who do not wish to run a window manager and of course javascript which is >> why I think things are fine as they are. >> > > > -- > coreboot mailing list: coreboot@coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Reminder: The maiing list vs forum poll closes in just under 24 hours.
On 03/03/2017 05:38 PM, i1w5d7gf38...@tutanota.com wrote: I would also really prefer a non-google poll. Taiidan wrote "I also do not like contributing to machine learning or advertising databases." You wrote "If people want to just email me responses, I can fill them into the form on their behalf." Thats exactly what he didnt want. He didnt want to feed skynet. Of course he also didnt want that you feed it for him with the data he provide to anyone. Would be really great if some free software running on the coreboot servers is been used for coreboot polls. I appreciate martins offer but yeah that would be even better. An open source community shouldn't be using closed source stuff. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] call on AMD to release src+specs+datasheets for ryzen
On 03/03/2017 02:25 PM, Leah Rowe wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, https://libreboot.org/amd-libre/ We call on coreboot to join us in our campaign to convince AMD to start cooperating with the libre hardware community again. Are there people in coreboot already doing this? - -- Leah Rowe Libreboot developer Use free software. Free as in freedom. https://en.wikipedia.org/wiki/Free_software Use a free operating system, GNU+Linux. https://libreboot.org/docs/distros/ Or BSD: https://libreboot.org/docs/bsd/ Use a free BIOS. https://libreboot.org/ Support computer user freedom. https://peers.community/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: https://minifree.org/ -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAli5wy0ACgkQ/0W3TPnR z5SjBQf+NCfTdd5WPPW9KDAD/UtvddNtjKrtwQz/50wR2mxuwqoiESq2M4pPk9C4 17zVqTPbQYESk5+smT4h3fnqVG5HvqhDJHpwEchq4x/PO0ZgsEGbDNpjt9FjOv6M 82U/RT33wW/X3KvPKhywYNOp5qhYzUN7DL4275cgikKsqLk9izbRxUE6lgTbcSTU 3mjTlRfyCr46EKEsB+c+qmbWAhaIrnu/6Vuv3LHZfO1iFEOQKmnZEvoNNnEGMPKY JQF/B3kuf3jcJ9yq4nhIQO9pBEAB2CuuYPn4XZZArHJS1OZX7ILMO2zj2o8favDf 5SWR2o2zEui3LZkwj8gwCPz3VF4Rag== =3Ke8 -END PGP SIGNATURE- Definitely - No matter what anyone thinks about the probability of this happening it is still very important that we show them how much we care. Of course they also must release the signing keys as well afaik, or we would be stuck at a tivo style not really open source impasse. Nobody has mentioned this fact in that thread. I can't understand as to why intel/amd after decades and decades of computing suddenly add a black box supervisor processor to every product line (not just the business models) that can't be removed or modified. All we are asking for is a way to shut it off but for some reason they believe that is unreasonable. One of the side issues is also the lack of open source GPU firmware and of course the signing keys for that as well. It is incredibly depressing that every commodity grade computer is moving to the locked down model, we can only hope that POWER will not follow suit. On 03/03/2017 06:26 PM, ron minnich wrote: So, first, I admire and agree with your enthusiasm for making this happen. I hope it works. That said, having gotten vendors to break open this kind of information, with a number of vendors a number of times, and having both failed and succeeded, my experience is that a broadcast call like this is probably the least effective approach. So I'd rather not have the "coreboot community" join in this sort of call, for the simple reason that I would rather see us place our efforts on something that's likely to be effective. That involves individual members of our community spending lots of time locating the right people in the right organizations, getting them into a single room, talking to them, drafting documents, and getting them to agree to some sort of joint communique. It's time consuming and boring but it's how the jobs gets done. But, that work naturally occurs behind closed doors, not via web pages. We could target putting a meeting with AMD together at the Denver meeting or the one in the fall. ron Yeah I agree, that would be what could really make something happen. It is like the difference between getting a job interview with an HR lackey and an actual technical person. Intel would never be willing to do this, but AMD? slightly possible. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] call on AMD to release src+specs+datasheets for ryzen
So, first, I admire and agree with your enthusiasm for making this happen. I hope it works. That said, having gotten vendors to break open this kind of information, with a number of vendors a number of times, and having both failed and succeeded, my experience is that a broadcast call like this is probably the least effective approach. So I'd rather not have the "coreboot community" join in this sort of call, for the simple reason that I would rather see us place our efforts on something that's likely to be effective. That involves individual members of our community spending lots of time locating the right people in the right organizations, getting them into a single room, talking to them, drafting documents, and getting them to agree to some sort of joint communique. It's time consuming and boring but it's how the jobs gets done. But, that work naturally occurs behind closed doors, not via web pages. We could target putting a meeting with AMD together at the Denver meeting or the one in the fall. ron -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Reminder: The maiing list vs forum poll closes in just under 24 hours.
I would also really prefer a non-google poll. Taiidan wrote "I also do not like contributing to machine learning or advertising databases." You wrote "If people want to just email me responses, I can fill them into the form on their behalf." Thats exactly what he didnt want. He didnt want to feed skynet. Of course he also didnt want that you feed it for him with the data he provide to anyone. Would be really great if some free software running on the coreboot servers is been used for coreboot polls. 3. Mar 2017 20:27 by gauml...@gmail.com: > Hey Talidan,> If someone wants to suggest a different site for doing polls, > I'd be glad to take a look, but I'm probably not going to change away from > Google forms unless we find something comparable. It's easy to make the > forms, easy to take the poll, and easy to collect, analyze, and view the data. > As a compromise, for future polls that I send out, I can send out a list of > the questions out to the mailing list as well. If people want to just email > me responses, I can fill them into the form on their behalf. That way you > don't have to deal with the site, but we can still use something that's easy > to work with. > Would that work for you? > Martin > On Fri, Mar 3, 2017 at 3:03 AM, > taii...@gmx.com> <> taii...@gmx.com> > > wrote: > >> On 03/03/2017 01:45 AM, Martin Roth wrote: >> >> >>> As brought up in the previous coreboot community meeting, the coreboot >>> project >>> is discussing the idea of switching from the mailing list to a forum. This >>> idea did not originate with the coreboot leadership, but from a request by >>> members of the community. >>> >>> I know many people have some strong feelings about this one way or the >>> other. Right now we're just collecting data on how people feel about it, >>> and looking for suggestions on ways to either improve the mailing list or >>> set up a well-run forum. >>> >>> Here's the poll about the switch. I will close the poll tomorrow, >>> March 3, 2017. >>> >>> https://goo.gl/9Hd569 >>> >>> Martin >>> >>> >> Thank you for reminding me. >> >> For future reference I would really prefer a non-google poll - the use of >> google services requires javascript and I don't like enabling javascript due >> to how easily exploitable it is. I also do not like contributing to machine >> learning or advertising databases. >> >> As I have said before, most forum software discriminates against people who >> do not wish to run a window manager and of course javascript which is why I >> think things are fine as they are. >> > >-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot only takes 260 ms on Lenovo 430s!
Dear coreboot folks, Kamyl pushed the board status for the Lenovo 430s, and I am excited looking at the time stamps! Gone in 260 ms! Awesome. (RAM training results are cached.) ``` $ more lenovo/t430s/4.5-1105-gd55ea7b/2017-03-03T18_41_49Z/coreboot_timestamps.txt 21 entries total: 0:1st timestamp 1,809 1:start of rom stage59,610 (57,800) 2:before ram initialization 60,859 (1,249) 3:after ram initialization 74,194 (13,334) 4:end of romstage 75,740 (1,546) 8:starting to load ramstage 77,081 (1,341) 15:starting LZMA decompress (ignore for x86) 77,298 (216) 16:finished LZMA decompress (ignore for x86) 94,003 (16,704) 9:finished loading ramstage 94,214 (211) 10:start of ramstage 94,296 (82) 30:device enumeration94,299 (3) 40:device configuration 98,818 (4,519) 50:device enable 100,528 (1,710) 60:device initialization 100,661 (133) 70:device setup done 223,845 (123,183) 75:cbmem post223,846 (1) 80:write tables 223,847 (1) 85:finalize chips245,080 (21,232) 90:load payload 245,081 (1) 15:starting LZMA decompress (ignore for x86) 245,192 (110) 16:finished LZMA decompress (ignore for x86) 262,007 (16,815) 99:selfboot jump 262,024 (17) Total Time: 260,208 ``` So a big thank you to everyone involved in making that possible. phcoder, the Googlers, siro, lynxis, and many, many more. This is great work! Thanks, Paul PS: Even the SMBIOS tables contain the embedded controller strings, which takes over 100 ms on the Lenovo X60 for example. ``` thinkpad_acpi: ThinkPad BIOS CBET4000 4.5-1105-gd55ea7b, EC G7HT29WW-3.22 ``` [1] https://review.coreboot.org/cgit/board-status.git/commit/?id=a2a34b4c7 signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2017 04:14 PM, Paul Menzel via coreboot wrote: > Dear Daniel, > > > Am Freitag, den 03.03.2017, 10:52 +0100 schrieb Daniel Kulesz: > >>> I think most of the time is spent in RAM initialization. >>> >>>1. Do board owners with similar amount of memory (independent of the >>> board) have similar numbers? >>>2. What are the ways to improve that? Is it possible? For example, can >>> the modules be probed in parallel (if that isn?t done already)? >> >> Regarding 1: I am running 128GB in 8GB modules (LRDIMMs) and >> experiencing a similar issue. With just two UDIMMs, the boot times >> are *much* faster. > > That’s good to hear. Do you have concrete numbers? > >> Also, the vendor BIOS is faster from the time you press the poweron >> button to the time the monitor gets a signal. > > I believe that’s a design decision in coreboot, that the display can > only be initialized after RAM has been initialized. The vendor firmware > seems to be able to do it beforehand. (If I am wrong, the vendor > firmware is really fast in configuring the memory.) The vendor firmware starts up the display while memory is still being configured. As far as I can tell, the graphical ASUS logo is loaded as part of the proprietary BIOS's romstage-equivalent component, while RAM is not initialized until that logo is removed from the display. You can test this for yourself by noting that the keyboard numlock will not respond while that logo is displayed, whereas it does respond afterward. The proprietary BIOS likely uses a proprietary variant of the open AGESA code in the coreboot tree, and I see no reason its RAM initialization will be any faster (or slower) than the native RAM initialization currently used for the KGPE-D16 as both are based on the same BKDG and use the same general algorithms. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYuezkAAoJEK+E3vEXDOFbDXkH/Aw+IORZhJdncXFVEn+0Go8s lRGuYJzcx28XmVLXDYfZACGdAdVRWnc0AYFGUeqJm1oCMoxpKa5zqVfdIMf+2XU6 vo3Qm6nkzAUxp61s2niaOoAwN6G11XsFokeoFDAL+2m9sxxxVgwBiiazQNlUrusu 4S6Z6H9aooJPAEtj/E/HhovJGCb9DCZEyHkT4V+kZc0I0i3i2khktNcgenlkVefU aNeZQ3aabJ3LMfJLbBEDFHlrFHbjRjU7aDeosTztnR0w+AVa2w6ZbUd5D6Pq8h1X un7sD+AsBpvKjnTq00d89OD/2glmq4cglGKW+vlNg3xzsiz3eXjGmmRlJKZsTSI= =Q6T1 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?
Dear Daniel, Am Freitag, den 03.03.2017, 10:52 +0100 schrieb Daniel Kulesz: > > I think most of the time is spent in RAM initialization. > > > >1. Do board owners with similar amount of memory (independent of the > > board) have similar numbers? > >2. What are the ways to improve that? Is it possible? For example, can > > the modules be probed in parallel (if that isn?t done already)? > > Regarding 1: I am running 128GB in 8GB modules (LRDIMMs) and > experiencing a similar issue. With just two UDIMMs, the boot times > are *much* faster. That’s good to hear. Do you have concrete numbers? > Also, the vendor BIOS is faster from the time you press the poweron > button to the time the monitor gets a signal. I believe that’s a design decision in coreboot, that the display can only be initialized after RAM has been initialized. The vendor firmware seems to be able to do it beforehand. (If I am wrong, the vendor firmware is really fast in configuring the memory.) Thanks, Paul PS: Please note, your messages is not threaded correctly, as the mail header fields *In-Reply-To* and References are not set. signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Reminder: The maiing list vs forum poll closes in just under 24 hours.
Hey Talidan, If someone wants to suggest a different site for doing polls, I'd be glad to take a look, but I'm probably not going to change away from Google forms unless we find something comparable. It's easy to make the forms, easy to take the poll, and easy to collect, analyze, and view the data. As a compromise, for future polls that I send out, I can send out a list of the questions out to the mailing list as well. If people want to just email me responses, I can fill them into the form on their behalf. That way you don't have to deal with the site, but we can still use something that's easy to work with. Would that work for you? Martin On Fri, Mar 3, 2017 at 3:03 AM, taii...@gmx.com wrote: > On 03/03/2017 01:45 AM, Martin Roth wrote: > > As brought up in the previous coreboot community meeting, the coreboot >> project >> is discussing the idea of switching from the mailing list to a forum. >> This >> idea did not originate with the coreboot leadership, but from a request by >> members of the community. >> >> I know many people have some strong feelings about this one way or the >> other. Right now we're just collecting data on how people feel about it, >> and looking for suggestions on ways to either improve the mailing list or >> set up a well-run forum. >> >> Here's the poll about the switch. I will close the poll tomorrow, >> March 3, 2017. >> >> https://goo.gl/9Hd569 >> >> Martin >> >> Thank you for reminding me. > > For future reference I would really prefer a non-google poll - the use of > google services requires javascript and I don't like enabling javascript > due to how easily exploitable it is. I also do not like contributing to > machine learning or advertising databases. > > As I have said before, most forum software discriminates against people > who do not wish to run a window manager and of course javascript which is > why I think things are fine as they are. > -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Reminder: The maiing list vs forum poll closes in just under 24 hours.
I don't want to skew the poll by releasing the data before it closes. Martin On Fri, Mar 3, 2017 at 12:22 AM, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > Hello Martin, > > The current/up to date poll results would be also nice to have... I > guess, I am asking for too much, don't I? ;-) > > (anyway, it is too late) > > Zoran > ___ > > On 3/3/17, Martin Roth wrote: > > As brought up in the previous coreboot community meeting, the coreboot > > project > > is discussing the idea of switching from the mailing list to a forum. > This > > idea did not originate with the coreboot leadership, but from a request > by > > members of the community. > > > > I know many people have some strong feelings about this one way or the > > other. Right now we're just collecting data on how people feel about it, > > and looking for suggestions on ways to either improve the mailing list or > > set up a well-run forum. > > > > Here's the poll about the switch. I will close the poll tomorrow, > > March 3, 2017. > > > > https://goo.gl/9Hd569 > > > > Martin > > > > -- > > coreboot mailing list: coreboot@coreboot.org > > https://www.coreboot.org/mailman/listinfo/coreboot > > > -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] call on AMD to release src+specs+datasheets for ryzen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, https://libreboot.org/amd-libre/ We call on coreboot to join us in our campaign to convince AMD to start cooperating with the libre hardware community again. Are there people in coreboot already doing this? - -- Leah Rowe Libreboot developer Use free software. Free as in freedom. https://en.wikipedia.org/wiki/Free_software Use a free operating system, GNU+Linux. https://libreboot.org/docs/distros/ Or BSD: https://libreboot.org/docs/bsd/ Use a free BIOS. https://libreboot.org/ Support computer user freedom. https://peers.community/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: https://minifree.org/ -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAli5wy0ACgkQ/0W3TPnR z5SjBQf+NCfTdd5WPPW9KDAD/UtvddNtjKrtwQz/50wR2mxuwqoiESq2M4pPk9C4 17zVqTPbQYESk5+smT4h3fnqVG5HvqhDJHpwEchq4x/PO0ZgsEGbDNpjt9FjOv6M 82U/RT33wW/X3KvPKhywYNOp5qhYzUN7DL4275cgikKsqLk9izbRxUE6lgTbcSTU 3mjTlRfyCr46EKEsB+c+qmbWAhaIrnu/6Vuv3LHZfO1iFEOQKmnZEvoNNnEGMPKY JQF/B3kuf3jcJ9yq4nhIQO9pBEAB2CuuYPn4XZZArHJS1OZX7ILMO2zj2o8favDf 5SWR2o2zEui3LZkwj8gwCPz3VF4Rag== =3Ke8 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Some errors by compiling romstage (I am a newbie)
On Fri, Mar 3, 2017 at 11:23 AM, Maxim Gusev 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 > 000100187000 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: adur...@google.com > To: Maxim Gusev , Coreboot > > On Fri, Mar 3, 2017 at 8:37 AM, Maxim Gusev 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: adur...@google.com >> To: Maxim Gusev , Coreboot >> >> On Fri, Mar 3, 2017 at 6:41 AM, Maxim Gusev 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: adur...@google.com >>> To: Maxim Gusev >>> coreboot@coreboot.org >>> >>> On Thu, Mar 2, 2017 at 8:33 AM, Maxim Gusev 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 000100187000 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. >>>
Re: [coreboot] Some errors by compiling romstage (I am a newbie)
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 I also have a warning: cannot find entry symbol start; defaulting to 000100187000 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? 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: adur...@google.com To: Maxim Gusev , Coreboot On Fri, Mar 3, 2017 at 8:37 AM, Maxim Gusev 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: adur...@google.com > To: Maxim Gusev , Coreboot > > On Fri, Mar 3, 2017 at 6:41 AM, Maxim Gusev 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: adur...@google.com >> To: Maxim Gusev >> coreboot@coreboot.org >> >> On Thu, Mar 2, 2017 at 8:33 AM, Maxim Gusev 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 000100187000 >>> 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: adur...@google.com >>> To: Maxim Gusev >>> coreboot@coreboot.org >>> >>> On Thu, Mar 2, 2017 at 7:24 AM, Maxim Gusev via coreboot >>> 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 r
[coreboot] PCI BAR attacks on SMM at RECon Brussels
Intel ATR presented "Baring the system: New vulnerabilities in SMM of coreboot and UEFI based systems" at RECon Brussels last month: https://recon.cx/2017/brussels/talks/baring_the_system.html The slides are online now: http://www.intelsecurity.com/advanced-threat-research/content/data/REConBrussels2017_BARing_the_system.pdf Their first conclusion is that "the root cause is that firmware assumes hardware is trusted". This seems to be less and less of a valid assumption. -- Trammell -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Inteal Leafhill : Linux SATA driver fails when used with coreboot+grub
Hi Experts, I am trying to boot Linux 4.1 with coreboot and grub but SATA drive fails with error "ata1: SATA link down (SStatus 4 SControl 300)". It is interesting that GRUB2 can use the SATA drive without issue and able to load kernel from SATA disk. If I use same SATA Drive with Coreboot+UEFI payload then Linux driver just works fine and I am able to boot linux. Any Idea What might be going wrong with Linux Driver. Does it expect something from BIOS/Coreboot that is not fulfilled Linux boot logs: - Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Initializing cgroup subsys cpuacct Linux version 4.1.21-WR8.0.0.11_standard (vgahlaut@ubuntu) (gcc version 5.2.0 (Wind River Linux 5.2.0-8.0-intel-apollolake-i-64) ) #1 SMP PREEMPT Mon Feb 6 18:38:46 PST 2017 Command line: BOOT_IMAGE=(ahci0,msdos1)/boot/bzImage root=/dev/sda1 rootdelay=10 console=ttyS2,115200 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Centaur CentaurHauls e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0fff] type 16 BIOS-e820: [mem 0x1000-0x0009] usable BIOS-e820: [mem 0x000a-0x000f] reserved BIOS-e820: [mem 0x0010-0x0fff] usable BIOS-e820: [mem 0x1000-0x12150fff] reserved BIOS-e820: [mem 0x12151000-0x7a64] usable BIOS-e820: [mem 0x7a65-0x7aff] type 16 BIOS-e820: [mem 0x7b00-0x7fff] reserved BIOS-e820: [mem 0xd000-0x] reserved BIOS-e820: [mem 0x0001-0x00017fff] usable NX (Execute Disable) protection: active SMBIOS 2.7 present. e820: last_pfn = 0x18 max_arch_pfn = 0x4 PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC e820: last_pfn = 0x7a650 max_arch_pfn = 0x4 Scanning 1 areas for low memory corruption Using GB pages for direct mapping init_memory_mapping: [mem 0x-0x000f] init_memory_mapping: [mem 0x17fe0-0x17fff] init_memory_mapping: [mem 0x16000-0x17fdf] init_memory_mapping: [mem 0x0010-0x0fff] init_memory_mapping: [mem 0x12151000-0x7a64] init_memory_mapping: [mem 0x1-0x15fff] ACPI: Early table checksum verification disabled ACPI: RSDP 0x000F 24 (v02 CORE ) ACPI: XSDT 0x7A6690E0 5C (v01 CORE COREBOOT CORE ) ACPI: FACP 0x7A66BA60 00010C (v05 CORE COREBOOT CORE 0001) ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aEventBlock: 32/16 (20150410/tbfadt-623) ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aEventBlock: 16, using default 32 (20150410/tbfadt-704) ACPI: DSDT 0x7A669280 0027D8 (v05 COREv4 COREBOOT 20110725 INTL 20160831) ACPI: FACS 0x7A669240 40 ACPI: FACS 0x7A669240 40 ACPI: SSDT 0x7A66BB70 000774 (v02 CORE COREBOOT 002A CORE 002A) ACPI: MCFG 0x7A66C2F0 3C (v01 CORE COREBOOT CORE ) ACPI: TCPA 0x7A66C330 32 (v02 CORE COREBOOT CORE ) ACPI: TPM2 0x7A66C370 34 (v04 CORE COREBOOT CORE ) ACPI: APIC 0x7A66C3B0 6C (v01 CORE COREBOOT CORE ) ACPI: HPET 0x7A66C420 38 (v01 CORE COREBOOT CORE ) Zone ranges: DMA [mem 0x1000-0x00ff] DMA32[mem 0x0100-0x] Normal [mem 0x0001-0x00017fff] Movable zone start for each node Early memory node ranges node 0: [mem 0x1000-0x0009] node 0: [mem 0x0010-0x0fff] node 0: [mem 0x12151000-0x7a64] node 0: [mem 0x0001-0x00017fff] Initmem setup node 0 [mem 0x1000-0x00017fff] ACPI: PM-Timer IO Port: 0x408 IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-119 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8086a701 base: 0xfed0 smpboot: Allowing 4 CPUs, 0 hotplug CPUs PM: Registered nosave memory: [mem 0x-0x0fff] PM: Registered nosave memory: [mem 0x000a-0x000f] PM: Registered nosave memory: [mem 0x1000-0x12150fff] PM: Registered nosave memory: [mem 0x7a65-0x7aff] PM: Registered nosave memory: [mem 0x7b00-0x7fff] PM: Registered nosave memory: [mem 0x8000-0xcfff] PM: Registered nosave memory: [mem 0xd000-0x] e820: [mem 0x8000-0xcfff] available for PCI devices clocksource refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1910969940391419 ns setup_percpu: NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1 PERCPU: Embedded 32 pages/cpu @88017fc0 s93912 r8192 d28968 u524288 Built 1 zonelists in Zone order, mob
Re: [coreboot] Some errors by compiling romstage (I am a newbie)
On Fri, Mar 3, 2017 at 8:37 AM, Maxim Gusev 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: adur...@google.com > To: Maxim Gusev , Coreboot > > On Fri, Mar 3, 2017 at 6:41 AM, Maxim Gusev 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: adur...@google.com >> To: Maxim Gusev >> coreboot@coreboot.org >> >> On Thu, Mar 2, 2017 at 8:33 AM, Maxim Gusev 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 000100187000 >>> 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: adur...@google.com >>> To: Maxim Gusev >>> coreboot@coreboot.org >>> >>> On Thu, Mar 2, 2017 at 7:24 AM, Maxim Gusev via coreboot >>> 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 >>
Re: [coreboot] coreboot+filo
when i see filo.elf with readelf -a : ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x10 Start of program headers: 52 (bytes into file) Start of section headers: 1255408 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 1 Size of section headers: 40 (bytes) Number of section headers: 10 Section header string table index: 9 Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS0010 10 01e416 00 AX 0 0 16 [ 2] .boot PROGBITS0011e418 11e418 64 00 AX 0 0 4 [ 3] .rodata PROGBITS0011e480 11e480 0047f7 00 A 0 0 32 [ 4] .eh_frame PROGBITS00122c78 122c78 00d144 00 A 0 0 4 [ 5] .data PROGBITS0012fdc0 12fdc0 002980 00 WA 0 0 32 [ 6] .hdr.mb PROGBITS00132740 132740 0c 00 WA 0 0 4 [ 7] .initctx PROGBITS00132760 132760 48 00 WA 0 0 32 [ 8] .bss NOBITS 001327c0 1327a8 041920 00 WA 0 0 32 [ 9] .shstrtab STRTAB 1327a8 45 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) There are no section groups in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x 0x 0x1327a8 0x1740e0 RWE 0x20 Section to Segment mapping: Segment Sections... 00 .text .boot .rodata .eh_frame .data .hdr.mb .initctx .bss There is no dynamic section in this file. There are no relocations in this file. The decoding of unwind sections for machine type Intel 80386 is not currently supported. No version information found in this file. readelf -a seabios: ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0xff06e Start of program headers: 52 (bytes into file) Start of section headers: 114388 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 1 Size of section headers: 40 (bytes) Number of section headers: 3 Section header string table index: 2 Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS000e41a0 60 01be60 00 WAX 0 0 32 [ 2] .shstrtab STRTAB 01bec0 11 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) There are no section groups in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x60 0x000e41a0 0x000e41a0 0x1be60 0x1be60 RWE 0x20 Section to Segment mapping: Segment Sections... 00 .text There is no dynamic section in this file. There are no relocations in this file. The decoding of unwind sections for machine type Intel 80386 is not currently supported. No version information found in this file. when i use seabios as payload : Loading segment from ROM address 0xfff1c5f8 code (compression=1) New segment dstaddr 0xe41a0 memsize 0x1be60 srcaddr 0xfff1c630 filesize 0xe6bb Loading segment from ROM address 0xfff1c614 Entry Point 0x000ff06e Payload being loaded at below 1MiB without region being marked as RAM usable. Bounce Buf
Re: [coreboot] Some errors by compiling romstage (I am a newbie)
On Fri, Mar 3, 2017 at 6:41 AM, Maxim Gusev 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: adur...@google.com > To: Maxim Gusev > coreboot@coreboot.org > > On Thu, Mar 2, 2017 at 8:33 AM, Maxim Gusev 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 000100187000 >> 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: adur...@google.com >> To: Maxim Gusev >> coreboot@coreboot.org >> >> On Thu, Mar 2, 2017 at 7:24 AM, Maxim Gusev via coreboot >> 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@coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >> >> > > -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Reminder: The maiing list vs forum poll closes in just under 24 hours.
On 03/03/2017 01:45 AM, Martin Roth wrote: As brought up in the previous coreboot community meeting, the coreboot project is discussing the idea of switching from the mailing list to a forum. This idea did not originate with the coreboot leadership, but from a request by members of the community. I know many people have some strong feelings about this one way or the other. Right now we're just collecting data on how people feel about it, and looking for suggestions on ways to either improve the mailing list or set up a well-run forum. Here's the poll about the switch. I will close the poll tomorrow, March 3, 2017. https://goo.gl/9Hd569 Martin Thank you for reminding me. For future reference I would really prefer a non-google poll - the use of google services requires javascript and I don't like enabling javascript due to how easily exploitable it is. I also do not like contributing to machine learning or advertising databases. As I have said before, most forum software discriminates against people who do not wish to run a window manager and of course javascript which is why I think things are fine as they are. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?
Hi Paul, > > I think most of the time is spent in RAM initialization. > >1. Do board owners with similar amount of memory (independent of the > board) have similar numbers? >2. What are the ways to improve that? Is it possible? For example, can > the modules be probed in parallel (if that isn?t done already)? > Regarding 1: I am running 128GB in 8GB modules (LRDIMMs) and experiencing a similar issue. With just two UDIMMs, the boot times are *much* faster. Also, the vendor BIOS is faster from the time you press the poweron button to the time the monitor gets a signal. Cheers, Daniel -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot+filo
Hi all, - i use this config: 582 CONFIG_PAYLOAD_FILO=y 589 CONFIG_FILO_MASTER=y 590 CONFIG_PAYLOAD_FILE="payloads/external/FILO/filo/build/filo.elf" 591 CONFIG_PAYLOAD_OPTIONS="" My logs: BS: BS_WRITE_TABLES times (us): entry 166670 run 767112 exit 0 POST: 0x7a CBFS: 'Master Header Locator' located CBFS at [700100:7fffc0) CBFS: Locating 'fallback/payload' CBFS: Found @ offset 1c4c0 size 179fb Loading segment from ROM address 0xfff1c5f8 code (compression=1) New segment dstaddr 0x0 memsize 0x1740e0 srcaddr 0xfff1c630 filesize 0x179c3 Loading segment from ROM address 0xfff1c614 Entry Point 0x0010 SELF Payload doesn't target RAM: Failed Segment: 0x0, 1523936 bytes 0. -0fff: CONFIGURATION TABLES 1. 1000-0009: RAM 2. 000a-000f: RESERVED 3. 0010-7cc58fff: RAM 4. 7cc59000-7cff: CONFIGURATION TABLES 5. 7d00-7fff: RESERVED 6. e000-efff: RESERVED 7. fea0-febf: RESERVED 8. fed01000-fed01fff: RESERVED 9. fed03000-fed03fff: RESERVED 10. fed06000-fed06fff: RESERVED 11. fed08000-fed08fff: RESERVED 12. fed1c000-fed1cfff: RESERVED 13. fed8-fed83fff: RESERVED Payload not loaded. Filo can't loading in ram memory at @ 0x0, can you change this address ? How to? -- Sébastien Basset -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] The ECC 2017 web page
It depends on the browser if it uses hardware accerlation but I am gonna fix that for you. I will add some idle js which stops the video if not focused. Best Regards Zaolin On 03/03/2017 06:11 AM, ron minnich wrote: > That one web page, while not even visible, eats up 25% of the cpu on > one core of my osx laptop. > > Fan is at high speed. Laptop is hot. > > I realize it's a pretty web page and all, but what makes it do that? > Is it necessary for it to cause such power consumption? We need green > web pages :-) > > thanks > > ron > > signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
