Hi team
I am working on building coreboot for one of our customized board. This is based on Intel ISX board reference design, reference can be taken as Minnowboard or BayleyBay CRB.
As per documentation given under coreboot, I created folder with my board name under src/intel/mainboard/xxx and did changes required.
If I tried the coreboot with these changes on minnowboard, it got stuck at FSP MRC Cache not found.
But if the same code changes I copied under src/intel/mainboard/minnowmax and built, it booted fine.
I would like to know what is the importance of these board names, SMBIOS table name, serial no which are defined for Minnowmax.
Is there some master registry where all these are stored, and if any new entry comes, how we should add it.
Regards
Mayuri
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
On 2016-05-23 05:20 PM, Nuno Moreira wrote:
> Hi Iru, Arian and Alexander.
> Thanks a lot for your feedback :)
>
> Trying to reply to your input and presenting some questions emerging
> from it:
>
> [IRU] "X220 has been supported for years :)"
> [/ME] Indeed. My mistake. After a better Internet search, I can see
> support at least since 2013. Thanks for the correction, Iru ;)
>
> [IRU] "To unlock RAM speed in coreboot, you can see my article, but I
> haven't tested it yet."
> [/ME] Thanks a lot for this. I think I'll take the "risk" ant try to
> get 1866Mhz speed (fingers crossed).
>
> [IRU] "tp-smapi depends on the proprietary firmware, and you can set
> the battery threshold with ectool."
> [/ME] Oh, this is great. I was not aware of this tool. I was looking
> to tpacpi-bat as an alternative. Gotta check what fits me&scripts
> better.
>
> [ARIAN] "If you had damaged the ME firmware, you would not reach
> coreboot or any other firmware - the blob is signed"
> [ARIAN] "If you had damaged the NIC firmware, ethernet would probably
> be broken, so that's clearly defined."
> [/ME] That's good to know. Everything should be ok then, since BIOS
> can boot and Ethernet is working fine :)
>
> [ARIAN] "refining the wiki would be a good thing to do"
> [/ME] Indeed. I'll try to update the Wiki after I finished my testing.
>
> [ARIAN] "That's RAM _clock_ not data rate which is double the clock
> rate (-> DDR) - you're not any worse off than with the original
> firmware."
> [/ME] Also good news. This means the current speed is the default
> maximum of 1333 MHz. The problem in dmidecode info presentation is
> probably related with the issue Alexander presents below then.
>
Should we put the DDR frequency or real frequency here ?
>From users point of view DDR frequency does make more sense.
It looks like some vendors put DDR frequency and others the real
frequency here...
> [ALEXANDER] "we might written the wrong value into dmidata. (dmidecode
> reads a description written by the firmware, has nothing to do with
> the real values)."
> [/ME] This is the most "logical" possibility I think. DO YOU GUYS KNOW
> ABOUT ANY OTHER METHOD TO GET/READ THE "REAL" RAM CLOCK SPEED? I would
> like to apply the RAM speed unlock patch presented by Iru and check
> the speed with different RAM modules (2x4G 1333Mhz and 2x8GB 1866Mhz)
> in order to confirm if the max speed is really unlocked. But if
> dmidecode always presents 667MHz as RAM speed I will never know if it
> is working or not :(
>
The "real" frequency is the value reported by dmidecode.
It is the frequency the ram is running at, it isn't hardcoded to 667Mhz.
You can use it to verify the current RAM speed.
I don't think there's another linux tool to get real values.
> [ALEXANDER] "tp smapi depends on lot of SMM/SMI code. So tp-smapi
> kernel module asked the Lenovo BIOS to tell the EC to do something.
> coreboot don't want to support SMM/SMI APIs, because they are quite
> dangerous. But there is another way to get those features back. We
> know how to enable it, but we haven't yet create a way to control this
> by the user. One thing could be a userspace tool executed as root or
> we add another CMOS configuration for it. Any idea?"
> [/ME] Thanks for the clarification, Alexander. Well, in my user
> perspective, I think a user-space tool will be better because it can
> be used to update the thresholds more easily. If we only rely on CMOS
> config we would need to re-flash it every time we want to change the
> thresholds. (AFAIK, x220 only supports HW flash. We cannot re-flash
> from OS).
>
> [ALEXANDER] "It looks you're using the native graphics init instead of
> the binary blob VGABIOS. The last time I tried it, I had a lot of
> problems."
> [/ME] Yes, I'm using NGI. I did not suffer from the well-know "one
> color blur image" problem yet.
>
> [ALEXANDER] "Thanks for your feedback. Feel free to create tickets or
> updating the x220 wiki page."
> [/ME] You're welcome and Thanks for your support. I'll definitely try
> to update the Wiki after I finished my testing.
>
> --sigkill
>
> On Mon, May 23, 2016 at 3:02 PM, Alexander Couzens <lynxis(a)fe80.eu>
> wrote:
>
>> hey,
>>
>> nice you made it!
>>
>>> *3) Coreboot rocks but... Current Open issues:*
>>> ---------------------------------------------
>>> I decided to use coreboot-4.4 release instead of git-master.
>>> As payload I'm using SeaBIOS (booting Archlinux with Syslinux as
>>> bootloader).
>> That's ok.
>>
>>> Before, with dmidecode -t 17 the speed was 1333Mhz and now it is
>> just
>>> 667Mhz...
>> we might written the wrong value into dmidata. (dmidecode reads a
>> description written by the firmware, has nothing to do with the real
>> values).
>>
>>> *3.2) TP-SMAPI: *
>>> --------------
>> tp smapi depends on lot of SMM/SMI code. So tp-smapi kernel module
>> asked the Lenovo BIOS to tell the EC to do something. coreboot don't
>> want to support SMM/SMI APIs, because they are quite dangerous.
>> But there is another way to get those features back.
>> We know how to enable it, but we haven't yet create a way to control
>> this by the user.
>>
>> One thing could be a userspace tool executed as root or we add
>> another
>> CMOS configuration for it. Any idea?
>>
>>> *3.3) Config files:*
>>> ------------------
>>> coreboot - http://pastebin.com/9ymtxLBW
>> It looks you're using the native graphics init instead of the binary
>> blob VGABIOS. The last time I tried it, I had a lot of problems. [3]
>>
>> Thanks for your feedback. Feel free to create tickets or updating
>> the
>> x220 wiki page.
>>
>> Best,
>> lynxis
>>
>> [3] https://ticket.coreboot.org/issues/37
>> --
>> Alexander Couzens
>>
>> mail: lynxis(a)fe80.eu
>> jabber: lynxis(a)fe80.eu
>> mobile: +4915123277221 [1]
>> gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
>
>
>
> Links:
> ------
> [1] tel:%2B4915123277221
Regards,
Patrick
hey,
nice you made it!
> *3) Coreboot rocks but... Current Open issues:*
> ---------------------------------------------
> I decided to use coreboot-4.4 release instead of git-master.
> As payload I'm using SeaBIOS (booting Archlinux with Syslinux as
> bootloader).
That's ok.
> Before, with dmidecode -t 17 the speed was 1333Mhz and now it is just
> 667Mhz...
we might written the wrong value into dmidata. (dmidecode reads a
description written by the firmware, has nothing to do with the real
values).
> *3.2) TP-SMAPI: *
> --------------
tp smapi depends on lot of SMM/SMI code. So tp-smapi kernel module
asked the Lenovo BIOS to tell the EC to do something. coreboot don't
want to support SMM/SMI APIs, because they are quite dangerous.
But there is another way to get those features back.
We know how to enable it, but we haven't yet create a way to control
this by the user.
One thing could be a userspace tool executed as root or we add another
CMOS configuration for it. Any idea?
> *3.3) Config files:*
> ------------------
> coreboot - http://pastebin.com/9ymtxLBW
It looks you're using the native graphics init instead of the binary
blob VGABIOS. The last time I tried it, I had a lot of problems. [3]
Thanks for your feedback. Feel free to create tickets or updating the
x220 wiki page.
Best,
lynxis
[3] https://ticket.coreboot.org/issues/37
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
Hi Huno,
not terribly knowledgeable and speaking from T420-experience
> I've read and used the blobs from the "damaged" custom BIOS. I'm not sure if this can affect the functionality of Coreboot. Apparently, it does not.
If you had damaged the ME firmware, you would not reach coreboot or any other firmware - the blob is signed
If you had damaged the NIC firmware, ethernet would probably be broken, so that's clearly defined.
> /(Let me know if anyone of you need details/help about/with the HW flashing in this type of chip (MX25L6406E/MX25L6408E)).
refining the wiki would be a good thing to do
> *3.1) RAM speed:*
> ---------------
> *=> So, if I'm understanding it correctly, current 667 Mhz is not the maximum ***speed *supported.
> Any idea on how I can get higher speeds?*
That's RAM _clock_ not data rate which is double the clock rate (-> DDR) - you're not any worse off than with the original firmware.
Hello, everyone.
First of all, I would like to thanks and to congratulate all the community
who helps to develop and to optimize this great project. Keep it up :)
I would appreciate if you can give me some opinions or point me to someone
who will, regarding the Open Issues I present below (3.1 and 3.2).
Trying to give you a brief contextualization of my status before and after
Coreboot.
*1) Init:*
--------
Recently I bought a refurbished x220 and flashed it with a custom BIOS
(Lenovo ThinkPad x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo)
because I wanted to unlock the RAM speed to be 1866MHz (max RAM speed is
locked to 1333Mhz in official BIOS), white-list some Wi-Fi cards, Advanced
Chipset Config menu, etc.
This custom BIOS worked perfectly until I changed some settings related
with Intel VT-x. If I recall correctly, I activated SR-IOV for PCI-E, saved
and exited and after that x220 = BRICKED.
I tried every typical troubleshooting/workaround (Removing as much HW as
possible, unplug BIOS battery for hours, etc), nothing worked.
x220 BIOS never booted again and the machine was in a constant boot loop.
Don't know why/how this happened in the first place, but since it is a
custom BIOS and it is very hard to reach the developer, I knew I could
never get it to work without an intrusive method...
*2) Coreboot as Salvation:*
-------------------------
I started to look for alternatives, and luckily, Coreboot supports x220
since a couple of months ago :)
After dealing with all the learning curve to understand the minimal
requirements to compile and install Coreboot (tricky part is basically the
need for HW flashing) I managed to get a working BIOS and x220 is now
(almost 100%) operational :)
I've read and used the blobs from the "damaged" custom BIOS. I'm not sure
if this can affect the functionality of Coreboot. Apparently, it does not.
*(Let me know if anyone of you need details/help about/with the HW flashing
in this type of chip (MX25L6406E/MX25L6408E)).*
*3) Coreboot rocks but... Current Open issues:*
---------------------------------------------
I decided to use coreboot-4.4 release instead of git-master.
As payload I'm using SeaBIOS (booting Archlinux with Syslinux as
bootloader).
*3.1) RAM speed:*
---------------
I've 2 x 8GB DRR3-1866MHz installed. The 16GB are detected but the speed
reported is just 667MHz.
With the official BIOS, the max speed was 1333Mhz. Don't know how Coreboot
is handling this subject in this particular main-board...
DDR timings are a little bit confusing to me, I guess...
Before, with dmidecode -t 17 the speed was 1333Mhz and now it is just
667Mhz...
This 667MHz speed I get with coreboot is 2x667=1333Mhz or in reality is
2x333MHz?
In "northbridge/intel/sandybridge/raminit.c" we can see the following
statement:
/* Maximum supported DDR3 frequency is 1066MHz (DDR3 2133) so make sure
* we cap it if we have faster DIMMs.
* Then, align it to the closest JEDEC standard frequency */
*=> So, if I'm understanding it correctly, current 667 Mhz is not the
maximum *
*speed supported.Any idea on how I can get higher speeds?*
*3.2) TP-SMAPI: *
--------------
Looks like tp-smapi is not available using Coreboot. It was OK with the
official and custom BIOS before.
>From what I've read, this is not a Coreboot limitation... Not sure if the
blobs/EC are not ok for tp-smapi now...
I use tp-smapi for battery threshold, etc. TLP
<http://linrunner.de/en/tlp/tlp.html>also uses tp-smapi. So it is kinda of
important to me.
*=> Anyone using tp-smapi with no problems out there?*
*3.3) Config files:*
------------------
coreboot - http://pastebin.com/9ymtxLBW
seabios - http://pastebin.com/rUU7ajRH
cmos.default - http://pastebin.com/Pm5vS15R
Thanks in advance, guys.
All the best \o
--sigkill
Hi Zoran
I tried Minnowboard max bios file available on intel firmware site. With this file, I am able to boot to UEFI bios setup. But I don’t see any option to change CSM off.
When I am booting thru coreboot, I don’t see any option to change this CSM mode.
Regards
Mayuri
From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com]
Sent: 21 May 2016 12:47
To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com>
Cc: coreboot <coreboot(a)coreboot.org>
Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay
Mayuri,
> Zoran writes in last email: "...UEFI payload will not find EFI32 /boot/EFI directory created..."
My bad (right thinking, but too fast hands): should read FAT32 instead EFI32.
> Sorry, but I am not able to understand what you have mentioned.
Please, read carefully the following article: https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually...
I have no time explaining the written. You need to spend maybe whole day analyzing it, trying to understand what Adam writes about. Bottom line, your Tiano Core works perfectly as payload, but you have CSM ON formatted HDD (must have CSM OFF).
Zoran
On Fri, May 20, 2016 at 10:41 AM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote:
Hi Zoran
Sorry, but I am not able to understand what you have mentioned.
Can you please help me explain little detail?
Sorry, but I am new to this coreboot environment.
Regards
Mayuri
From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com<mailto:zoran.stojsavljevic@gmail.com>]
Sent: 20 May 2016 13:39
To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>>
Cc: coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>>
Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay
Hello Mayuri,
Not sure if I am right, but to bring GRUB 2.0 from CSM OFF and CSM ON modes, you must have two distinct HDDs, one created with CSM ON, other with CSM OFF. If you are using one with CSM ON (seems the case), your UEFI payload will not find EFI32 /boot/EFI directory created, and it does not understand MBR).
Does this (what I wrote) make sense?
Zoran
On Fri, May 20, 2016 at 7:21 AM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote:
Hi Zoran
Currently we are using FSP 3. But it works fine with seabios payload.
Only when I include UEFI, I am getting this issue. So I am not sure if this is related to FSP3 or 4.
My query is there any additional configurations required in UEFI Payload to make it work for Minnowboard max.
I see difference in addresses for UEFI and Seabios payload. Not sure where are they set.
Seabios payload (working)
CBFS provider active.
CBFS @ 500000 size 2ff9c0
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 76b40 size f782
'fallback/payload' located at offset: 576b78 size: f782
Loading segment from rom address 0xffd76b78
code (compression=1)
New segment dstaddr 0xe2780 memsize 0x1d880 srcaddr 0xffd76bb0 filesize 0xf74a
Loading segment from rom address 0xffd76b94
Entry Point 0x000ff06e
Payload being loaded below 1MiB without region being marked as RAM usable.
Bounce Buffer at 7ac50000, 451744 bytes
Loading Segment: addr: 0x00000000000e2780 memsz: 0x000000000001d880 filesz: 0x000000000000f74a
lb: [0x0000000000100000, 0x0000000000137250)
Post relocation: addr: 0x00000000000e2780 memsz: 0x000000000001d880 filesz: 0x000000000000f74a
using LZMA
[ 0x000e2780, 00100000, 0x00100000) <- ffd76bb0
dest 000e2780, end 00100000, bouncebuffer 7ac50000
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 130526 exit 0
FspNotify(EnumInitPhaseReadyToBoot)
fsp_header_ptr: fffc0094
FSP Header Version: 1
FSP Revision: 3.3
Returned from FspNotify(EnumInitPhaseReadyToBoot)
POST: 0x7b
Jumping to boot code at 000ff06e(7acbf000)
POST: 0xf8
CPU0: stack: 0012e000 - 0012f000, lowest used address 0012eb10, stack used: 1264 bytes
entry = 0x000ff06e
lb_start = 0x00100000
lb_size = 0x00037250
buffer = 0x7ac50000
SeaBIOS (version rel-1.9.0-127-gc8e105a)
UEFI Payload logs (not working)
CBFS provider active.
CBFS @ 500000 size 2ff9c0
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 56ec0 size 90b92
'fallback/payload' located at offset: 556ef8 size: 90b92
Loading segment from rom address 0xffd56ef8
code (compression=1)
New segment dstaddr 0x800000 memsize 0x410000 srcaddr 0xffd56f30 filesize 0x90b5a
Loading segment from rom address 0xffd56f14
Entry Point 0x008002c0
Bounce Buffer at 7ac34000, 437408 bytes
Loading Segment: addr: 0x0000000000800000 memsz: 0x0000000000410000 filesz: 0x0000000000090b5a
lb: [0x0000000000100000, 0x0000000000135650)
Post relocation: addr: 0x0000000000800000 memsz: 0x0000000000410000 filesz: 0x0000000000090b5a
using LZMA
[ 0x00800000, 00c10000, 0x00c10000) <- ffd56f30
dest 00800000, end 00c10000, bouncebuffer 7ac34000
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 507070 exit 0
FspNotify(EnumInitPhaseReadyToBoot)
fsp_header_ptr: fffc0094
FSP Header Version: 1
FSP Revision: 3.3
Returned from FspNotify(EnumInitPhaseReadyToBoot)
POST: 0x7b
Jumping to boot code at 008002c0(7ac9f000)
POST: 0xf8
CPU0: stack: 0012c000 - 0012d000, lowest used address 0012cb10, stack used: 1264 bytes
entry = 0x008002c0
lb_start = 0x00100000
lb_size = 0x00035650
buffer = 0x7ac34000
From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com<mailto:zoran.stojsavljevic@gmail.com>]
Sent: 20 May 2016 10:44
To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>>; coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>>
Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay
Hello Mayuri,
If I am not mistaken (I often mix BYT Coreboot @ threads in my head), you are using BYT FSP Version 3.
> fsp_header_ptr: fffc0094 <== correct
> FSP Header Version: 1
> FSP Revision: 3.3 <== please, use Version 4
Please, try to use the latest public BYT FSP Version 4 posted at: www.intel.com/fsp<http://www.intel.com/fsp>
BAYTRAIL_FSP_GOLD_004_22-MAY-2015.fd
BAYTRAIL_FSP_GOLD_004_22-MAY-2015_DEBUG.fd
Don't remember deltas between V3 and V4, I thing something was wrong in V3 with MTRRs' setup, if I do not mix data in my head.
INTEL also has Version 5 for a quite some time, but this one for some reasons never got publicly released.
Please, report if this solved your problems.
Zoran
On Wed, May 18, 2016 at 6:56 AM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote:
Hi
While booting my Minnomboard with coreboot and UEFI, it hangs at below point while loading the payload.
I followed the procedure to download latest EDK2 tree and built UEFIPAYLOAD.fd and copied it to coreboot/payloads/external/tianocore folder and gave this path in make menuconfig.
Has anybody come across this?
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 507070 exit 0
FspNotify(EnumInitPhaseReadyToBoot)
fsp_header_ptr: fffc0094
FSP Header Version: 1
FSP Revision: 3.3
Returned from FspNotify(EnumInitPhaseReadyToBoot)
POST: 0x7b
Jumping to boot code at 008002c0(7ac9f000)
POST: 0xf8
CPU0: stack: 0012c000 - 0012d000, lowest used address 0012cb10, stack used: 1264 bytes
entry = 0x008002c0
lb_start = 0x00100000
lb_size = 0x00035650
buffer = 0x7ac34000
Regards
Mayuri
From: Mayuri Tendulkar
Sent: 17 May 2016 14:13
To: 'Zoran Stojsavljevic' <zoran.stojsavljevic(a)gmail.com<mailto:zoran.stojsavljevic@gmail.com>>; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>
Subject: RE: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay
Hi Zoran and Martin
Today I was able to build UEFIPAYLOAD separately. I included .fd file while building coreboot.rom.
But while booting, getting some errors , so debugging those.
Need to check what more customizations to be done in UEFI for Minnowmax.
Has anybody tried it?
Regards
Mayuri
From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com]
Sent: 16 May 2016 21:04
To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>>; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>
Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay
OK, Mayuri,
You brought an interesting point. And this point is to be not only investigated by you, rather also by me and, perhaps, Coreboot community.
Since here, in Bayern/Deutschland is Holiday Day, I went to buy a beer in Munchen HBf, and while walking there I was thinking about your use case. Thinking deeper.
I know that you are using some INTEL CPU/SoC (do not remember which one, if you said one). But, while recapping how BIOS looks like, I did notice that SEC and PEI phases have nothing to do with UEFI EDK2. EDK 2 comes to play in DXE phase, where EDK2 actually takes place/overtakes control...
It says to me one major thing I did not notice while ago: that ARM SoCs are also eligible to run on UEFI compliant OSes, namely WIN 8.1+ (including WIN 10 and WIN 10 Athens/RT WIN 10). Which makes very interesting IOT case namely for ARM, allowing it also to compete in WIN space.
Interestingly enough, this idea did not come to my mind till few hours ago... I guess, Vincent (Zimmer) already thought about that. ;-)
_______
Martin (Roth) just replied, to solve this immediate mystery. probably for the beginning only for INTEL SoCs, but, I really hope, ARM will also integrate in this concept seamlessly! :-)
Zoran
_______
On Mon, May 16, 2016 at 2:29 PM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote:
Hi Zoran
I have checked that site and downloaded EDK2 code. I am trying to build it on Linux but facing some issues.
But if I generate payload file separately, I need to integrate it in coreboot separately.
So I am checking if there is way to build the payload in coreboot itself.
Regards
Mayuri
From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com<mailto:zoran.stojsavljevic@gmail.com>]
Sent: 16 May 2016 17:57
To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>>
Cc: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>
Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay
Hello Mayuri,
You should check payload called: Tiano Core (true UEFI payload).
Zoran
On Mon, May 16, 2016 at 2:12 PM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote:
Hi
Is there any mechanism to build UEFI payload directly in coreboot similar like seabios?
Regards
Mayuri
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
--
coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>
https://www.coreboot.org/mailman/listinfo/coreboot
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
On Mon, 23 May 2016, Zoran Stojsavljevic wrote:
> Hello David, Martin, Peter,
>
> I would like to ask few quick questions about payload called OpenBIOS. Since
> I know something about SeaBIOS, but nothing about OpenBIOS.
>
> Quick questions:
> [1] What is OpenBIOS? Something similar as SeaBIOS?
> [2] If [1] is YES, what are differences, and when to use SeaBIOS, when
> OpenBIOS payloads?
> [3] Does OpenBIOS simulates CSM ON only (I expect yes, butt not CSM OFF)?
> [4] Any net pointer/web pages I can read more on OpenBIOS?
[1] OpenBIOS is a GPL2 licensed implementation of OpenFirmware. It's more
akin to OpenBoot on a Sparc machine whereas SeaBIOS is akin to a PC's
traditional BIOS.
[2] OpenBIOS provides a command-line and Forth programming interface to
setting up and booting a computer. As-is, OpenBIOS is rather spartan.
See http://www.tldp.org/HOWTO/SPARC-HOWTO-14.html for a rundown of what
can be done with a Sparc machine's OpenBoot environment.
[3] If you're asking if it provides legacy BIOS compatibility, then no.
[4] http://www.openfirmware.info/
--
David Griffith
dave(a)661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Hello David, Martin, Peter,
I would like to ask few quick questions about payload called OpenBIOS.
Since I know something about SeaBIOS, but nothing about OpenBIOS.
Quick questions:
[1] What is OpenBIOS? Something similar as SeaBIOS?
[2] If [1] is YES, what are differences, and when to use SeaBIOS, when
OpenBIOS payloads?
[3] Does OpenBIOS simulates CSM ON only (I expect yes, butt not CSM OFF)?
[4] Any net pointer/web pages I can read more on OpenBIOS?
Thank you,
Zoran
On Tue, May 17, 2016 at 10:19 PM, Martin Roth <gaumless(a)gmail.com> wrote:
> I agree that downloading at build time shouldn't be a requirement, and
> that there should be the ability for building on a machine that isn't
> connected to the internet. So I'd say that it's important for the
> number of *REQUIRED* downloads at build time to be zero.
>
> Adding another payload option that downloads at build time isn't an
> issue though - for people who don't want to use it, they can select
> 'no payload' or 'elf payload'.
>
> Martin
>
> On Tue, May 17, 2016 at 1:47 PM, Peter Stuge <peter(a)stuge.se> wrote:
> > David Griffith wrote:
> >> Is there any interest in having the Coreboot build process downliad
> >
> > In general I think it's important to reduce the number of downloads
> > during coreboot builds to zero.
> >
> > Downloading needs to be managed separately from building.
> >
> >
> > //Peter
> >
> > --
> > coreboot mailing list: coreboot(a)coreboot.org
> > https://www.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
Dear Sir.
Thank's your work.
Enable the bi-direction serial console is done.
2016-05-20 오후 8:36에 Kyösti Mälkki 이(가) 쓴 글:
>
>
> On Tue, May 17, 2016 at 10:46 PM, Martin Roth <gaumless(a)gmail.com
> <mailto:gaumless@gmail.com>> wrote:
>
> Hi,
> If you want bi-directional serial port in SeaBIOS, I think you need
> to stick with the version from Sage. As far as I know, it's never been
> supported in the upstream SeaBIOS version.
>
>
> I have pulled this serial to keyboard mapping change from SageBIOS and
> posted on the seabios list today. Hitting ESC and changing boot media
> seemed to work.
>
> BR,
> Kyösti
>
On Sat, May 21, 2016 at 09:14:49PM +0000, thejapanscout . wrote:
> I want to see if coreboot could support an old Latitude D510 I have from
> late 2005. It's suitable for low-end operations such as running Firefox and
> computations, and I'm currently running Lubuntu on this thing.
>
> Vendor: Dell
Coreboot currently doesn't support any Dell hardware.
> Motherboard ID: 3TZKF91, according to dmidecode -s system-seriel-number
> CPU: Pentium M, Type 0, Family 6, Model 13, Stepping 8
> Northbridge/Southbridge: likely 82915GM(?), ICH6/M Southbridge
Coreboot supports GM45 northbridges, and a few others, I'm not sure if
this northbridge is supported.
Coreboot supports the 82801Ex (ICH5) and Gx (ICH7), but apparently no
ICH6.
> lspci -tvnn output:
> -[0000:00]-+-00.0 Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller [8086:2590]
> +-02.0 Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592]
> +-02.1 Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2792]
> +-1d.0 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 [8086:2658]
> +-1d.1 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 [8086:2659]
> +-1d.2 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 [8086:265a]
> +-1d.3 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 [8086:265b]
> +-1d.7 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [8086:265c]
> +-1e.0-[02-06]--+-00.0 Broadcom Corporation BCM4401-B0 100Base-TX [14e4:170c]
> | +-01.0 Texas Instruments PCI6515 Cardbus Controller [104c:8036]
> | +-01.2 Texas Instruments Device [104c:8037]
> | \-03.0 Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318]
> +-1e.2 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller [8086:266e]
> +-1e.3 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller [8086:266d]
> +-1f.0 Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge [8086:2641]
> \-1f.2 Intel Corporation 82801FBM (ICH6M) SATA Controller [8086:2653]
>
> There is no Super I/O chip on the mainboard, nor one can be detected by
> superiotool. Sadly, this is where my venture ends here as flashrom refuses
> to identify the motherboard because it halts if it finds an unsupported
> laptop, so I can't identify the flash chip. SPI, maybe?
SPI flashing is pretty inevitable during coreboot development anyway (in
most cases), because internal flashing requires a booted system and
coreboot won't boot at first.
Overall, I guess this wouldn't be an easy port. And given that this
laptop is quite old, it's probably not worth it. (If you want to port a
laptop that can run without the Intel ME, I'd recommend one with GM45
and ICH9.)
Regards,
Jonathan
