I previously wanted to port coreboot to my machine. But due to the lack of FSPs, specially the MRC.bin for Cedar trail platforms, I couldn't do it. But, I have recently found the source code for an Intel Cedar trail bios. It is actually an AMI bios source code. It has a huge amount of very useful information like Memory Init, Power management etc. And has almost everything open source except the EC. I want to ask how can I use it to add support for coreboot to Cedar trail? Is it possible to use at least the memory init and the FSP alternatives from the source code? I can share the code archive if you need to have a look at them Alif
Alif Ilhan wrote:
I have recently found the source code for an Intel Cedar trail bios. It is actually an AMI bios source code. .. has almost everything open source except the EC.
Unless the source code was published by the author (AMI) under one of the licenses listed at https://opensource.org/licenses/alphabetical it's not open source - a better term would perhaps be leaked source.
I want to ask how can I use it to add support for coreboot to Cedar trail?
Unfortunately you can't really use leaked source for much, but read on..
Is it possible to use at least the memory init and the FSP alternatives from the source code?
No; since coreboot is licensed per GPLv2, which means that leaked source is useless. GPLv2 requires among other things that coreboot source code may be legally copied - this is not the case with leaked source, or even with a derivative work of leaked source. Now, depending on your jurisdiction, what you *can* possibly do is so-called clean room reverse engineering. There, some developers study the leaked source and then write documentation - not code - which describes the functionality in detail. Later, *other* developers (that's critical) can use the documentation and write source code from scratch which is also licensed per GPLv2 and will hopefully work. This method obviously requires a huge effort. But as far as I know it's the only way to make use of leaked source in a legal and thus sustainable way. If the developer(s) who study the leaked source already know what coreboot can and can not do, then perhaps it's possible to create some simplified, to-the-point documentation for the only relevant parts in the leaked source, but that's just an idea. Please be careful not to introduce leaked source into the coreboot tree. And maybe talk with a lawyer specialized on free software about the reverse engineering situation in your jurisdiction. Kind regards //Peter
On 1/9/21 2:33 PM, Peter Stuge wrote:
Alif Ilhan wrote:
I have recently found the source code for an Intel Cedar trail bios. It is actually an AMI bios source code. .. has almost everything open source except the EC.
Unless the source code was published by the author (AMI) under one of the licenses listed at https://opensource.org/licenses/alphabetical it's not open source - a better term would perhaps be leaked source.
I want to ask how can I use it to add support for coreboot to Cedar trail?
Unfortunately you can't really use leaked source for much, but read on..
Is it possible to use at least the memory init and the FSP alternatives from the source code?
No; since coreboot is licensed per GPLv2, which means that leaked source is useless. GPLv2 requires among other things that coreboot source code may be legally copied - this is not the case with leaked source, or even with a derivative work of leaked source.
Now, depending on your jurisdiction, what you *can* possibly do is so-called clean room reverse engineering. There, some developers study the leaked source and then write documentation - not code - which describes the functionality in detail. Later, *other* developers (that's critical) can use the documentation and write source code from scratch which is also licensed per GPLv2 and will hopefully work.
This method obviously requires a huge effort. But as far as I know it's the only way to make use of leaked source in a legal and thus sustainable way.
For what it's worth: I have a few different Cedar Trail motherboards that I would like to port coreboot to. Since I have not looked at the leaked code, if such documentation was available, I would be interested in helping write a Cedarview/Cedar Trail port. Regards, Samuel
If the developer(s) who study the leaked source already know what coreboot can and can not do, then perhaps it's possible to create some simplified, to-the-point documentation for the only relevant parts in the leaked source, but that's just an idea.
Please be careful not to introduce leaked source into the coreboot tree.
And maybe talk with a lawyer specialized on free software about the reverse engineering situation in your jurisdiction.
Kind regards
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Well, should I share the code? But I am trying with Pineview raminit codes, both the MRC.bin and native one. The bios session document mentioned "Cedar View uses the same MRC build environment as Pineview" On Tue, Jan 12, 2021, 12:09 PM Samuel Holland <samuel@sholland.org> wrote:
On 1/9/21 2:33 PM, Peter Stuge wrote:
Alif Ilhan wrote:
I have recently found the source code for an Intel Cedar trail bios. It is actually an AMI bios source code. .. has almost everything open source except the EC.
Unless the source code was published by the author (AMI) under one of the licenses listed at https://opensource.org/licenses/alphabetical it's not open source - a better term would perhaps be leaked source.
I want to ask how can I use it to add support for coreboot to Cedar trail?
Unfortunately you can't really use leaked source for much, but read on..
Is it possible to use at least the memory init and the FSP alternatives from the source code?
No; since coreboot is licensed per GPLv2, which means that leaked source is useless. GPLv2 requires among other things that coreboot source code may be legally copied - this is not the case with leaked source, or even with a derivative work of leaked source.
Now, depending on your jurisdiction, what you *can* possibly do is so-called clean room reverse engineering. There, some developers study the leaked source and then write documentation - not code - which describes the functionality in detail. Later, *other* developers (that's critical) can use the documentation and write source code from scratch which is also licensed per GPLv2 and will hopefully work.
This method obviously requires a huge effort. But as far as I know it's the only way to make use of leaked source in a legal and thus sustainable way.
For what it's worth: I have a few different Cedar Trail motherboards that I would like to port coreboot to. Since I have not looked at the leaked code, if such documentation was available, I would be interested in helping write a Cedarview/Cedar Trail port.
Regards, Samuel
If the developer(s) who study the leaked source already know what coreboot can and can not do, then perhaps it's possible to create some simplified, to-the-point documentation for the only relevant parts in the leaked source, but that's just an idea.
Please be careful not to introduce leaked source into the coreboot tree.
And maybe talk with a lawyer specialized on free software about the reverse engineering situation in your jurisdiction.
Kind regards
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Am Di., 12. Jan. 2021 um 09:47 Uhr schrieb Alif Ilhan <alifilhan0@gmail.com
:
Well, should I share the code? But I am trying with Pineview raminit codes, both the MRC.bin and native one. The bios session document mentioned "Cedar View uses the same MRC build environment as Pineview"
We welcome contributions that you have written yourself and that you are legally allowed to license under GPLv2 terms. Don't share other people's code that came under licenses that aren't compatible with the GPLv2, or under no license at all (such as leaked code). Deriving knowledge from such code to write your own can lead to legal problems (the boundary of what constitutes a derivative work isn't very clear and can differ from country to country), for you and for the project, so please be careful! There's been an example on how that can hamper open source projects: https://en.wikipedia.org/wiki/ReactOS#Internal_audit That issue led to a significant slowdown in their development for several years until the mess was sorted out. Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Thank you. I will make sure it will not happen. But can anyone tell me where can I find MRC.bin from pineview? Which chromebook specifically? On Tue, Jan 12, 2021, 4:35 PM Patrick Georgi via coreboot < coreboot@coreboot.org> wrote:
Am Di., 12. Jan. 2021 um 09:47 Uhr schrieb Alif Ilhan < alifilhan0@gmail.com>:
Well, should I share the code? But I am trying with Pineview raminit codes, both the MRC.bin and native one. The bios session document mentioned "Cedar View uses the same MRC build environment as Pineview"
We welcome contributions that you have written yourself and that you are legally allowed to license under GPLv2 terms.
Don't share other people's code that came under licenses that aren't compatible with the GPLv2, or under no license at all (such as leaked code). Deriving knowledge from such code to write your own can lead to legal problems (the boundary of what constitutes a derivative work isn't very clear and can differ from country to country), for you and for the project, so please be careful!
There's been an example on how that can hamper open source projects: https://en.wikipedia.org/wiki/ReactOS#Internal_audit That issue led to a significant slowdown in their development for several years until the mess was sorted out.
Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi, On Tue, Jan 12, 2021 at 11:24 AM Alif Ilhan <zakirhosain71@gmail.com> wrote:
Thank you. I will make sure it will not happen. But can anyone tell me where can I find MRC.bin from pineview? Which chromebook specifically?
Pineview Chromebooks did not use coreboot, so there's no MRC.bin to use with coreboot. In any case, Cedarview's memory controller is much different from Pineview, and is actually closer to Bay Trail: there's no MCHBAR, and the relevant registers are spread across several IOSF "units". For example, high-level memory controller registers are in the DUnit, and there's one DUnit per channel. The 2nd volume of the Atom D2000/N2000 datasheet contains a long table with IOSF ports and register offsets, which can be useful. Best regards, Angel
So is BLDK refcode useable?. I have the BLDK ref code for Cedar Rock board based on Atom Cedar Trail. I think BLDK reference code was public(I'm kinda sure it it public, just not available everywhere)...given the documents are publicly available across the internet and there are a lot of public guides porting EDK2 to Atom Cedar trail using the code. . On Tue, 12 Jan 2021 at 18:24, Angel Pons <th3fanbus@gmail.com> wrote:
Hi,
On Tue, Jan 12, 2021 at 11:24 AM Alif Ilhan <zakirhosain71@gmail.com> wrote:
Thank you. I will make sure it will not happen. But can anyone tell me
where can I find MRC.bin from pineview? Which chromebook specifically?
Pineview Chromebooks did not use coreboot, so there's no MRC.bin to use with coreboot. In any case, Cedarview's memory controller is much different from Pineview, and is actually closer to Bay Trail: there's no MCHBAR, and the relevant registers are spread across several IOSF "units". For example, high-level memory controller registers are in the DUnit, and there's one DUnit per channel. The 2nd volume of the Atom D2000/N2000 datasheet contains a long table with IOSF ports and register offsets, which can be useful.
Best regards,
Angel
participants (6)
-
Alif Ilhan -
Alif Ilhan -
Angel Pons -
Patrick Georgi -
Peter Stuge -
Samuel Holland