[coreboot] Debug builds and memory testing

[Naveed Ghori]

Hi all,

Is there a debug build of coreboot or a way to test memory very early on.
My custom board goes through the romstage just fine but stops booting while 
trying to enumerate the buses.

I am suspecting RAM might be an issue so would like to eliminate that by doing 
a memory test on it.
--
POST: 0x72
Enumerating buses...
Show all devs... Before device enumeration.
Root Dev
--

Thanks in advance,
Naveed

Naveed Ghori | Lead Firmware & Driver Engineer

DTI Group Ltd | Transit Security & Surveillance

31 Affleck Road, Perth Airport, Western Australia 6105, AU

P +61 8 9373 2905,151 | F +61 8 9479 1190 | naveed.gh...@dti.com.au



Visit our website www.dti.com.au

The information contained in this email is confidential. If you receive this 
email in error, please inform DTI Group Ltd via the above contact details. If 
you are not the intended recipient, you may not use or disclose the information 
contained in this email or attachments.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Query regarding coreboot for new intel customized board

[Mayuri Tendulkar]

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."
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ThinkPad x220 - Status

[Nuno Moreira]

Hello, Patrick.
Thanks for your input.

*[Patrick]* "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..."
*[/me]* I think dmidata *should present the DDR frequency*. A user (without
much knowledge) wants to see the value he bought :) if "DDR3 - 1866 MHz"
then dmidecode = 1866Mhz (not 933 MHz, since this value could lead to
misunderstanding). *[AFAIK, this can also be tricky if we are not in dual
channel mode, right? I understand that we need to have 2 modules in order
to get the DDR speed = 2 x REAL_FREQ. Anyway, with my basic knowledge, it
seems to be possible to add the correct DDR frequency written into dmidata
if we validate the channel mode...]*

*[Patrick]* "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.
*[/me]* Before coreboot (With custom BIOS), dmidecode reported 1333Mhz
(even with the 1866Mhz modules). Possibly the firmware was writing 1333Mhz
to dmidata also. Lenovo BIOS used the DDR Freq and not the Real Freq,
apparently. This takes me to the following question:* If coreboot is not
hard-coded (and it is prepared to write any real RAM clock to dmidata)
then, if I patch coreboot to unlock 1866Mhz (2x933Mhz) DDR frequency, it is
expected to have 933MHz written into dmidata? (if this happens, then yes.
We can test and check with the usage of different modules)* Any idea in
which (source .c) this value is being set to be written?

Thanks in advance.
--sigkill


On Mon, May 23, 2016 at 4:42 PM, Patrick Rudolph  wrote:

> 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 

Re: [coreboot] ThinkPad x220 - Status

[Patrick Rudolph]

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 
> 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 ge

Re: [coreboot] ThinkPad x220 - Status

[Nuno Moreira]

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.

*[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 :(

*[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  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/iss

Re: [coreboot] ThinkPad x220 - Status

[Alexander Couzens]

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: lyn...@fe80.eu
jabber: lyn...@fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604


pgpfOgjw8CUu6.pgp
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ThinkPad x220 - Status

[arian]

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.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] ThinkPad x220 - Status

[Nuno Moreira]

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
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
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Need a bigger CBFS size. What's a save value?

[David Griffith]

I'm experimenting with a Thinkpad T60p, specifically getting something 
working that includes PXE and secondary payloads.  Apparently the default 
CBFS size of 0x4 is too small because the build process complains it 
can't add ipxe.rom and guesses that there's no room.  Just now I tried 
specifying a size of 0x20, thinking that would work because I have a 
two megabyte SPI flash chip.  I went through the procedures on 
https://www.coreboot.org/Board:lenovo/t60 and 
https://www.coreboot.org/Board:lenovo/x60/Installation which led to a T60p 
that shows a black screen and is non-responsive.  So, I guess that was a 
wrong value.


So, what's a safe value for the CBFS size that will allow me to add PXE 
and some other secondary payloads?



--
David Griffith
d...@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?

--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay

[Mayuri Tendulkar]

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.stojsavlje...@gmail.com]
Sent: 21 May 2016 12:47
To: Mayuri Tendulkar 
Cc: coreboot 
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-work-then/

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 
mailto:mayuri.tendul...@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.stojsavlje...@gmail.com]
Sent: 20 May 2016 13:39
To: Mayuri Tendulkar 
mailto:mayuri.tendul...@aricent.com>>
Cc: coreboot 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 
mailto:mayuri.tendul...@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 @ 50 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 7ac5, 451744 bytes
Loading Segment: addr: 0x000e2780 memsz: 0x0001d880 filesz: 
0xf74a
lb: [0x0010, 0x00137250)
Post relocation: addr: 0x000e2780 memsz: 0x0001d880 filesz: 
0xf74a
using LZMA
[ 0x000e2780, 0010, 0x0010) <- ffd76bb0
dest 000e2780, end 0010, bouncebuffer 7ac5
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 = 0x0010
lb_size  = 0x00037250
buffer   = 0x7ac5
SeaBIOS (version rel-1.9.0-127-gc8e105a)



UEFI Payload logs (not working)

CBFS provider active.
CBFS @ 50 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 0x80 memsize 0x41 srcaddr 0xffd56f30 filesize 
0x90b5a
Loading segment from rom address 0xffd56f14
  Entry Point 0x008002c0
Bounce Buffer at 7ac34000, 437408 bytes
Loading Segment: addr: 0x0080 memsz: 0x0041 filesz: 
0x00090b5a
lb: [0x0010, 0x00135650)
Post relocation: addr: 0x0080 memsz: 0x0041 filesz: 
0x00090b5a
using LZMA
[ 0x0080, 00c1, 0x00c1) <- ffd56f30
dest 0080, end 00c1, 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 FspNo