Dear coreboot folks,
Using GCC 4.9.2 coreboot fails to build for certain boards, whose code
uses ‘for’ loop initial declarations.
```
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
[…]
$ make # lenovo/x60 with native graphics initialization
[…]
CC ramstage/northbridge/intel/i945/gma.o
src/northbridge/intel/i945/gma.c: In function 'probe_edid':
src/northbridge/intel/i945/gma.c:570:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < 8; i++) {
^
src/northbridge/intel/i945/gma.c:570:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
Makefile:316: recipe for target 'build/ramstage/northbridge/intel/i945/gma.o' failed
make: *** [build/ramstage/northbridge/intel/i945/gma.o] Error 1
```
As Linux has switched to C99 in version 3.18, I suggest that coreboot
also explicitly sets that in the Makefiles, so that code can easily be
copied and so that there is no dependency on the compiler default.
Are there any objections?
Thanks,
Paul
[1] https://review.coreboot.org/17623/
On 28.11.2016 22:38, ron minnich wrote:
> I'm also ok with text protobufs. My only request is that we do not use
> binary blobs or XML.
Interesting, I think almost everyone would agree to never use XML for
anything ;)
I've been looking at protobufs, the text-representation looks nice. I
like it more than JSON. But I totally agree with Peter, don't hurry!
Before we decide about our favorite data format, we should define what
we're going to store in it.
At the moment, I don't see a reason for a most human readable format,
like syslinux or legacy GRUB did it. If we can write a parser for it
in 30~50 loc, I'd prefer that over any more standardized format.
Anyway, back to what to store: With multiboot in mind, there is
o the path to the binary,
o optional list of arguments to the binary,
o optional list of paths to modules
1st, is this everything we _need_? are there other standards to load a
kernel that don't fit in this (and we'd want to support).
2nd, is this everything we _want_? how about multiple options to choose
from?
>
> Here's one .json from Harvey, defining rules for libraries. It has some
> arrays, and shows the use of structure. Seems simple enough to me.
>
> My assumption is that this would be parsed by a user level program, not
> firmware or kernel.
The idea is to specify something that can be adopted by any bootloader.
>
> If you're going to pick a format, pick a simple one with lots of parser
> implementations in lots of languages and which is easy to read (I find this
> easy to read).
>
> {
> "Libs": {
> "Include": [
> "/$ARCH/include/cflags.json"
> ],
> "Oflags": [
> "-static"
> ],
> "Post": [
> "rm -f *.o"
> ],
> "Pre": [
> "rm -f *.o *.tag.*"
> ]
> }
> }
Well, actually this shouts at me: It didn't boot because I missed a clo-
sing bracket? WTF! no, this is not human readable.
Nico
>
> On Mon, Nov 28, 2016 at 1:15 PM David Hendricks via coreboot <
> coreboot(a)coreboot.org> wrote:
>
>> On Mon, Nov 28, 2016 at 12:40 PM, Peter Stuge <peter(a)stuge.se> wrote:
>>
>> David Hendricks via coreboot wrote:
>>> On Sun, Nov 27, 2016 at 8:28 PM, ron minnich <rminnich(a)gmail.com> wrote:
>>>> I like the idea of JSON file
>>>
>>> Now we're talkin' - A standardized data format that is human
>>> readable/writeable that can be easily parsed and generated using
>>> small libraries.
>>
>> I agree with the concept as described by David, but strongly disagree
>> with choosing JSON. I think we can and should do better than that.
>>
>>
>> That was my initial reaction as well. But if you check out some examples
>> it really doesn't seem bad especially if we restrict ourselves to a subset
>> of JSON. Here's a simple example using key:value pairs (from
>> http://www.w3schools.com/js/js_json_intro.asp):
>> {"employees":[
>> {"firstName":"John", "lastName":"Doe"},
>> {"firstName":"Anna", "lastName":"Smith"},
>> {"firstName":"Peter", "lastName":"Jones"}
>> ]}
>>
>> The page for jsmn notes that it explicitly does not support "advanced"
>> functionality that does not map well to C. I'm not sure exactly what this
>> implies (presumably the above example is OK), but it seems worth
>> investigating if it suits our needs and enables us to use existing
>> standards and libraries.
>>
>> Ron - If you get a chance, can you post a sample JSON file from u-root?
>>
>>> given that CMOS might not exist on a particular platform
>>> (especially in the non-x86 world)
>>
>> Maybe no NVRAM, but surely there will be persistent storage on board?
>>
>>
>> Implementation-defined. I'm sure it exists on some designs, but in general
>> non-x86 board vendors don't add additional nonvolatile storage unless they
>> really have a specific purpose for it. Even if they add a serial EEPROM or
>> some such, it's not necessarily trivial to access like CMOS on x86
>> platforms. IMO the only persistent storage we can depend upon is the
>> persistent storage that coreboot resides on. Everything else is nice to
>> have but should not be a hard requirement.
>>
>> I suppose this could be another parameter exposed in the config file in
>> CBFS. For example, if a key "nonvolatile-storage" has value "cmos" then the
>> tools know we need to look at cmos.layout and write boot device priority
>> using CMOS-methods. We currently do something similar to this on ChromeOS
>> devices to tell where verified boot data is stored (CMOS, embedded
>> controller, SPI ROM, etc).
>>
>> --
>> David Hendricks (dhendrix)
>> Systems Software Engineer, Google Inc.
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
Grigore,
Here are my comments to what you wrote to me:
On Mon, Nov 28, 2016 at 7:59 PM, Grigore Lupescu <grigore(a)arista.com> wrote:
> Hello Zoran,
>
> [1-3] I am using the latest Ubuntu 16.04 LTS x64 desktop, 4.4 kernel.
>
Perfect. Got it. Good to know. 16.04 LTS support back-ports to kernel 4.4
APIs most of the newer features exceeding 4.4 version for some time (this
is very important info to/for me, never mind).
> [4] I don't know exactly if it's x64 or x86. I have no control over AMI
> BIOS since it's just a binary I flash into the SPI ROM, which supports the
> board.
>
Even if it is a binary, you should be able to enter it (CMOS) pressing at
the very beginning of the boot <esc> or <F2> (maybe <F1>, Lenovo 420T
supports <F1>, as example), or simultaneously - alternately both of them,
one after another (NOT both at the same time). Then you can read the BIOS
version from system BIOS page. Maybe version says what is the architecture.
Other that that, it is bloody hard to tell what BIOS (32 or 64) you have.
It is easier if you do have UEFI BIOS, but you must have/gain access to EFI
shell, which is another problem, another dimension.
> [5] I boot Linux using legacy mode (in AMI, the Linux was installed for
> legacy boot on the HDD/SSD which connects via USB - USBtoSATA)
>
You see... BIOS is a beast. With BIOS, if you have already attached HDMI
monitor, BIOS should/must detect this and record, and pass such info to OS,
somehow (very long story). Regardless what your GRUB2 supports (or, at
least, this is my naive understanding).
If your BIOS is a legacy one, guess who is doing this detection? Which part
of BIOS?! I'll tell this secret (ONLY) to you: vBIOS! ;-)
> [6] I'm not sure. So I have the following checked:
> - Run VGA Option ROMs, Native Mode
> - Add a VGA BIOS image -> 3rdparty/blobs.../VBIOS.bin
> - Set framebuffer resolution (any, without this + above, I have no HDMI
> output)
>
The secret, I'll whisper only to you again... You MUST add to Coreboot
vBIOS as video component, because vBIOS will pass to Linux so-called VBT
(the same it does above, being part of BIOS), where these info are recorded
(Coreboot, no Coreboot, does NOT matter, but for Linux video, vBIOS
component extremely DOES matter).
(for UEFI boot, this works completely differently... Just tiny note)
> [7] It's the same one referenced from Coreboot in the external payloads -
> GRUB 2.02 beta3.
>
I apologize. I made here a mistake. Forgot to mention - outdated Coreboot
GRUB2 payload. Here is a naive exercise to be done:
Please, program back BIOS into flash and boot your system (Ubuntu 16.04).
Please, stop in GRUB2, after BIOS, and inspect the Ubuntu 16.04 LTS GRUB2
data. What is the GRUB2 version?
And, as you have said: you are able (also) to execute in BIOS GRUB the
following (?!):
grub> set root=(hd0,gpt2)
grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda2
grub> initrd /boot/initrd.img-3.13.0-29-generic
grub> boot
Can you do this with the kernel 4.4??? Exact the same (above) commands? And
from where you do have 3.13? Also as entry in grub.cfg? How/from where? Or,
maybe... You use different HDD/SSD for Coreboot purposes?!
And if you use the same HDD/SSD, how do you have two different kernels you
are (after all) executing:
[A] Using GRUB2 as Coreboot payload as GRUB 2.02 beta3, executing kernel
3.13???
[B] Using GRUB2 (hidden behind MBR on the HDD/SSD) executing kernel 4.4???
I did not get out of these emails the complete picture, I admit... :-(
>From your view where would the overflow / boot problems come from ?
>
Still not able to answer this question, since I do not have clear
understanding what you actually do? I am trying...
Thank you,
Zoran
> Thank you,
> Grigore
>
> On Mon, Nov 28, 2016 at 6:31 PM, Zoran Stojsavljevic <
> zoran.stojsavljevic(a)gmail.com> wrote:
>
>> Hello Grigore,
>>
>> I have here some dummy questions (forgive me for my ignorance), but I
>> need to ask them just for the sake of curiosity (maybe, after all, we can
>> get somewhere if I articulate questions in the right direction/right format
>> for this problem):
>>
>> > If I put a proprietary AMI BIOS, GRUB2 works without issue in gfxterm
>> mode and boots Linux without issue.
>>
>> [1] What Linux architecture are you using (32 or 64)?
>> [2] Which Linux distro?
>> [3] Which kernel version?
>>
>> If you put AMI BIOS, the following questions I would like to know:
>>
>> [4] Are you using 32 or 64 BIOS?
>> [5] Which mode are you using for booting (legacy/CSM ON or UEFI/CSM OFF)?
>> [6] In the accordance with [5], what video component you have set with
>> CMOS: vBIOS or GOP driver?
>>
>> Not sure, but it seems to me that you are using too old/outdated GRUB2
>> version (or maybe I am also mistaken)?
>> [7] Could you tell us, which GRUB2 version you are using?
>>
>> Thank you,
>> Zoran
>>
>> On Mon, Nov 28, 2016 at 7:13 PM, Grigore Lupescu via coreboot <
>> coreboot(a)coreboot.org> wrote:
>>
>>> Hello,
>>>
>>> I am trying to run Linux through the GRUB2 payload. I am not tied to
>>> GRUB2 but it's the only payload that gives me HDMI output (board has no
>>> serial port) using Coreboot and AMD FT3B-LC.
>>>
>>> I have the latest Coreboot sources, have set config accordingly (e.g.
>>> CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="DB-FT3b-LC"...), getting an image
>>> on HDMI and the GRUB2 payload is executing.
>>> In GRUB2 payload I seem to have an overflow issue possibly related to
>>> the *vga_text* mode. If I put a proprietary AMI BIOS, GRUB2 works
>>> without issue in gfxterm mode and boots Linux without issue.
>>>
>>> Using Coreboot every time the screen gets full of text, GRUB2
>>> re-executes. If I though set the terminal_output to cbmemc then commands
>>> would execute but Linux still fails to execute - at the end GRUB2 would
>>> restart.
>>>
>>> Also the GRUB2 payload on Coreboot does see the drive/files and attempts
>>> to execute - I looks like a GRUB2/Coreboot config/code problem.
>>>
>>> I execute the below in GRUB2 (which work on AMI BIOS + GRUB2).
>>> grub> set root=(hd0,gpt2)
>>> grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda2
>>> grub> initrd /boot/initrd.img-3.13.0-29-generic
>>> grub> boot
>>>
>>> 1. Would anyone have any recommendation about the overflow in GRUB2
>>> payload ? - related to Coreboot.
>>> 2. Any suggestions on booting Linux given this board's limitations on
>>> output (HDMI only) ?
>>>
>>> Thank you,
>>> Grigore
>>>
>>> --
>>> coreboot mailing list: coreboot(a)coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>
I'm also ok with text protobufs. My only request is that we do not use
binary blobs or XML.
Here's one .json from Harvey, defining rules for libraries. It has some
arrays, and shows the use of structure. Seems simple enough to me.
My assumption is that this would be parsed by a user level program, not
firmware or kernel.
If you're going to pick a format, pick a simple one with lots of parser
implementations in lots of languages and which is easy to read (I find this
easy to read).
{
"Libs": {
"Include": [
"/$ARCH/include/cflags.json"
],
"Oflags": [
"-static"
],
"Post": [
"rm -f *.o"
],
"Pre": [
"rm -f *.o *.tag.*"
]
}
}
On Mon, Nov 28, 2016 at 1:15 PM David Hendricks via coreboot <
coreboot(a)coreboot.org> wrote:
> On Mon, Nov 28, 2016 at 12:40 PM, Peter Stuge <peter(a)stuge.se> wrote:
>
> David Hendricks via coreboot wrote:
> > On Sun, Nov 27, 2016 at 8:28 PM, ron minnich <rminnich(a)gmail.com> wrote:
> > > I like the idea of JSON file
> >
> > Now we're talkin' - A standardized data format that is human
> > readable/writeable that can be easily parsed and generated using
> > small libraries.
>
> I agree with the concept as described by David, but strongly disagree
> with choosing JSON. I think we can and should do better than that.
>
>
> That was my initial reaction as well. But if you check out some examples
> it really doesn't seem bad especially if we restrict ourselves to a subset
> of JSON. Here's a simple example using key:value pairs (from
> http://www.w3schools.com/js/js_json_intro.asp):
> {"employees":[
> {"firstName":"John", "lastName":"Doe"},
> {"firstName":"Anna", "lastName":"Smith"},
> {"firstName":"Peter", "lastName":"Jones"}
> ]}
>
> The page for jsmn notes that it explicitly does not support "advanced"
> functionality that does not map well to C. I'm not sure exactly what this
> implies (presumably the above example is OK), but it seems worth
> investigating if it suits our needs and enables us to use existing
> standards and libraries.
>
> Ron - If you get a chance, can you post a sample JSON file from u-root?
>
> > given that CMOS might not exist on a particular platform
> > (especially in the non-x86 world)
>
> Maybe no NVRAM, but surely there will be persistent storage on board?
>
>
> Implementation-defined. I'm sure it exists on some designs, but in general
> non-x86 board vendors don't add additional nonvolatile storage unless they
> really have a specific purpose for it. Even if they add a serial EEPROM or
> some such, it's not necessarily trivial to access like CMOS on x86
> platforms. IMO the only persistent storage we can depend upon is the
> persistent storage that coreboot resides on. Everything else is nice to
> have but should not be a hard requirement.
>
> I suppose this could be another parameter exposed in the config file in
> CBFS. For example, if a key "nonvolatile-storage" has value "cmos" then the
> tools know we need to look at cmos.layout and write boot device priority
> using CMOS-methods. We currently do something similar to this on ChromeOS
> devices to tell where verified boot data is stored (CMOS, embedded
> controller, SPI ROM, etc).
>
> --
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
David Hendricks via coreboot wrote:
> On Sun, Nov 27, 2016 at 8:28 PM, ron minnich <rminnich(a)gmail.com> wrote:
> > I like the idea of JSON file
>
> Now we're talkin' - A standardized data format that is human
> readable/writeable that can be easily parsed and generated using
> small libraries.
I agree with the concept as described by David, but strongly disagree
with choosing JSON. I think we can and should do better than that.
Firmware design decisions centered around Golang are about as good as
firmware design decisions centered around Forth.
Let's not create another public interface in a rush, as we have with
NVRAM. Let's take the time to actually design something really well.
> given that CMOS might not exist on a particular platform
> (especially in the non-x86 world)
Maybe no NVRAM, but surely there will be persistent storage on board?
//Peter
On Sun, Nov 27, 2016 at 8:28 PM, ron minnich <rminnich(a)gmail.com> wrote:
> yeah, david and nico both make very good points. I like the idea of JSON
> file, and further we're working on a Go program
> on the u-root project that would parse said file (trivial in Go to parse
> JSON, it's one statement and blam! your Go struct is all
> filled in) and then decide what to configure/what to download/how to
> validate (we have a gpgv command written in Go by
> Eric Grosse) and then how to kexec it.
>
> I think what we're doing might be useful?
>
Now we're talkin' - A standardized data format that is human
readable/writeable that can be easily parsed and generated using small
libraries. It looks like Go can already handle it easily, for C we could
maybe use JSMN (http://zserge.com/jsmn.html) or something similar. I think
that addresses Nico's first point.
For the other points, I imagine we'd have two varieties of the JSON file.
One would be generated along with the payload and included as a CBFS file
to specify things like capabilities and bootable device priority*. The
other would be on the bootable media and specify things like the kernel
path and parameters. A tool which is used to generate the latter would
verify the capabilities and warn the user if their coreboot payload lacks
support for something.
*Stuff like boot device priority might need some more thought since CMOS
may be a preferable way of controlling something like that. However given
that CMOS might not exist on a particular platform (especially in the
non-x86 world) replacing the config file in CBFS file might not be a bad
way to go.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
Hello Zoran,
[1-3] I am using the latest Ubuntu 16.04 LTS x64 desktop, 4.4 kernel.
[4] I don't know exactly if it's x64 or x86. I have no control over AMI
BIOS since it's just a binary I flash into the SPI ROM, which supports the
board.
[5] I boot Linux using legacy mode (in AMI, the Linux was installed for
legacy boot on the HDD/SSD which connects via USB - USBtoSATA)
[6] I'm not sure. So I have the following checked:
- Run VGA Option ROMs, Native Mode
- Add a VGA BIOS image -> 3rdparty/blobs.../VBIOS.bin
- Set framebuffer resolution (any, without this + above, I have no HDMI
output)
[7] It's the same one referenced from Coreboot in the external payloads -
GRUB 2.02 beta3.
>From your view where would the overflow / boot problems come from ?
Thank you,
Grigore
On Mon, Nov 28, 2016 at 6:31 PM, Zoran Stojsavljevic <
zoran.stojsavljevic(a)gmail.com> wrote:
> Hello Grigore,
>
> I have here some dummy questions (forgive me for my ignorance), but I need
> to ask them just for the sake of curiosity (maybe, after all, we can get
> somewhere if I articulate questions in the right direction/right format for
> this problem):
>
> > If I put a proprietary AMI BIOS, GRUB2 works without issue in gfxterm
> mode and boots Linux without issue.
>
> [1] What Linux architecture are you using (32 or 64)?
> [2] Which Linux distro?
> [3] Which kernel version?
>
> If you put AMI BIOS, the following questions I would like to know:
>
> [4] Are you using 32 or 64 BIOS?
> [5] Which mode are you using for booting (legacy/CSM ON or UEFI/CSM OFF)?
> [6] In the accordance with [5], what video component you have set with
> CMOS: vBIOS or GOP driver?
>
> Not sure, but it seems to me that you are using too old/outdated GRUB2
> version (or maybe I am also mistaken)?
> [7] Could you tell us, which GRUB2 version you are using?
>
> Thank you,
> Zoran
>
> On Mon, Nov 28, 2016 at 7:13 PM, Grigore Lupescu via coreboot <
> coreboot(a)coreboot.org> wrote:
>
>> Hello,
>>
>> I am trying to run Linux through the GRUB2 payload. I am not tied to
>> GRUB2 but it's the only payload that gives me HDMI output (board has no
>> serial port) using Coreboot and AMD FT3B-LC.
>>
>> I have the latest Coreboot sources, have set config accordingly (e.g.
>> CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="DB-FT3b-LC"...), getting an image
>> on HDMI and the GRUB2 payload is executing.
>> In GRUB2 payload I seem to have an overflow issue possibly related to the
>> *vga_text* mode. If I put a proprietary AMI BIOS, GRUB2 works without
>> issue in gfxterm mode and boots Linux without issue.
>>
>> Using Coreboot every time the screen gets full of text, GRUB2
>> re-executes. If I though set the terminal_output to cbmemc then commands
>> would execute but Linux still fails to execute - at the end GRUB2 would
>> restart.
>>
>> Also the GRUB2 payload on Coreboot does see the drive/files and attempts
>> to execute - I looks like a GRUB2/Coreboot config/code problem.
>>
>> I execute the below in GRUB2 (which work on AMI BIOS + GRUB2).
>> grub> set root=(hd0,gpt2)
>> grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda2
>> grub> initrd /boot/initrd.img-3.13.0-29-generic
>> grub> boot
>>
>> 1. Would anyone have any recommendation about the overflow in GRUB2
>> payload ? - related to Coreboot.
>> 2. Any suggestions on booting Linux given this board's limitations on
>> output (HDMI only) ?
>>
>> Thank you,
>> Grigore
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
Hello Grigore,
I have here some dummy questions (forgive me for my ignorance), but I need
to ask them just for the sake of curiosity (maybe, after all, we can get
somewhere if I articulate questions in the right direction/right format for
this problem):
> If I put a proprietary AMI BIOS, GRUB2 works without issue in gfxterm
mode and boots Linux without issue.
[1] What Linux architecture are you using (32 or 64)?
[2] Which Linux distro?
[3] Which kernel version?
If you put AMI BIOS, the following questions I would like to know:
[4] Are you using 32 or 64 BIOS?
[5] Which mode are you using for booting (legacy/CSM ON or UEFI/CSM OFF)?
[6] In the accordance with [5], what video component you have set with
CMOS: vBIOS or GOP driver?
Not sure, but it seems to me that you are using too old/outdated GRUB2
version (or maybe I am also mistaken)?
[7] Could you tell us, which GRUB2 version you are using?
Thank you,
Zoran
On Mon, Nov 28, 2016 at 7:13 PM, Grigore Lupescu via coreboot <
coreboot(a)coreboot.org> wrote:
> Hello,
>
> I am trying to run Linux through the GRUB2 payload. I am not tied to GRUB2
> but it's the only payload that gives me HDMI output (board has no serial
> port) using Coreboot and AMD FT3B-LC.
>
> I have the latest Coreboot sources, have set config accordingly (e.g.
> CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="DB-FT3b-LC"...), getting an image
> on HDMI and the GRUB2 payload is executing.
> In GRUB2 payload I seem to have an overflow issue possibly related to the
> *vga_text* mode. If I put a proprietary AMI BIOS, GRUB2 works without
> issue in gfxterm mode and boots Linux without issue.
>
> Using Coreboot every time the screen gets full of text, GRUB2 re-executes.
> If I though set the terminal_output to cbmemc then commands would execute
> but Linux still fails to execute - at the end GRUB2 would restart.
>
> Also the GRUB2 payload on Coreboot does see the drive/files and attempts
> to execute - I looks like a GRUB2/Coreboot config/code problem.
>
> I execute the below in GRUB2 (which work on AMI BIOS + GRUB2).
> grub> set root=(hd0,gpt2)
> grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda2
> grub> initrd /boot/initrd.img-3.13.0-29-generic
> grub> boot
>
> 1. Would anyone have any recommendation about the overflow in GRUB2
> payload ? - related to Coreboot.
> 2. Any suggestions on booting Linux given this board's limitations on
> output (HDMI only) ?
>
> Thank you,
> Grigore
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
Hello,
I am trying to run Linux through the GRUB2 payload. I am not tied to GRUB2
but it's the only payload that gives me HDMI output (board has no serial
port) using Coreboot and AMD FT3B-LC.
I have the latest Coreboot sources, have set config accordingly (e.g.
CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="DB-FT3b-LC"...), getting an image on
HDMI and the GRUB2 payload is executing.
In GRUB2 payload I seem to have an overflow issue possibly related to the
*vga_text* mode. If I put a proprietary AMI BIOS, GRUB2 works without issue
in gfxterm mode and boots Linux without issue.
Using Coreboot every time the screen gets full of text, GRUB2 re-executes.
If I though set the terminal_output to cbmemc then commands would execute
but Linux still fails to execute - at the end GRUB2 would restart.
Also the GRUB2 payload on Coreboot does see the drive/files and attempts to
execute - I looks like a GRUB2/Coreboot config/code problem.
I execute the below in GRUB2 (which work on AMI BIOS + GRUB2).
grub> set root=(hd0,gpt2)
grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda2
grub> initrd /boot/initrd.img-3.13.0-29-generic
grub> boot
1. Would anyone have any recommendation about the overflow in GRUB2 payload
? - related to Coreboot.
2. Any suggestions on booting Linux given this board's limitations on
output (HDMI only) ?
Thank you,
Grigore
Dear Sir.
My env is see below.
board : Intel rangeley MOHON PEAK.(CPU is C2358)
I was success boot coreboot + SeaBIOS.
This time, I'm try to boot coreboot + u-boot(16.05).
But u-boot is every time fail. log is see below.
U-Boot 2016.05-rc3 (Nov 28 2016 - 17:04:31 +0900)
CPU: x86_64, vendor Intel, device 406d8h
DRAM: 4 GiB
dm_pci_hose_probe_bus: Internal error, bus 'pch@1,0' got seq 0,
expected 1
Using default environment
Video: No video mode configured in coreboot!
Model: QEMU x86 (I440FX)
dm_pci_hose_probe_bus: Internal error, bus 'pch@1,0' got seq 0,
expected 1
initcall sequence 7fc59100 failed at call 01110185 (err=-32)
### ERROR ### Please RESET the board ###
Every time occured fail on the *interrupt_init().*
But I don't have a solution.
I was attached the config of corebooe and u-boot.
Please advise to me.
Thank you.
