[coreboot] Does coreboot table still exist in F000 segment?

[WANG FEI]

Hi, all

Beside placing coreboot table (lb_header) in low RAM (0x0-0x1000), I
remember a copy of coreboot table should be placed at F000 segment and it
can be controlled with a Kconfig flag, does this feature still exist? I
just can't find it right now.

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

Re: [coreboot] 64 UEFI payload boot fail on Denverton platform but 32 UEFI payload works

[WANG FEI]

I can confirm coreboot has no issue to support 64 bit UEFI payload, it's
already verified.

Can you please provide more information of your coreboot/payload? Like,
coreboot revision/commit ID, payload revision/commid ID, FSP revision,
platform details (CRB or OEM platform) etc.

On Thu, Sep 21, 2017 at 10:20 AM, Melissa Yi  wrote:

> Hi
>I want to know whether coreboot supports 64bit UEFI payload on
> denverton platform?
>Attached the fail log.
>
> Thanks.
>
> Regards,
> Melissa Yi
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to change config of SDRAM of intel mohonpeak EVB on coreboot?

[WANG FEI]

YuSeok,

It looks your platform has enabled the Memory Down function.

The MEM_DOWN_DIMM_SPD_DATA structure supposed to be filled with the
relative DIMM SPD data as described in comments, for example,

DRAMDeviceType =>>> SPD Byte Offset 2
ModuleType  =>>> SPD Byte offset 3
DramManufacturerIdLsb =>>> SPD Byte offset 148


To have a look at below links to understand the DDR3's SPD details.

http://www.simmtester.com/page/news/showpubnews.asp?num=153

https://www.google.com/url?sa=t=j==s=web=3=rja=8=0ahUKEwiMxt_PzrfNAhVQF8AKHQfkAJ8QFgg3MAI=https%3A%2F%2Fwww.micron.com%2F~%2Fmedia%2Fdocuments%2Fproducts%2Ftechnical-note%2Fdram-modules%2Ftn_04_42.pdf=AFQjCNEBeya4qkEodTkCc1eEjuK5Qdz0YA=S9r0YXabVNhpO_UfzJqNpQ=bv.125221236,d.ZGg

On Wed, Jun 1, 2016 at 7:53 AM, 김유석  wrote:

> Dear Sir.
>
> My own product must need a change the value(config) of sdram. Such as
> size, speed, and etc.
>
>
> So, I'm try to search and study the coreboot source code, and found out
> the "vendorcode/intel/fsp1_0/rangeley/include/fspplatform.h"
>
>
> This header are contained the some structure for setup the sdram. such as
> "MEM_DOWN_DIMM_SPD_DATA;"
>
>
>  50 typedef struct {
>  51   UINT8  DRAMDeviceType; // 2   DRAM Device Type
>  52   UINT8  ModuleType; // 3   Module Type
>  53   UINT8  SDRAMDensityAndBanks;   // 4   SDRAM Density and Banks
>  54   UINT8  SDRAMAddressing;// 5   SDRAM Addressing
>  55   UINT8  VDD;// 6   Module Nominal Voltage
>  56   UINT8  ModuleOrganization; // 7   Module Organization
>  57   UINT8  ModuleMemoryBusWidth;
>
>  94   UINT8  DramManufacturerIdLsb;  // 148 DRAM Manufacturer ID
> Code, LSB
>  95   UINT8  DramManufacturerIdMsb;  // 149 DRAM Manufacturer ID
> Code, MSB
>  96 } MEM_DOWN_DIMM_SPD_DATA;
>
>
>
> So, I'm try to found **.c* source codes for check configuration point.
>
> But, coreboot are not setup the argument of sdram.
>
> I don't understand this sisution, Because sdram is must need a some
> configuration for use.
>
>
> *Why? do not setup the argument of sd*
>
> *ram ??? *
> Please advise to me.
>
> Thank you.
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How can extract descriptor.bin from bios image?

[WANG FEI]

Looking at the logs you've got, the final bios only have BIOS/coreboot and
descriptor.bin, the GbE/ME areas are not used, I think as long as your
enable the descripor.bin, it should be good enough.

  poplinux@raw rangeley $ > ./tools/ifdtool -x ./oem_dumped.bin
  File ./oem_dumped.bin is 8388608 bytes
Flash Region 0 (Flash Descriptor):  - 
Flash Region 1 (BIOS): 0001 - 007f
Flash Region 2 (Intel ME): 00fff000 - 0fff* (unused)*
Flash Region 3 (GbE): 00fff000 - 0fff *(unused)*
Flash Region 4 (Platform Data): 00fff000 - 0fff* (unused)*

On Mon, Jun 20, 2016 at 3:16 AM, 김유석  wrote:

> Dear Sir.
>
> Thank's your advise. It is very useful to me.
>
> My work log is see below.
>
>   poplinux@raw rangeley $ > ./tools/ifdtool -x ./oem_dumped.bin
>   File ./oem_dumped.bin is 8388608 bytes
> Flash Region 0 (Flash Descriptor):  - 
> Flash Region 1 (BIOS): 0001 - 007f
> Flash Region 2 (Intel ME): 00fff000 - 0fff* (unused)*
> Flash Region 3 (GbE): 00fff000 - 0fff *(unused)*
> Flash Region 4 (Platform Data): 00fff000 - 0fff* (unused)*
>
> *The Flash Region 2~3 is (unused). Is it corrent?*
>
>
> And descriptor.bin's content is see below.
>
> poplinux@raw rangeley $ > ./tools/ifdtool -d ./descriptor.bin
> File ./descriptor.bin is 65536 bytes
> FD signature Offset 0x10
> FD signature Offset 0x10
> FLMAP0:0x01040003
>   NR:  1
>   FRBA:0x40
>   NC:  1
>   FCBA:0x30
> FLMAP1:0x09100206
>   ISL: 0x09
>   FPSBA:   0x100
>   NM:  2
>   FMBA:0x60
> FLMAP2:0x00210020
>   PSL: 0x2100
>   FMSBA:   0x200
> FLUMAP1:   0x02e0
>   Intel ME VSCC Table Length (VTL):2
>   Intel ME VSCC Table Base Address (VTBA): 0x000e00
>
> ME VSCC table:
>   JID0:  0x001740ef
> SPI Componend Device ID 1:  0x17
> SPI Componend Device ID 0:  0x40
> SPI Componend Vendor ID:0xef
>   VSCC0: 0x20052005
> Lower Erase Opcode: 0x20
> Lower Write Enable on Write Status: 0x50
> Lower Write Status Required:No
> Lower Write Granularity:64 bytes
> Lower Block / Sector Erase Size:4KB
> Upper Erase Opcode: 0x20
> Upper Write Enable on Write Status: 0x50
> Upper Write Status Required:No
> Upper Write Granularity:64 bytes
> Upper Block / Sector Erase Size:4KB
>
> OEM Section:
> 00: 31 31 35 32 31 35 30 39 32 30 00 00 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> Found Region Section
> FLREG0:0x000f
>   Flash Region 0 (Flash Descriptor):  - 
> FLREG1:0x07ff0010
>   Flash Region 1 (BIOS): 0001 - 007f
> FLREG2:0x0fff
>   Flash Region 2 (Intel ME): 00fff000 - 0fff (unused)
> FLREG3:0x0fff
>   Flash Region 3 (GbE): 00fff000 - 0fff (unused)
> FLREG4:0x0fff
>   Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
>
> Found Component Section
> FLCOMP 0x09200024
>   Dual Output Fast Read Support:   not supported
>   Read ID/Read Status Clock Frequency: 33MHz
>   Write/Erase Clock Frequency: 33MHz
>   Fast Read Clock Frequency:   33MHz
>   Fast Read Support:   not supported
>   Read Clock Frequency:20MHz
>   Component 2 Density: 8MB
>   Component 1 Density: 8MB
> FLILL  0x
>   Invalid Instruction 3: 0x00
>   Invalid Instruction 2: 0x00
>   Invalid Instruction 1: 0x00
>   Invalid Instruction 0: 0x00
> FLPB   0x
>   Flash Partition Boundary Address: 0x00
>
> Found PCH Strap Section
> PCHSTRP0:  0x00080002
> PCHSTRP1:  0x
> PCHSTRP2:  0x
> PCHSTRP3:  0x0003
> PCHSTRP4:  0x007f
> PCHSTRP5:  0x007fffc0
> PCHSTRP6:  0x0001c7c0
> PCHSTRP7:  0x0624
> PCHSTRP8:  0x
> PCHSTRP9:  0x
> PCHSTRP10: 0x
> PCHSTRP11: 0x
> PCHSTRP12: 0x
> PCHSTRP13: 0x
> PCHSTRP14: 0x
> PCHSTRP15: 0x
> PCHSTRP16: 0x
> PCHSTRP17: 0x
>
> Found Master Section
> FLMSTR1:   0x1f1f (Host CPU/BIOS)
>   Platform Data Region Write Access: enabled
>   GbE Region Write Access:   enabled
>   Intel ME Region Write Access:  enabled
>   Host CPU/BIOS Region Write Access: enabled
>   Flash Descriptor Write Access: enabled
>   Platform Data Region Read Access:  enabled
>   GbE Region Read Access:enabled
>   Intel ME Region Read Access:   enabled
>   Host CPU/BIOS Region Read Access:  enabled
>   Flash Descriptor Read Access:  enabled
>   Requester ID:  0x
>
> FLMSTR2:   0x08090118 (Intel ME)
>   Platform Data Region Write Access: disabled
>   GbE Region Write Access:   enabled
>   Intel ME 

Re: [coreboot] The GbE is not activated on my Board.

[WANG FEI]

Here is a sample,

Please select INCLUDE_ME to y and set ME_PATH to point to your
descriptor.bin (Path/descriptor.bin, refer to FSP_FILE as a sample).

On Mon, Jun 20, 2016 at 10:48 PM, WANG FEI <wangfei.ji...@gmail.com> wrote:

> YuSeok, how did you attach the descriptor.bin to your coreboot? Did you
> follow the previous mail to include descriptor.bin with INCLUDE_ME and
> ME_PATH in .config?
>
> On Mon, Jun 20, 2016 at 6:46 AM, 김유석 <poplin...@gmail.com> wrote:
>
>> Dear Sir.
>>
>>
>> My ENV
>>
>>   EVB : ADI SG-2440
>>
>>   source : official coreboot
>>
>>   FSP : intel FSP 4.0
>>
>>
>>
>> I was successfully build-up the coreboot and successfully boot-up my EVB.
>>
>>
>> But My EVB's GbE is not activated(not running.)
>>
>>
>> So, I was try to boot using the original OEM bios(from ADI). *This image
>> is **act**vate the GbE*.
>>
>>
>> Another developer was same quetion to Coreboot communite. And He is
>> resolved this issue.
>>
>> <https://www.coreboot.org/pipermail/coreboot/2015-January/079074.html>
>> https://www.coreboot.org/pipermail/coreboot/2015-January/079074.html
>>
>>
>> This guy's said that "Must add the descriptor.bin to coreboot.bin".
>>
>>
>> So, I was extract the descriptor.bin from ADI's coreboot.bin
>>
>> And successfully attached the descriptor.bin to my coreboot.bin.
>>
>>   *oem_dumped.bin => ADI's default **coreboot.bin, This image are
>> activated the GbE.*
>>
>>   *poplinux@raw bins $ >* ./ifdtool -x src/oem_dumped.bin
>>   File src/oem_dumped.bin is 8388608 bytes
>> Flash Region 0 (Flash Descriptor):  - 
>> Flash Region 1 (BIOS): 0001 - 007f
>> Flash Region 2 (Intel ME): 00fff000 - 0fff (unused)
>> Flash Region 3 (GbE): 00fff000 - 0fff (unused)
>> Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
>>
>>   *poplinux@raw bins $ >* ln -s ./flashregion_0_flashdescriptor.bin
>> descriptor.bin
>>   *poplinux@raw bins $ >* ./ifdtool -d ./descriptor.bin
>>   File ./descriptor.bin is 65536 bytes
>>   FLMAP0:0x01040003
>> NR:  1
>> FRBA:0x40
>> NC:  1
>> FCBA:0x30
>>   FLMAP1:0x09100206
>> ISL: 0x09
>> FPSBA:   0x100
>> NM:  2
>> FMBA:0x60
>>   FLMAP2:0x00210020
>> PSL: 0x2100
>> FMSBA:   0x200
>>   FLUMAP1:   0x02e0
>> Intel ME VSCC Table Length (VTL):2
>> Intel ME VSCC Table Base Address (VTBA): 0x000e00
>>
>>   ME VSCC table:
>> JID0:  0x001740ef
>>   SPI Componend Device ID 1:  0x17
>>   SPI Componend Device ID 0:  0x40
>>   SPI Componend Vendor ID:0xef
>> VSCC0: 0x20052005
>>   Lower Erase Opcode: 0x20
>>   Lower Write Enable on Write Status: 0x50
>>   Lower Write Status Required:No
>>   Lower Write Granularity:64 bytes
>>   Lower Block / Sector Erase Size:4KB
>>   Upper Erase Opcode: 0x20
>>   Upper Write Enable on Write Status: 0x50
>>   Upper Write Status Required:No
>>   Upper Write Granularity:64 bytes
>>   Upper Block / Sector Erase Size:4KB
>>
>>   OEM Section:
>>   00: 31 31 35 32 31 35 30 39 32 30 00 00 00 00 00 00
>>   10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>
>>   Found Region Section
>>   FLREG0:0x000f
>> Flash Region 0 (Flash Descriptor):  - 
>>   FLREG1:0x07ff0010
>> Flash Region 1 (BIOS): 0001 - 007f
>>   FLREG2:0x0fff
>> Flash Region 2 (Intel ME): 00fff000 - 0fff (unused)
>>   FLREG3:0x0fff
>> Flash Region 3 (GbE): 00fff000 - 0fff (unused)
>>   FLREG4:0x0fff
>> Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
>>
>>   Found Component Section
>>   FLCOMP 0x09200024
>> Dual Output Fast Read Support:   not supported
>> Read ID/Read Status Clock Frequency: 33MHz
>> Write/Erase Clock Frequency: 33MHz
>> Fast Read Clock Frequency:   33MHz
>> Fast Read Support:   not supported
>> Read Clock Frequency:20MHz
>> Compon

Re: [coreboot] bootfail on my Mohon Peak CRB.

[WANG FEI]

It's great to hear this! Thanks sharing the knowledge with coreboot
community, enjoy your coreboot/FSP journey.

On Tue, May 17, 2016 at 2:39 AM, 김유석 <poplin...@gmail.com> wrote:

> Dear Sir.
>
> Thank's your advise.
>
> I was solved this issue.
>
> The cause was "Image size".
>
> My spi flash is have a 16MByte size. and coreboot.rom's size is a 2MByte.
>
> And I was write from 0x00. But x86 is must write from bottom. I guess.
>
>
> *For example*
>
> case 1.
>   coreboot image : 2MByte
>   flash storage : 16MByte
>
>   You must write start address is 0x00E0(offset 14MByte)
>
> case 2.
>   coreboot image : 8MByte
>   flash storage : 16MByte
>
>   You must write start address is 0x0080(offset 8MByte)
>
> case 3.
>   coreboot image : 16MByte
>   flash storage : 16MByte
>
>   You must write start address is 0x00000000(offset 0MByte)
>
>
> This time, coreboot work is very fine.
>
> Thank you.
>
> 2016-02-04 오후 11:02에 WANG FEI 이(가) 쓴 글:
>
> *RANGELEY_POSTGOLD4_FSP_004_20150924.fd is the FSP binary, you can rename
> it to FvFsp.bin and placed it to the path defined in coreboot, ie, *
> `../intel/fsp/rangeley/Fv*, to generate coreboot image.*
>
> On Thu, Feb 4, 2016 at 5:19 AM, 김유석 <poplin...@gmail.com> wrote:
>
>> Dear Martin.
>>
>> Thank's your advise.
>>
>> I'm use the serial consol port. but can't see any message.
>>
>> Thank you.
>>
>> 2016-02-02 오후 9:18에 Martin Roth 이(가) 쓴 글:
>>
>> You might try a different video card. There's an issue in the video bios
>> of the aspeed card that came with the mohon peak.
>>
>> martin
>> On Tue, Feb 2, 2016 at 00:41 김유석 <poplin...@gmail.com> wrote:
>>
>>> Dear sir.
>>>
>>> My ENV is see below.
>>>
>>>   *EVB : Intel rangeley Mohon Peak CRB*
>>>
>>>
>>> This time, I was download the coreboot from git.
>>>
>>>   poplinux@raw work $ > git clone
>>> http://review.coreboot.org/coreboot.git ./
>>>   poplinux@raw work $ > cd coreboot
>>>   poplinux@raw coreboot $ > git submodule update --init --checkout
>>>
>>> Next, *run make menuconfig* and set-up to mohon peak CRB and save & exit
>>>
>>>  * Mainboa**rd*
>>>Mainboard vendor (*Intel*)  --->
>>>Mainboard model (*Mohon Peak CRB*)  --->
>>>[ ] Configure defaults for the Intel FSP package
>>>ROM chip size (2048 KB (2 MB))  --->
>>>(0x0020) Size of CBFS filesystem in ROM
>>>()  fmap description file in fmd format
>>>
>>> Next, I'm try to build core boot.
>>>
>>>   poplinux@raw coreboot $ > make
>>> GENgenerated/bootblock.ld
>>> CP bootblock/arch/x86/bootblock.ld
>>> LINK   cbfs/fallback/bootblock.debug
>>> OBJCOPYcbfs/fallback/bootblock.elf
>>> OBJCOPYbootblock.raw.bin
>>> Checking out SeaBIOS revision
>>> 01a84bea2d28a19d2405c1ecac4bdef17683cc0c
>>> Switched to branch 'master'
>>>
>>>   Performing operation on 'COREBOOT' region...
>>>   Name   Offset Type Size
>>>   cbfs master header 0x0cbfs header  32
>>>   fallback/romstage  0x80   stage22684
>>>   cpu_microcode_blob.bin 0x5980 microcode0
>>>   config 0x5a00 raw  127
>>>   revision   0x5ac0 raw  570
>>>   cmos_layout.bin0x5d40 cmos_layout  1316
>>>   fallback/dsdt.aml  0x62c0 raw  7952
>>>   payload_config 0x8240 raw  1574
>>>   payload_revision   0x88c0 raw  237
>>>   (empty)0x8a00 null 29848
>>>   mrc.cache  0xfec0 mrc_cache65536
>>>   fallback/ramstage  0x1ff00stage46922
>>>   fallback/payload   0x2b6c0payload  61122
>>>   (empty)0x3a5c0null 1856216
>>>   bootblock  0x1ff8c0   bootblock1528
>>>
>>> Finally, I'm got a coreboot image.
>>>
>>>
>>>   poplinux@raw build $ > ls build/coreboot.rom
>>>   build/coreboot.rom
>>>   poplinux@raw build $ > ./build/cbfstool build/coreboot.rom print
>>>   Performing operation on 'COREBOOT' region..

Re: [coreboot] Question about Intel's documentation notations

[WANG FEI]

xxH - xx means these two numbers could be a hex number from 00 - FF, which
is depend on the SoC/processors.

On Mon, May 9, 2016 at 4:25 PM, Rafael Machado <
rafaelrodrigues.mach...@gmail.com> wrote:

> Make sense. Now I saw the notes. Stupid question, sorry.
>
> That about the *xx*H ?
>
> Thanks for the fast response.
> Rafael
>
> Em seg, 9 de mai de 2016 às 12:23, ron minnich 
> escreveu:
>
>> H means hex, they do that instead of 0x.
>> 2 is footnote 2.
>>
>> The whole H thing goes back 45 years or so and was a failure of vision,
>> AH is a register name and a constant. As are bc, ch, and dh. oops.
>>
>> ron
>> On Mon, May 9, 2016 at 8:19 AM Rafael Machado <
>> rafaelrodrigues.mach...@gmail.com> wrote:
>>
>>> Hi everyone
>>>
>>> I'm taking a look at the Intel developers guide and there is a notation
>>> there that I didn't understand.
>>>
>>> [image: pasted1]
>>>
>>> Since there are several guys with more experience here, probably someone
>>> can help me. This is the table with the default values of the registers
>>> after a system reset, from Intel Developers Guide, page 2285.
>>>
>>> That does the "H2" means at the attached picture ?
>>> And what toes the xxH3 means too ?
>>>
>>> Thanks and Regards
>>> Rafael R. Machado
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] A talk about coreboot

[WANG FEI]

Wow, Iru, it's a great presentation, I bet you have spent quite a lot time
to make it happen.

I'm excited more contributors from China too, I noticed some Chinese
companies have deployed coreboot/FSP on their platform in recent years, I
would like to encourage them involving in the coreboot community.

It might be too late to have the suggestions now, but it should be always
useful in the future.

1. I would suggest you emphasis coreboot can support different CPU, such as
IA/ARM/ARM64/MIPS/Power8 etc.
2. Intel FSP/microcode is free now, go to www.intel.com/fsp, you would be
able to download the different FSP products there. Also the FSP spec is
published now, the latest FSP spec is 1.1a,
http://www.intel.co.uk/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1.pdf
&
http://www.intel.co.uk/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1a.pdf
.

-Fei

On Sun, Apr 10, 2016 at 4:03 PM, Iru Cai  wrote:

>
>
> On Sun, Apr 10, 2016 at 8:53 PM, Stefan Tauner 
> wrote:
>
>> On Sun, 10 Apr 2016 01:45:03 +0800
>> Iru Cai  wrote:
>>
>> > Hi community,
>> >
>> > I gave a talk about coreboot in my LUG yesterday, and here's my
>> > slides.
>> >
>> > https://bdwm.net/attach/boards/Linux/M.1460223002.A/coreboot-talk.pdf
>>
>> Hi Iru,
>>
>> I'll do a very similar talk in two weeks. Can I please re-use some of
>> your stuff under a CC BY-SA license?
>> https://creativecommons.org/licenses/by-sa/4.0/
>>
>> Well, I wrote a CC license in my source file, but not in the slides.
>
> https://bdwm.net/attach/boards/Linux/M.1460223002.A/coreboot%2dtalk.src.tar.gz
>
>
>> --
>> Kind regards/Mit freundlichen Grüßen, Stefan Tauner
>>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] bootfail on my Mohon Peak CRB.

[WANG FEI]

If your platform still does not boot up, I would suggest you check the SoC
revision on your platform with the microcode revision of your coreboot,
these two revisions should be matched, if not, system will halt in a every
early stage.

Another possibility you should consider is that if the UART configuration
of your board, if it's wrong, you definitely will not have any output on
serial console.

On Thu, Feb 4, 2016 at 2:02 PM, WANG FEI <wangfei.ji...@gmail.com> wrote:

> *RANGELEY_POSTGOLD4_FSP_004_20150924.fd is the FSP binary, you can rename
> it to FvFsp.bin and placed it to the path defined in coreboot, ie, *
> `../intel/fsp/rangeley/Fv*, to generate coreboot image.*
>
> On Thu, Feb 4, 2016 at 5:19 AM, 김유석 <poplin...@gmail.com> wrote:
>
>> Dear Martin.
>>
>> Thank's your advise.
>>
>> I'm use the serial consol port. but can't see any message.
>>
>> Thank you.
>>
>> 2016-02-02 오후 9:18에 Martin Roth 이(가) 쓴 글:
>>
>> You might try a different video card. There's an issue in the video bios
>> of the aspeed card that came with the mohon peak.
>>
>> martin
>> On Tue, Feb 2, 2016 at 00:41 김유석 < <poplin...@gmail.com>
>> poplin...@gmail.com> wrote:
>>
>>> Dear sir.
>>>
>>> My ENV is see below.
>>>
>>>   *EVB : Intel rangeley Mohon Peak CRB*
>>>
>>>
>>> This time, I was download the coreboot from git.
>>>
>>>   poplinux@raw work $ > git clone
>>> <http://review.coreboot.org/coreboot.git>
>>> http://review.coreboot.org/coreboot.git ./
>>>   poplinux@raw work $ > cd coreboot
>>>   poplinux@raw coreboot $ > git submodule update --init --checkout
>>>
>>> Next, *run make menuconfig* and set-up to mohon peak CRB and save & exit
>>>
>>>  * Mainboa**rd*
>>>Mainboard vendor (*Intel*)  --->
>>>Mainboard model (*Mohon Peak CRB*)  --->
>>>[ ] Configure defaults for the Intel FSP package
>>>ROM chip size (2048 KB (2 MB))  --->
>>>(0x0020) Size of CBFS filesystem in ROM
>>>()  fmap description file in fmd format
>>>
>>> Next, I'm try to build core boot.
>>>
>>>   poplinux@raw coreboot $ > make
>>> GENgenerated/bootblock.ld
>>> CP bootblock/arch/x86/bootblock.ld
>>> LINK   cbfs/fallback/bootblock.debug
>>> OBJCOPYcbfs/fallback/bootblock.elf
>>> OBJCOPYbootblock.raw.bin
>>> Checking out SeaBIOS revision
>>> 01a84bea2d28a19d2405c1ecac4bdef17683cc0c
>>> Switched to branch 'master'
>>>
>>>   Performing operation on 'COREBOOT' region...
>>>   Name   Offset Type Size
>>>   cbfs master header 0x0cbfs header  32
>>>   fallback/romstage  0x80   stage22684
>>>   cpu_microcode_blob.bin 0x5980 microcode0
>>>   config 0x5a00 raw  127
>>>   revision   0x5ac0 raw  570
>>>   cmos_layout.bin0x5d40 cmos_layout  1316
>>>   fallback/dsdt.aml  0x62c0 raw  7952
>>>   payload_config 0x8240 raw  1574
>>>   payload_revision   0x88c0 raw  237
>>>   (empty)0x8a00 null 29848
>>>   mrc.cache  0xfec0 mrc_cache65536
>>>   fallback/ramstage  0x1ff00stage46922
>>>   fallback/payload   0x2b6c0payload  61122
>>>   (empty)0x3a5c0null 1856216
>>>   bootblock  0x1ff8c0   bootblock1528
>>>
>>> Finally, I'm got a coreboot image.
>>>
>>>
>>>   poplinux@raw build $ > ls build/coreboot.rom
>>>   build/coreboot.rom
>>>   poplinux@raw build $ > ./build/cbfstool build/coreboot.rom print
>>>   Performing operation on 'COREBOOT' region...
>>>   Name   Offset Type Size
>>>   cbfs master header 0x0cbfs header  32
>>>   fallback/romstage  0x80   stage22684
>>>   cpu_microcode_blob.bin 0x5980 microcode0
>>>   config 0x5a00 raw  127
>>>   revision   0x5ac0 raw  570
>>>   cmos_layout.bin0x5d40 cmos_layo

Re: [coreboot] bootfail on my Mohon Peak CRB.

[WANG FEI]

*RANGELEY_POSTGOLD4_FSP_004_20150924.fd is the FSP binary, you can rename
it to FvFsp.bin and placed it to the path defined in coreboot, ie, *
`../intel/fsp/rangeley/Fv*, to generate coreboot image.*

On Thu, Feb 4, 2016 at 5:19 AM, 김유석  wrote:

> Dear Martin.
>
> Thank's your advise.
>
> I'm use the serial consol port. but can't see any message.
>
> Thank you.
>
> 2016-02-02 오후 9:18에 Martin Roth 이(가) 쓴 글:
>
> You might try a different video card. There's an issue in the video bios
> of the aspeed card that came with the mohon peak.
>
> martin
> On Tue, Feb 2, 2016 at 00:41 김유석 < 
> poplin...@gmail.com> wrote:
>
>> Dear sir.
>>
>> My ENV is see below.
>>
>>   *EVB : Intel rangeley Mohon Peak CRB*
>>
>>
>> This time, I was download the coreboot from git.
>>
>>   poplinux@raw work $ > git clone
>> 
>> http://review.coreboot.org/coreboot.git ./
>>   poplinux@raw work $ > cd coreboot
>>   poplinux@raw coreboot $ > git submodule update --init --checkout
>>
>> Next, *run make menuconfig* and set-up to mohon peak CRB and save & exit
>>
>>  * Mainboa**rd*
>>Mainboard vendor (*Intel*)  --->
>>Mainboard model (*Mohon Peak CRB*)  --->
>>[ ] Configure defaults for the Intel FSP package
>>ROM chip size (2048 KB (2 MB))  --->
>>(0x0020) Size of CBFS filesystem in ROM
>>()  fmap description file in fmd format
>>
>> Next, I'm try to build core boot.
>>
>>   poplinux@raw coreboot $ > make
>> GENgenerated/bootblock.ld
>> CP bootblock/arch/x86/bootblock.ld
>> LINK   cbfs/fallback/bootblock.debug
>> OBJCOPYcbfs/fallback/bootblock.elf
>> OBJCOPYbootblock.raw.bin
>> Checking out SeaBIOS revision 01a84bea2d28a19d2405c1ecac4bdef17683cc0c
>> Switched to branch 'master'
>>
>>   Performing operation on 'COREBOOT' region...
>>   Name   Offset Type Size
>>   cbfs master header 0x0cbfs header  32
>>   fallback/romstage  0x80   stage22684
>>   cpu_microcode_blob.bin 0x5980 microcode0
>>   config 0x5a00 raw  127
>>   revision   0x5ac0 raw  570
>>   cmos_layout.bin0x5d40 cmos_layout  1316
>>   fallback/dsdt.aml  0x62c0 raw  7952
>>   payload_config 0x8240 raw  1574
>>   payload_revision   0x88c0 raw  237
>>   (empty)0x8a00 null 29848
>>   mrc.cache  0xfec0 mrc_cache65536
>>   fallback/ramstage  0x1ff00stage46922
>>   fallback/payload   0x2b6c0payload  61122
>>   (empty)0x3a5c0null 1856216
>>   bootblock  0x1ff8c0   bootblock1528
>>
>> Finally, I'm got a coreboot image.
>>
>>
>>   poplinux@raw build $ > ls build/coreboot.rom
>>   build/coreboot.rom
>>   poplinux@raw build $ > ./build/cbfstool build/coreboot.rom print
>>   Performing operation on 'COREBOOT' region...
>>   Name   Offset Type Size
>>   cbfs master header 0x0cbfs header  32
>>   fallback/romstage  0x80   stage22684
>>   cpu_microcode_blob.bin 0x5980 microcode0
>>   config 0x5a00 raw  127
>>   revision   0x5ac0 raw  570
>>   cmos_layout.bin0x5d40 cmos_layout  1316
>>   fallback/dsdt.aml  0x62c0 raw  7952
>>   payload_config 0x8240 raw  1574
>>   payload_revision   0x88c0 raw  237
>>   (empty)0x8a00 null 29848
>>   mrc.cache  0xfec0 mrc_cache65536
>>   fallback/ramstage  0x1ff00stage46922
>>   fallback/payload   0x2b6c0payload  61122
>>   (empty)0x3a5c0null 1856216
>>   bootblock  0x1ff8c0   bootblock1528
>>
>>
>> And I'm write image to my EVB using *ALL-100 Gang-writ**er*.
>> spi flash's write *start address is set 0x*. write it success.
>>
>> And I'm attach the flash memory to my EVB.
>>
>> And power-up the my EVB. But can't see any message on my monitor and
>> serial port both.
>>
>>
>> *Why did not display any message? *
>> *A**nd could you support correct configuration file for my EVB?*
>>
>> Thank you.
>>
>>
>>
>>
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] bootfail on my Mohon Peak CRB.

[WANG FEI]

Mohon Peak coreboot can only power on your system with a Rangeley SoC FSP
included in your coreboot.

Please download the Rangeley FSP binary from
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
,

*Intel® Atom™ processor C2000 product family* (formerly Rangeley, Compliant
with FSP v1.0 Specification)

   - Windows* release version 004 >
   

   - Linux* release version 004 >
   

   - Release notes >
   

   - Platform guide >
   

   - Integration guide >
   


 And following the steps described on FSP integration guide to include FSP
into coreboot, for example, when you run "make menuconfig", you should
select "configure defaults for the Intel FSP package", you possible need to
configure more, please follow the instruction of FSP integration guide.

 * Mainboa**rd*
   Mainboard vendor (*Intel*)  --->
   Mainboard model (*Mohon Peak CRB*)  --->
   [ ] Configure defaults for the Intel FSP package
   ROM chip size (2048 KB (2 MB))  --->
   (0x0020) Size of CBFS filesystem in ROM
   ()  fmap description file in fmd format


On Tue, Feb 2, 2016 at 7:40 AM, 김유석  wrote:

> Dear sir.
>
> My ENV is see below.
>
>   *EVB : Intel rangeley Mohon Peak CRB*
>
>
> This time, I was download the coreboot from git.
>
>   poplinux@raw work $ > git clone http://review.coreboot.org/coreboot.git
> ./
>   poplinux@raw work $ > cd coreboot
>   poplinux@raw coreboot $ > git submodule update --init --checkout
>
> Next, *run make menuconfig* and set-up to mohon peak CRB and save & exit
>
>  * Mainboa**rd*
>Mainboard vendor (*Intel*)  --->
>Mainboard model (*Mohon Peak CRB*)  --->
>[ ] Configure defaults for the Intel FSP package
>ROM chip size (2048 KB (2 MB))  --->
>(0x0020) Size of CBFS filesystem in ROM
>()  fmap description file in fmd format
>
> Next, I'm try to build core boot.
>
>   poplinux@raw coreboot $ > make
> GENgenerated/bootblock.ld
> CP bootblock/arch/x86/bootblock.ld
> LINK   cbfs/fallback/bootblock.debug
> OBJCOPYcbfs/fallback/bootblock.elf
> OBJCOPYbootblock.raw.bin
> Checking out SeaBIOS revision 01a84bea2d28a19d2405c1ecac4bdef17683cc0c
> Switched to branch 'master'
>
>   Performing operation on 'COREBOOT' region...
>   Name   Offset Type Size
>   cbfs master header 0x0cbfs header  32
>   fallback/romstage  0x80   stage22684
>   cpu_microcode_blob.bin 0x5980 microcode0
>   config 0x5a00 raw  127
>   revision   0x5ac0 raw  570
>   cmos_layout.bin0x5d40 cmos_layout  1316
>   fallback/dsdt.aml  0x62c0 raw  7952
>   payload_config 0x8240 raw  1574
>   payload_revision   0x88c0 raw  237
>   (empty)0x8a00 null 29848
>   mrc.cache  0xfec0 mrc_cache65536
>   fallback/ramstage  0x1ff00stage46922
>   fallback/payload   0x2b6c0payload  61122
>   (empty)0x3a5c0null 1856216
>   bootblock  0x1ff8c0   bootblock1528
>
> Finally, I'm got a coreboot image.
>
>
>   poplinux@raw build $ > ls build/coreboot.rom
>   build/coreboot.rom
>   poplinux@raw build $ > ./build/cbfstool build/coreboot.rom print
>   Performing operation on 'COREBOOT' region...
>   Name   Offset Type Size
>   cbfs master header 0x0cbfs header  32
>   fallback/romstage  0x80   stage22684
>   cpu_microcode_blob.bin 0x5980 microcode0
>   config 0x5a00 raw  127
>   revision   0x5ac0 raw  570
>   cmos_layout.bin0x5d40 cmos_layout  1316
>   fallback/dsdt.aml  0x62c0 raw  7952
>   payload_config 0x8240 raw  1574
>   payload_revision   0x88c0 raw  237
>   (empty)0x8a00 null 29848
>   mrc.cache  0xfec0 mrc_cache65536
>   fallback/ramstage  0x1ff00stage46922
>   fallback/payload   0x2b6c0payload  61122
>   (empty)

Re: [coreboot] noob question

[WANG FEI]

can you share the coreboot serial log with community?

I used to have a splash on my system, sometime I have to use a new splash
file if the original one does not show up correctly.

On Mon, Aug 10, 2015 at 1:04 PM, Johan S johan...@yahoo.fr wrote:

 Hi there,
 i m trying to understand few mechanism in coreboot can someone help ?
 I grabbed the git tree , made crossgcc , made a biosfile tested
 succesfully within qemu.
 In the menuconfig few options are quite confusing especially looking at
 the vgabios .
 I choose the oldest qemu model for emulation , enabled the vgabios , kept
 the vesa framebuffer
 did the edid patch to bypasse vbe mod multiple ...
 but i can't get my splashscreen :-/

 johan@debian:~/coreboot$ file build/coreboot.rom ^C
 johan@debian:~/coreboot$ build/cbfstool build/coreboot.rom print
 coreboot.rom: 4096 kB, bootblocksize 928, romsize 4194304, offset 0x3c
 alignment: 64 bytes, architecture: x86

 Name   Offset Type Size
 bootsplash.jpg 0x3c   bootsplash   50937
 cmos_layout.bin0x3cc740   cmos_layout  808
 fallback/dsdt.aml  0x3ccac0   raw  4000
 config 0x3cdac0   raw  3459
 revision   0x3ce880   raw  569
 (empty)0x3ceb00   null 5208
 fallback/romstage  0x3cff80   stage11468
 fallback/ramstage  0x3d2cc0   stage46007
 fallback/payload   0x3de0c0   payload  55823
 vgaroms/seavgabios.bin 0x3ebb40   raw  35840
 (empty)0x3f4780   null 46232

 I read somewhere that in vgabios i should be able to see :

 under VGA ROM --- VGA Hardware Type select coreboot linear framebuffer


 Anyway i can get my os to boot , i can pass the F12 boot option , i can
 pass openfirmware but ...
 i can't even understand why with all requirement in the biosfile i could't
 get 1024*768
 jpeg displayed with vesa enabled ...
 I 'm lost
 Thanks


 --
 Johan S johan...@yahoo.fr

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

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

Re: [coreboot] How to check if DRAM init is OK?

[WANG FEI]

How about MemTest86? See this link http://www.coreboot.org/Memtest86, I
never use it before.


On Tue, Aug 4, 2015 at 6:16 AM, Iru Cai mytbk920...@gmail.com wrote:

 Hi,

 I'm now porting coreboot to CubieTruck, a development board with an
 Allwinner A20 SoC. I use Mr.Nuke's code[1] and Allwinner's user manual for
 reference.However, when I modified the code and tested with the board, the
 console gave only two lines of message and it get stuck. So I thought DRAM
 init failed. I put some printks at bootblock_media.c, and found the bug
 occurs at line 118[2], which showed the access of a certain memory space
 caused the error. So I need to know how to check if the DRAM init works.

 Thanks
 Iru Cai

 [1] https://github.com/mrnuke/coreboot/tree/cubie_mmc
 [2]
 https://github.com/mrnuke/coreboot/blob/cubie_mmc/src/cpu/allwinner/a10/bootblock_media.c#L118

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

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

Re: [coreboot] minnowboardmax coreboot intel uefi payload :Failed to find the required acpi table

[WANG FEI]

My understanding is that your coreboot does not have ACPI table, you
possible 1) add ACPI support in coreboot, or 2) modify UEFI payload to
remove the assert if ACPI table not exist, or 3) trying the latest coreboot
package from edk2 source tree.

On Tue, Jul 7, 2015 at 2:58 AM, DM365 1395158...@qq.com wrote:

 Hello!
   I tested intel uefi payload instead of seabios in coreboot
 minnowboard max .
   It failed with Failed to find the required acpi table .
   If I use seabios payload ,the bios runs ok!
   I followed http://www.elinux.org/Minnowboard:MinnowMaxCoreboot; to
 build coreboot.
   I used https://firmware.intel.com/develop/;
 2014-WW26-UEFI.coreboot.Payload.zip
 https://firmware.intel.com/sites/default/files/2014-WW26-UEFI.CoreBoot.Payload.zip
  to
 builed uefi in coreboot.
 https://firmware.intel.com/sites/default/files/2014-WW26-UEFI.CoreBoot.Payload.zip
   The whole terminal log is :
POST: 0x4a
 POST: 0x4b
 POST: 0x4c
 POST: 0x4d
 POST: 0x4e
 POST: 0x4f
 POST: 0x39
 POST: 0x80
 POST: 0x70
 POST: 0x71
 POST: 0x72
 POST: 0x24
 POST: 0x25
 POST: 0x24
 POST: 0x25
 POST: 0x55
 POST: 0x24
 POST: 0x25
 POST: 0x55
 POST: 0x55
 POST: 0x73
 APIC: 00 missing read_resources
 PCI: 00:00.0 missing set_resources
 POST: 0x74
 POST: 0x75
 POST: 0x75
 POST: 0x93
 POST: 0x9b
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 POST: 0x75
 Warning: PCI Device 2 does not have an IRQ entry, skipping it
 POST: 0x75
 POST: 0x75
 POST: 0x76
 POST: 0x77
 find_current_mrc_cache_local: No valid fast boot cache found.
 POST: 0x79
 POST: 0x9c
 POST: 0x9e
 POST: 0x9d
 POST: 0x7a
 POST: 0x7b
 POST: 0xf8
 PROGRESS CODE: V03020003 I0
 Loading PEIM at 0x080EC20 EntryPoint=0x080EE80 CbSupportPeim.efi
 PROGRESS CODE: V03020002 I0
 0.  - 0FFF [10]
 1. 1000 - 0009 [01]
 2. 000A - 000F [02]
 3. 0010 - 7ACBCFFF [01]
 4. 7ACBD000 - 7ADF [10]
 5. 7AE0 - 7FFF [02]
 6. E000 - EFFF [02]
 7. FEB0 - FEC00FFF [02]
 8. FED01000 - FED01FFF [02]
 9. FED03000 - FED03FFF [02]
 10. FED05000 - FED05FFF [02]
 11. FED08000 - FED08FFF [02]
 12. FED0C000 - FED0 [02]
 13. FED1C000 - FED1CFFF [02]
 14. FEE0 - FEE00FFF [02]
 15. FEF0 - FEFF [02]
 16. FF80 -  [02]
 Low memory 0x7ACBD000, High Memory 0x0
 LowMemorySize: 0x7ACBD000.
 HighMemorySize: 0x0.
 PeiMemBase: 0x76CB.
 PeiMemSize: 0x400.
 PeiInstallPeiMemory MemoryBegin 0x76CB, MemoryLength 0x400
 Found one valid fv : 0x82.
 Install PPI: 49EDB1C1-BF21-4761-BB12-EB0031AABB39
 Notify: PPI Guid: 49EDB1C1-BF21-4761-BB12-EB0031AABB39, Peim notify entry
 point: 801BC0
 The 1th FV start address is 0x082, size is 0x003E, handle is
 0x82
 Install PPI: 7408D748-FC8C-4EE6-9288-C4BEC092A410
 Actual Coreboot header: 0x7ACBD000.
 Failed to find the required acpi table

 PEI_ASSERT!: d:\myworkspace\CorebootModulePkg\CbSupportPei\CbSupportPei.c
 (338): ((BOOLEAN)(0==1))


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

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

Re: [coreboot] How to build SPI ROM 8MB image

[WANG FEI]

Update BOARD_ROMSIZE_KB_2048 in src\mainboard\intel\bayleybay_fsp\Kconfig
to BOARD_ROMSIZE_KB_8192, re-generate .config and make sure .config the ROM
size is 8MB, now you can run make to generate 8MB ROM.

On Tue, Jul 7, 2015 at 10:32 AM, Cao Duc Quan caoducq...@gmail.com wrote:

 Dear all,
 I am trying to make coreboot work on BayTrail-I SoC E3845.
 I wonder if anyone could build the SPI ROM 8MB image with coreboot? I
 found that I got 2MB image with normal building so I have to flash two
 times SPI.rom first then flash coreboot.rom.

 Many Thanks,
 --
 Quan Cao
 0976574864

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

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

Re: [coreboot] ACPI resource problem

[WANG FEI]

Siyuan, did you reserved 0xFEDC2000 - 0xFEDC2FFF in ASL file? what you've
done in your code is to reserve this MMIO area in E820 table, OS will not
take this area, but it's not enough for ACPI.

Here is a sample to reserve MMIO area in asl file.

// TPM Area (0xfed4-0xfed44fff)
DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed,
Cacheable, ReadWrite,
0x, 0xfed4, 0xfed44fff, 0x,
0x5000,,, TPMR)

On Mon, Jul 6, 2015 at 12:31 PM, WANG Siyuan wangsiyuanb...@gmail.com
wrote:

 Hi,
 I have a question about acpi resource.

 My device need the resource:
 Name(_CRS, ResourceTemplate() {
   IRQ(Edge, ActiveHigh, Exclusive) {3}
   Memory32Fixed(ReadWrite, 0xFEDC2000, 0x1000)
 })
 In Win8's device manager, I got error This device cannot find enough free
 resources that it can use.

 I reserve resource (0xFEDC2000 - 0xFEDC2FFF) using flag resource-flags =
 IORESOURCE_MEM | IORESOURCE_RESERVE | IORESOURCE_FIXED | IORESOURCE_STORED
 |  IORESOURCE_ASSIGNED; I still got this error.

 I have 2 questions:
 1) Do I need to reserve MMIO for (0xFEDC2000 - 0xFEDC2FFF)?
 2) Do I need to do some thing for IRQ(Edge, ActiveHigh, Exclusive) {3}?

 Any replay is appreciated!

 Yours sincerely,
 WANG Siyuan

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

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

Re: [coreboot] Using SeaBIOS as coreboot paylod fail

[WANG FEI]

Yu-Cheng, looking through the log and just have two suggestions here.

1. It mentions the payload size is 0xc5a5, is it too small for a payload?
My understanding is that something wrong in payload compressing,
please set CONFIG_COMPRESSED_PAYLOAD_LZMA
to N and try again, I remember I saw similar issue few years ago, but never
look into the details.

CBFS: Found @ offset 102c0 size c5a5

2. I noticed you've reported 0xC000 - 0xF as the normal RAM, QEMU
should have shadow RAM switches for this special address RAM, I would
suggest you reporting the RAM starting from 0x1.

 0. -0fff: CONFIGURATION TABLES
 1. 1000-0009: RAM
 2. 000c-07fb0fff: RAM
 3. 07fb1000-07ff: CONFIGURATION TABLES


On Thu, Jun 18, 2015 at 10:58 AM, Yu-Cheng Liu peter90...@gmail.com wrote:

 hello,
 Below are my error message when using SeaBIOS as coreboot payload,Please
 help me figure out what’s wrong with my steps.Thank you in advance.


 coreboot table: 316 bytes.
 IMD ROOT0. 07fff000 1000
 IMD SMALL   1. 07ffe000 1000
 CONSOLE 2. 07fde000 0002
 ACPI3. 07fba000 00024000
 SMBIOS  4. 07fb9000 0800
 COREBOOT5. 07fb1000 8000
 IMD small region:
   IMD ROOT0. 07ffec00 0400
   CAR GLOBALS 1. 07ffebe0 000c
   ROMSTAGE2. 07ffebc0 0004
   GDT 3. 07ffe9c0 0200
 CBFS provider active.
 CBFS @ 10 size ffc80
 CBFS: Locating 'fallback/payload'
 CBFS: Found @ offset 102c0 size c5a5
 'fallback/payload' located at offset: 1102f8 size: c5a5
 Loading segment from rom address 0xfff102f8
   code (compression=1)
   New segment dstaddr 0xe7c04 memsize 0x183fc srcaddr 0xfff10330 filesize
 0xc56d
 Loading segment from rom address 0xfff10314
   Entry Point 0x000fcfff
 Bounce Buffer at 07f5e000, 338264 bytes
 Loading Segment: addr: 0x000e7c04 memsz: 0x000183fc
 filesz: 0xc56d
 lb: [0x0010, 0x001294ac)
 Post relocation: addr: 0x000e7c04 memsz: 0x000183fc
 filesz: 0xc56d
 using LZMA
 lzma: Decoding error = 1
 Payload not loaded.




 PS.:if you want see more about my option setting,step

 Setpup step:
 https://dl.dropboxusercontent.com/u/73839141/Qemu_coreboot.pdf

 SeaBIOS config:
 https://dl.dropboxusercontent.com/u/73839141/SeaBIOSConfig.txt

 Coreboot config:
 https://dl.dropboxusercontent.com/u/73839141/CorebootConfig.txt

 Erro Message:
 https://dl.dropboxusercontent.com/u/73839141/ErrMsg.txt




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

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

[coreboot] How to assign a fixed resource to PCI BAR?

[WANG FEI]

Hi, coreboot folks,

I'm trying to assign a fixed resource to a specific PCI BAR, does any know
how to do it?

Also is there a switch to change the PCI enumeration order? for example,
PCI devices enumerate from high device number to low device number?

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

Re: [coreboot] Question on VGA BIOS extraction

[WANG FEI]

TP X220 suppose to have a UEFI compatible BIOS, is it possible it has a
UEFI DXE VGA driver (not sure what's the proper name of it) except a legacy
video?

Maybe you should boot up system with original BIOS and check the content in
0xC000 segment, is it a legacy VBIOS or it's empty...

On Mon, Mar 30, 2015 at 7:10 PM, Charles Devereaux coreb...@guylhem.net
wrote:

 Likewise on thinkpad tablets the name of the digitizer (WACF004) can be
 changed by the ACPI DSDT depending on things detected by the BIOS or not.

 You may want to check the DSDT

 On Mon, Mar 30, 2015 at 12:29 PM, Timothy Pearson 
 tpear...@raptorengineeringinc.com wrote:

 On 03/30/2015 11:24 AM, Iru Cai wrote:

 Hi,

 I'm trying to build Coreboot for ThinkPad X220. I first backup the
 vendor BIOS, then use UEFITool to extract a VBIOS. The romheader program
 detects the ROM's PCI data structure and reports the device id is
 8086:0106, but the VGA controller's device id is 8086:0126. I extracted
 the video ROM from a running X220 memory and use romheader to test it,
 the result is still 8086:0106. How could this happen?

 Iru


 Some PCI devices can change their device ID based on a configuration
 register or two (I know the XGI Volari can do this for instance).  It is
 possible that the proprietary BIOS changes the ID for some reason.

 --
 Timothy Pearson
 Raptor Engineering
 +1 (415) 727-8645
 http://www.raptorengineeringinc.com

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



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

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

Re: [coreboot] 0xE0000/0xF0000 segment issue

[WANG FEI]

I'm curious why your seabios payload is loading to shadow RAM (C/D/E/F000
segment), this area suppose to be used by seabios, I guess since seabios is
a legacy BIOS. My suggestion is to load your seabios to a over 1MB address.

On Thu, Mar 19, 2015 at 2:38 PM, Naresh G. Solanki 
naresh.solanki.2...@gmail.com wrote:

 Hi All,


 I'm trying to port coreboot with seabios payload.
 Everything goes fine till the control is transferred to payload.

 Since payload is loaded between memory range 0xC_ - 0x10_.

 The problem I was facing was that the board was going to auto reboot mode
 while executing payload..

 Once it reboot then I'm not able  to control the processor through XDP
 until I manually do CPU reset.

 It keeps on rebooting once control is transferred to payload.


 To find out the cause I did detailed memory test  found out that the
 memory range 0xA - 0xB  0xE - 0xF always reads 0xFF.

 since payload is loaded in the same region so before jmp_payload, I tried
 to read this region through XDP  found payload code exist.

 so I introduced wbinvd instruction just before jmp_payload  I found that
 the  XDP started reading 0xFF in the memory range  0xE - 0xF.

 Thus from this I conclude that before the payload was able to execute
 because of cached copy of it in CPU cache  it didn't really existed in RAM.

 Also to enable  memory range 0xE_ to 0xF_  I have followed the
 guidlines  as per table 15 of the document

 http://www.intel.com/content/www/us/en/intelligent-systems/queens-bay/atom-e6xx-boot-requirements-app-note.html

 Is that OK.
 What I can do to successfully enable the memory range  0xE_ to
 0xF_ for read write operation so that my payload execution goes
 undisturbed.

 My ultimate aim is to load Windows by Seabios as payload.

 Thanks
 N Solanki














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

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

Re: [coreboot] VGA doesn't work on Mohon Peak

[WANG FEI]

Viktor, I've messed around VGA function on my platform before, I got the
problem to display seabios messages on VGA as well, finally I fed up and
enabled the bootsplash in coreboot instead, as along as the coreboot splash
can be shown on monitor, which proves the VGA function works, it's what I
want, maybe you want more...

Here is my suggestions, 1) Once the VGA option rom integrated in coreboot,
making sure it can be invoked during coreboot booting, you possible have to
change the debug level to 8 to get more coreboot debug message. I remember
it will show a message before/after VGA option rom invoked, searching VGA
or other keyword in your coreboot log to make sure it does happen. 2)
Enable boot splash on coreboot, making sure it can be shown up on your
monitor.

I can not help you on seabios VGA function, I never make it work neither.

-Fei

On Thu, Mar 19, 2015 at 10:22 AM, Kuzmichev Viktor 
kuzmichevvikt...@gmail.com wrote:

 Hello,

 I'm using coreboot + SeaBIOS on Mohon Peak CRB. And I've tried to make VGA
 work for a while now. I used this article as a guide:
 http://www.coreboot.org/VGA_support

 Extracting VGA BIOS from vendor BIOS image did not work:
 $ ./bios_extract EDVLCRB1.86B.0043.R00.1408290947_MPK.bin
 Using file EDVLCRB1.86B.0043.R00.1408290947_MPK.bin (8192kB)
 Error: Unable to detect BIOS Image type.

 Then, I've downloaded VGA BIOS from here:
 http://www.aspeedtech.com/support.php
 Mohon Peak uses Aspeed VGA controller AST1300.

 And also, I've extracted Video ROM from /dev/mem:
 # dd if=/dev/mem of=vgabios.bin bs=1k count=32 skip=768

 Neither of them worked. Here's what I've tried. I've tried to add them via
 coreboot's menuconfig (' Add VGA BIOS image' option). I've tried to add
 them manually via cbfstool as an optionrom and as a raw file. I've tried to
 put them in CBFS under vgaroms/ directory. Here's my latest ROM-file layout:
 $ ./build/cbfstool build/coreboot.rom print
 coreboot.rom: 8192 kB, bootblocksize 1024, romsize 8388608, offset 0x60
 alignment: 64 bytes, architecture: x86

 Name   Offset Type Size
 cmos_layout.bin0x60   cmos_layout  1352
 pci1a03,2000.rom   0x600580   optionrom32768
 fallback/romstage  0x6085c0   stage26616
 fallback/ramstage  0x60ee00   stage59904
 fallback/payload   0x61d840   payload  56100
 config 0x62b3c0   raw  4532
 revision   0x62c5c0   raw  708
 pci8086,1f41.rom   0x62c8c0   raw  61952
 vgaroms/pci1a03,2000.rom   0x63bb00   raw  32768
 img/Memtest86+(5.01)   0x643b40   payload  159492
 (empty)0x66aa80   null 939288
 mrc.cache  0x74ffc0   (unknown)65536
 cpu_microcode_blob.bin 0x76   microcode83968
 (empty)0x774840   null 46936
 fsp.bin0x77ffc0   (unknown)372736
 (empty)0x7db000   null 150424

 The entries pci1a03,2000.rom are the VGA ROMs there. I also tried to
 remove either of them. I've tested with coreboot option 'Run VGA Option
 ROMs' checked and unchecked without any difference. In SeaBIOS I set 'VGA
 Hardware Type (coreboot linear framebuffer)' as the other options are None,
 GeodeGX2 and GeodeLX, so coreboot linear framebuffer seemed more logical.

 I saw this mailing list:
 http://www.seabios.org/pipermail/seabios/2015-January/008588.html
 but found no solution there and it seems not to be my case as my board
 does not hang.

 I put coreboot and SeaBIOS output in the attachment. Debug levels set to 7
 for both. In coreboot only 'Output verbose CBFS debug messages' checked in
 'Debugging' submenu.

 Is there anything I'm doing wrong or simply missing?

 Viktor

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

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

Re: [coreboot] [Intel Atom C2000 Rangeley] SPI Descriptor issue related to coreboot

[WANG FEI]

Guo Jia,

It's not easy to figure out the problem in your case, it would be great if
you can have an ITP hooked on your system to debug coreboot instead of
guessing.

I'm glad you've tried to dump descriptor bin from ADI's binary, but I
remember even without descriptor binary, Mohon Peak platform can still boot
up. I would suggest you checking the microcode, making sure the processor
revision matching the microcode included in coreboot, system will halt
itself If they does not match.

-Fei

On Wed, Mar 18, 2015 at 2:17 AM, 郭佳 yunyua...@gmail.com wrote:

 Hi buddies,

 I'm porting coreboot to Intel Atom C2000 board provided from ADI.
 I've retrieved the source code released by ADI from github.
 ADI's coreboot source code requires SegaBIOS SDK to build, since I
 don't have one, I've modified the Makefile to use toolchain provided by
 original coreboot(xgcc).
 When building done, there is a coreboot.rom(8M) under coreboot/build
 directory, and flashing this file to boot rom doesn't bring the system up,
 even no serial outputs.
 I found that there is no descriptor segment at the beginning of
 coreboot.rom.
 And in Makefile, there are following lines:
 dd
 if=../intel/mainboard/intel/mohon_peak/unlocked_descriptor/descriptor.bin
 of=
 build/coreboot.pre conv=notrunc  /dev/null 21;
 Unfortunately, ADI doesn't release descriptor.bin.
 So, I use ifdtool to dump the descriptor from ADI's coreboot binary file.
 Firstly, I unlock the descriptor, then extract descriptor.bin, and
 after that, reassembly
 my own coreboot.rom file, but still fail to bring system up (no serial
 output,
 cpu core seems to fall into some infinite loop, when debugging with
 SourcePoint)
 I don't know if I've made my question clear, I'm new to x86/coreboot.
 Can someone help me? Thank you in advance.

 Regards,
 Hook Guo

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

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

Re: [coreboot] grub2 as SeaBIOS payload

[WANG FEI]

I bet the solution you mentioned is to build GRUB2 as the payload of
coreboot instead of seabios.

Seabios is a legacy bios and support legacy boot, it possible can not load
grub2.elf. Please correct me if I'm wrong.

I think memdisk is only a blank disk with grub.cfg and can be created with
Linux dd command.

I'm not familiar with GRUB2, waiting for the expert to explain this.

On Fri, Jan 23, 2015 at 4:34 AM, Wen Wang wen.w...@adiengineering.com
wrote:

 Hello,

 Has anybody tried to launch GRUB2 by SeaBIOS as a payload (not grub2 on
 MBR)?  I am hoping to see grub2 on SeaBIOS boot menu.

 I followed the coreboot wiki page to compile grub2:
 git clone git://git.savannah.gnu.org/grub.git grub
 cd grub
 ./autogen.sh
 ./configure --with-platform=coreboot
 make

 At this point it is not clear to me how to create grub2.elf and what the
 role of memdisk is. I would appreciate it if somebody could clarify the
 steps.

 Thanks!

 Wen





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

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

Re: [coreboot] SeaBIOS, serial output, grub, sgabios does not seem to load

[WANG FEI]

Kuzmichev,

Changing the seabios serial port base address, you should modify it via
make menuconfig command, it's much easy and efficiency.

It's not recommended to modify the actual source files.

-Fei

On Tue, Jan 13, 2015 at 3:33 AM, Martin Roth gauml...@gmail.com wrote:

 Hi Viktor,
   Yes, I think having option roms checked is probably required. The only
 other thing I'd recommend is to build SeaBIOS outside of the coreboot
 structure and pull it in as an elf payload.  Building within coreboot is
 handy, but it doesn't offer the flexibility or control that you get
 building it yourself.

 Martin


 On 01/12/2015 01:50 AM, Kuzmichev Viktor wrote:

 On 11.01.2015 07:45, Martin Roth wrote:

 On 01/10/2015 07:53 AM, Kevin O'Connor wrote:

 On Thu, Dec 25, 2014 at 11:45:40AM +0300, Kuzmichev Viktor wrote:

 Hello,

 I've been trying to boot grub installed on the hard drive using
 coreboot and
 SeaBIOS as a payload. The motherboard I'm using is Intel Mohon Peak.
 Also, I
 do not use VGA for output, only serial port. So, I included the
 sgabios into
 my rom file. Here is its layout:

 It should have worked.  How did you build SeaBIOS, what SeaBIOS config
 did you use, and what changes have you made to SeaBIOS?

 -Kevin

  As I recall, Mohon Peak uses 0x2f8 for the console serial port. Did
 you set sgabios to output to 2f8 instead of 3f8 in sgabios.h?

 sgabios.h:#define COM_BASE_ADDR   0x3f8

 Martin

 Thank you for your replies!

 Just checked sgabios.h and changed serial port base address to 2f8.
 Somehow I missed it earlier, although I did set this parameter in both
 coreboot and SeaBIOS before. Sadly, I do not currently have access to Mohon
 Peak, so I can't really test this right now but, hopefully, I would be able
 to test this in a few days.
 Also, I'd like to clarify one more thing. Should Option ROMS parameter in
 SeaBIOS menuconfig be checked for sgabios to work? Are there any other
 nuances I should keep in mind?

 Viktor



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

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

Re: [coreboot] [SOLVED] Internal Ethernet controller on Mohon Peak CRB failed to get activated

[WANG FEI]

Patrick,

It's great to know the issue has been solved with my suggestion.

Thanks your update.

-Fei

On Wed, Jan 7, 2015 at 4:21 PM, Patrick Agrain 
patrick.agr...@alcatel-lucent.com wrote:

 Hello,

 This issue is solved.
 Fei, your tip concerning the Intel Firmware Descriptor was good.

 Another tip came from here: http://www.sublab.org/wiki/coreboot-x201/

 I've found an Intel tool 'fict', with which I could build a valid
 descriptor (checked by the 'ifdtool').
 Enabling the INCLUDE_ME and ME_PATH in coreboot does the rest.

 Now, the Mohon Peak CRB boots with all internal GbE enabled and
 functionning.

 Thank to all.
 Kind regards,
 Patrick Agrain

 Le 05/01/2015 15:37, Alexander Couzens a écrit :

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On Mon, 5 Jan 2015 13:49:05 +0100
 Patrick Agrain patrick.agr...@alcatel-lucent.com wrote:

  Hello Fei,

 Thanks for your answer.
 Indeed, the INCLUDE_ME and ME_PATH are not configured, because I do not
 really know what is the constitution of a descriptor.bin file.

 May anybody have any pointer which could explain me what it is ?

 It's the intel management engine. It's does some power management and a
 lot other things. It's a cpu
 and has access to *everything* like ram, chipset, ...

 http://www.coreboot.org/Intel_Management_Engine

 Best,
 lynxis
 - -- Alexander Couzens

 mail: lyn...@fe80.eu
 jabber: lyn...@jabber.ccc.de
 mobile: +4915123277221
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQIcBAEBCAAGBQJUqqGTAAoJEMKenaag34YEWukP/j0HO36Y9L/ruP2r1Jfk04Ti
 RqBIP1tzWVcBEjTTJqF55bO5+Dz5sWsbqTxYfdfWxYE+EOHyxm/eET2vgYNsL4Se
 XZUdw09RWGHP3nwvp0KpGgWDYn+mUhjr6zGnI6Bx+mhiW0k+T82c4IlSMJsLZhRD
 e73Gzp5Br6Aa2VA9KY9HCvG7jS04eAOVG4ewVDfj1yR0UA6hTSfrmdiINU4R+BVc
 wneKp5xcdKIoHNT2TrgTBefyibeiGzoltGR0dZ5B03VMxxvBT56dcsCQt7LlaOTm
 48ZkkQl3/uPnISXkGXD5BDpwEOq730lNlF0ldmRG0KQpOdg0w9JE/9M9onuKU0tm
 fmkrgNXWjVit7AFzay9pe0xAzzQaseJHjZ+PbA/HEziDEOYGpan0w4e+cZHjlOZM
 ZO9b41yLAkTcYq9SPHu6EWoCExFXvvgZCd7u7UFrfeha+rdqcrIBqWw3WNTspVam
 PSBxmotfSaPWQLhApj0n4vnZRR8Y7kid8AZE2wfyD8ro7paB8wLqYMZFtTrKQv85
 QCbveDJbzMqa7s4sB1nSuoTWYQzoY2uNrZUoFZhKF1HU8nrTi+u8s5ZsqMgZZyEl
 DhOFuaiA/mpVhlWEikv6T+6IEgEN5yND8LTck50MxvCMcDHJ4OEQM5k8WddXKVWo
 McmgvLZ5qufpka30pafL
 =WE05
 -END PGP SIGNATURE-



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

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

Re: [coreboot] No video output with Bay Trail

[WANG FEI]

Fred, as long as the video output in Linux environment, it seems the video
controller is configured properly, so maybe something wrong in seabios in
configuring video to text mode (I remember seabios will configure video to
text mode as default, correct me if I am wrong).

I would suggest you enabling Boot Splash in coreboot, you might be able to
see the boot splash photo show up on your monitor.

Another suggestion, maybe you should check install_intel_vga_int15_handler
routine referring other coreboot projects and see how to modify/port it to
your project.

-Fei

On Wed, Jan 7, 2015 at 3:46 PM, Fred Young fred.yo...@kaleidescape.com
wrote:

 The last time that I synched my coreboot source was about 2 weeks ago. I
 just tried the latest FSP and I still have the same problem. When I load
 Linux, I do see video output.



 Here’s my serial output:



 coreboot-4.0-7555-g8916d0d-dirty Wed Jan  7 09:52:17 EST 2015 starting...

 POST: 0x44

 POST: 0x47

 POST: 0x48

 prev_sleep_state = S5

 POST: 0x4a

 Baytrail Chip Variant: Bay Trail-I (ISG/embedded)

 MRC v0.100

 1 channels of DDR3 @ 1333MHz

 POST: 0x4b

 POST: 0x4c

 POST: 0x4d

 POST: 0x4e

 POST: 0x4f

 CBFS: loading stage fallback/ramstage @ 0x10 (287632 bytes), entry @
 0x10

 POST: 0x80

 POST: 0x39

 coreboot-4.0-7555-g8916d0d-dirty Wed Jan  7 09:52:17 EST 2015 booting...

 POST: 0x40

 clocks_per_usec: 1916

 POST: 0x70

 POST: 0x71

 POST: 0x72

 Enumerating buses...

 POST: 0x24

 FSP Header Version: 1

 FSP Revision: 3.3

 POST: 0x25

 POST: 0x24

 POST: 0x25

 POST: 0x55

 POST: 0x24

 POST: 0x25

 POST: 0x55

 POST: 0x24

 POST: 0x25

 POST: 0x55

 POST: 0x24

 POST: 0x25

 POST: 0x24

 POST: 0x25

 POST: 0x24

 POST: 0x25

 POST: 0x55

 POST: 0x24

 POST: 0x25

 POST: 0x55

 POST: 0x24

 POST: 0x25

 POST: 0x55

 POST: 0x55

 POST: 0x55

 POST: 0x55

 done

 POST: 0x73

 Allocating resources...

 Reading resources...

 APIC: 00 missing read_resources

 Available memory below 4GB: 0x7ae0 (1966M)

 Available memory above 4GB: 0M

 Done reading resources.

 Setting resources...

 PCI: 00:00.0 missing set_resources

 Done setting resources.

 Done allocating resources.

 POST: 0x74

 Enabling resources...

 done.

 POST: 0x75

 Initializing devices...

 POST: 0x75

 POST: 0x93

 Setting up local apic...done.

 POST: 0x9b

 CPU: Intel(R) Atom(TM) CPU  E3845  @ 1.91GHz.

 AP: slot 1 apic_id 2.

 AP: slot 3 apic_id 6.

 AP: slot 2 apic_id 4.

 Initializing CPU #0

 CPU #0 initialized

 Initializing CPU #1

 Initializing CPU #3

 Turbo is unavailable

 CPU #3 initialized

 CPU #1 initialized

 Initializing CPU #2

 CPU #2 initialized

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 Unsupported software interrupt #0x15 eax 0x3005f35

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 Warning: PCI Device 2 does not have an IRQ entry, skipping it

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 POST: 0x75

 Devices initialized

 POST: 0x76

 Finalize devices...

 Devices finalized

 POST: 0x77

 POST: 0x79

 POST: 0x9c

 ACPI: Writing ACPI tables at 7add6000.

 ACPI: done.

 Root Device (Intel Bayley Bay CRB (FSP))

 CPU_CLUSTER: 0 (Intel BayTrail SoC)

 APIC: 00 (Intel BayTrail SoC)

 DOMAIN:  (Intel BayTrail SoC)

 PCI: 00:00.0 (Intel BayTrail SoC)

 PCI: 00:02.0 (Intel BayTrail SoC)

 PCI: 00:03.0 (Intel BayTrail SoC)

 PCI: 00:10.0 (Intel BayTrail SoC)

 PCI: 00:11.0 (Intel BayTrail SoC)

 PCI: 00:12.0 (Intel BayTrail SoC)

 PCI: 00:13.0 (Intel BayTrail SoC)

 PCI: 00:14.0 (Intel BayTrail SoC)

 PCI: 00:15.0 (Intel BayTrail SoC)

 PCI: 00:16.0 (Intel BayTrail SoC)

 PCI: 00:17.0 (Intel BayTrail SoC)

 PCI: 00:18.0 (Intel BayTrail SoC)

 PCI: 00:18.1 (Intel BayTrail SoC)

 PCI: 00:18.2 (Intel BayTrail SoC)

 PCI: 00:18.3 (Intel BayTrail SoC)

 PCI: 00:18.4 (Intel BayTrail SoC)

 PCI: 00:18.5 (Intel BayTrail SoC)

 PCI: 00:18.6 (Intel BayTrail SoC)

 PCI: 00:18.7 (Intel BayTrail SoC)

 PCI: 00:1a.0 (Intel BayTrail SoC)

 PCI: 00:1b.0 (Intel BayTrail SoC)

 PCI: 00:1c.0 (Intel BayTrail SoC)

 PCI: 00:1c.1 (Intel BayTrail SoC)

 PCI: 00:1c.2 (Intel BayTrail SoC)

 PCI: 00:1c.3 (Intel BayTrail SoC)

 PCI: 00:1d.0 (Intel BayTrail SoC)

 PCI: 00:1e.0 (Intel BayTrail SoC)

 PCI: 00:1e.1 (Intel BayTrail SoC)

 PCI: 00:1e.2 (Intel BayTrail SoC)

 PCI: 00:1e.3 (Intel BayTrail SoC)

 PCI: 00:1e.4 (Intel BayTrail SoC)

 PCI: 00:1e.5 (Intel BayTrail SoC)

 PCI: 00:1f.0 (Intel BayTrail SoC)

 PCI: 00:1f.3 (Intel BayTrail SoC)

 PCI: 02:00.0 (unknown)

 PCI: 03:00.0 (unknown)

 PCI: 04:00.0 (unknown)

 PCI: 05:01.0 

Re: [coreboot] questions about Rangerley

[WANG FEI]

coreboot already supports Intel Mohon Peak platform, I noticed the source
code has been committed to coreboot source tree.

The mainboard path is coreboot\src\mainboard\intel\mohonpeak.

On Fri, Dec 5, 2014 at 5:41 AM, maypar...@163.com maypar...@163.com wrote:

 Hi Martin,

 I am kinda have this graphic card issue when porting coreboot to this
 MohonPeak CRB, would you please advice any of the supported graphic card?
 or is there any clue or document about how to support such graphic card
 with seaBios?

 thanks

 May


 *From:* Martin Roth gauml...@gmail.com
 *Date:* 2014-12-05 12:00
 *To:* Jack Zhao jack_z...@usish.com; coreboot coreboot@coreboot.org
 *Subject:* Re: [coreboot] questions about Rangerley
 Hi Jack,
The Rangeley processor is supported by coreboot.  The intel/mohonpeak
 is the reference board.

 You will need to download the FSP from http://intel.com/fsp

 While there isn't a platform guide for rangeley yet, you would follow
 similar steps to setting up coreboot for the baytrail platform, so grab
 that platform guide from the fsp site.  I believe it should answer most
 of your questions.

 Please note that the graphics card delivered with the mohon peak board
 is NOT compatible with SeaBIOS.  This is an issue with the video bios on
 that particular graphics card.


 Also, if this is for a commercial project, you may be interested in
 Sage's Rangeley BSP.
 http://www.se-eng.com/intel-processors-formerly-known-as-rangeleyavoton/

 Martin

 On 12/04/2014 01:07 AM, Jack Zhao wrote:
 
  Hi Mr. Coreboot J
 
  I am a software engineer. And I am studying the coreboot with a new
  project which will use the CPU Intel Rangerley. But from the supported
  list, I cannot find it. Could you please tell me how I can see that?
  Or you can share with me some link about it. Thanks very much for
  support in advance.
 
  Best Regards,
 
  Jack Zhao
 
  +86-21-58966996-81122
 
 
 


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


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

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

Re: [coreboot] WOL/PCI PME wakeup from S3 Baytrail SoC (Bayleybay CRB)

[WANG FEI]

Guilu,

About the item 2, please refer to
https://www.pcisig.com/specifications/conventional/pcipm1.2.pdf, chapter 3,
my experience is based on this spec. I bet PCIE devices should be
compatible with this doc.

This doc will focus on PCI/PCIE devices behind PCI/PCIE bridges/root ports,
it's described how to configure the PCI/PCIE devices to wake themselves
from PME signals. This job suppose to be done before system
sleep(S1/S3/S4/S5).

-Fei

On Fri, Nov 28, 2014 at 6:42 AM, Gailu Singh gail...@gmail.com wrote:

 Hi Wang Fei,

 Thank you very much for your help. I checked the things you suggested but
 still it does not work. Here are some details.

 1) SoC ACPI registers: Enable PCIE PME in PM and GPE registers.
 You are right  PCIE Wake was disabled in smm.c I enabled it
 - enable_pm1(PWRBTN_EN | GBL_EN | PCIEXPWAK_DIS);
 + enable_pm1(PWRBTN_EN | GBL_EN);
  I Enabled GPE registers as well
 + enable_gpe(PCI_EXP_EN | PCIE_WAKE1_EN | PCIE_WAKE2_EN |
 SUS_GPIO_EN1 | SUS_GPIO_EN2);

 3) Report WOL PME single in ASL _GPE{} with _Lxx method
  I have _Lxx methods in GPE as below
 Method(_L11) {
 Notify(PWRB, 0x02) /* NOTIFY_DEVICE_WAKE */
 }

  4) (Option) If WOL PME single connect a GPIO, you have to configure
 GPIO pin as well.
  I tried configuring GPIO in gpio.c as GPIO_ACPI_WAKE and
 GPIO_ACPI_SCI
  - GPIO_DEFAULT,   /* GPIO_S5[01] */
  - GPIO_DEFAULT,   /* GPIO_S5[02] */
  + GPIO_ACPI_WAKE, /* GPIO_S5[01] */
  + GPIO_ACPI_WAKE, /* GPIO_S5[02] */

 2) PCIE Card ACPI register: Yeah, you need set some registers of the
 PCIE card to allow it waked by packages.
 I am not clear about this. Can you please elaborate little more on
 this. Do I need it to wake SoC or is it required for SoC to wake PCIe card
 after resume? From power button resume card works fine post resume.

 Am I doing something wrong in the first three things you suggested?

 Best Regards

 On Wed, Nov 26, 2014 at 8:33 PM, WANG FEI wangfei.ji...@gmail.com wrote:

 I remember WOL PME wakeup function need configure 3-4 different areas,

 1) SoC ACPI registers: Enable PCIE PME in PM and GPE registers.

 2) PCIE Card ACPI register: Yeah, you need set some registers of the PCIE
 card to allow it waked by packages.

 3) Report WOL PME single in ASL _GPE{} with _Lxx method

 4) (Option) If WOL PME single connect a GPIO, you have to configure GPIO
 pin as well.

 Please check your code and see if anything missed.

 On Tue, Nov 25, 2014 at 2:27 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Sean,

 Thanks for your help and showing me the direction. You are right GPIO
 pins for PMC_WAKE_PCIE were set to GPIO_DEFAULT in
 src/mainboard/intel/bayleybay_fsp/gpio.c. I have changed that to
 GPIO_ACPI_WAKE now. This seems to be one step closer to the solution but
 looks like something still missing as wakeup from PCIE device is still not
 working with coreboot. Any other thing that I should look at?

 Best Regards

 Perhaps you do not have all your GPIO pins set properly.

 On Mon, Nov 24, 2014 at 5:04 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Experts,

 I have PCIe card that supports wake on lan and it works fine with BIOS.
 On sending magic packet System wakes up from S3.

 However If I use same Linux image with coreboot wake from PCI device
 does not wake the system. System wakes up from S3 using power button only.

 I suspected the problem with dsdt and took dsdt binary from bios setup,
 disassembled it and replaced dsdt.asl in coreboot with the one from bios to
 match dsdt configuration. Now my dsdt and linux image are same but still
 system does not wake from PCI PME (WOL) in coreboot but works fine with
 bios.

 In both cases wakeup is enabled in
 /sys/bus/pci/devices/\:01\:00.0/power/wakeup

 Can you please advise what else could be the problem?

 PME signal is connected to GPIOS5 on the SoC.

 Best Regards



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




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

Re: [coreboot] WOL/PCI PME wakeup from S3 Baytrail SoC (Bayleybay CRB)

[WANG FEI]

I remember WOL PME wakeup function need configure 3-4 different areas,

1) SoC ACPI registers: Enable PCIE PME in PM and GPE registers.

2) PCIE Card ACPI register: Yeah, you need set some registers of the PCIE
card to allow it waked by packages.

3) Report WOL PME single in ASL _GPE{} with _Lxx method

4) (Option) If WOL PME single connect a GPIO, you have to configure GPIO
pin as well.

Please check your code and see if anything missed.

On Tue, Nov 25, 2014 at 2:27 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Sean,

 Thanks for your help and showing me the direction. You are right GPIO pins
 for PMC_WAKE_PCIE were set to GPIO_DEFAULT in
 src/mainboard/intel/bayleybay_fsp/gpio.c. I have changed that to
 GPIO_ACPI_WAKE now. This seems to be one step closer to the solution but
 looks like something still missing as wakeup from PCIE device is still not
 working with coreboot. Any other thing that I should look at?

 Best Regards

 Perhaps you do not have all your GPIO pins set properly.

 On Mon, Nov 24, 2014 at 5:04 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Experts,

 I have PCIe card that supports wake on lan and it works fine with BIOS.
 On sending magic packet System wakes up from S3.

 However If I use same Linux image with coreboot wake from PCI device does
 not wake the system. System wakes up from S3 using power button only.

 I suspected the problem with dsdt and took dsdt binary from bios setup,
 disassembled it and replaced dsdt.asl in coreboot with the one from bios to
 match dsdt configuration. Now my dsdt and linux image are same but still
 system does not wake from PCI PME (WOL) in coreboot but works fine with
 bios.

 In both cases wakeup is enabled in
 /sys/bus/pci/devices/\:01\:00.0/power/wakeup

 Can you please advise what else could be the problem?

 PME signal is connected to GPIOS5 on the SoC.

 Best Regards



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

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

Re: [coreboot] 转发: Coreboot with Intel FSP on BayleyBay Help

[WANG FEI]

Meng Qiaohui,

I noticed a file called ChangesRequiredForRambiWinboot.txt in Intel
released UEFI package, it can tell you how to modify coreboot/ACPI files to
boot Windows 7, you can download the package @
http://uefidk.intel.com/sites/default/files/2014-WW26-UEFI.CoreBoot.Payload.zip,
its decryption key @
http://uefidk.intel.com/sites/default/files/2014-WW26-UEFI.CoreBoot.Payload.zip-DecryptionKey.txt
and release note @
http://uefidk.intel.com/sites/default/files/2014-WW26-UEFI.CoreBoot.Payload-ReleaseNotes.txt
.

If you want to fully understand ACPI, go to http://www.acpi.info/ to
download the ACPI specification, reading it and practicing with your Bayley
Bay coreboot code is the best way to understand it.

-Fei

On Tue, Nov 4, 2014 at 3:07 AM, mengqiao...@mindray.com wrote:

 --

 Hi，expert.

 Now Coreboot with Intel FSP ,can load Linux on my BayleyBay.I
 tried to use Seabios 1.7.5 load Win7 64bit,but i got a blue screen
 issue,stop at A5(0x1000,0x000,0x105a23a1,0x100).Obviously I think this
 trouble was called by ACPI.Am I wrong? So I modify
 *src/soc/intel/fsp_baytrail/acpi/southcluster.asl* as follows.My serial
 ports message is attached.Then I can load Win7 64bit normaly,but the ACPI
 Table is not completed.

 *Scope (\_SB)*
 *{*
 *// GPIO Devices*
 *#include gpio.asl*

 *#if INCLUDE_LPSS*
 *// LPSS Devices*
 *#include lpss.asl*
 *#endif*

 *#if INCLUDE_SCC*
 *// SCC Devices*
 *//#include scc.asl -Commented out code 1*
 *#endif*

 *#if INCLUDE_LPE*
 *// LPE Device*
 *//#include lpe.asl-Commented out code 2*
 *#endif*
 *}*


 But I'm not quite understand ,I change the asl code is how to take
 effect?Looking for help to load win7 64bit normaly.How to modify the ACPI
 asl coed?
 Thanks in advance.






 This email (including any attachments) is intended for the sole use of the
 intended recipient/s and may contain material that is CONFIDENTIAL AND
 PRIVATE COMPANY INFORMATION.
 Any unauthorized review, use, disclosure, dissemination, forwarding,
 printing or copying of such information or any action taken in reliance on
 this e-mail is strictly prohibited.


  发件人: Werner Zeh via coreboot coreboot@coreboot.org 收件人: Gailu Singh 
 gail...@gmail.com, coreboot@coreboot.org 日期: 2014-11-04 03:24 主题: Re:
 [coreboot] Coreboot with Intel FSP on BayleyBay Help 发件人： coreboot 
 coreboot-boun...@coreboot.org
 --



 Hi.

 Now you have coreboot running.
 coreboot searches for FSP, finds it and executes the first call into it.
 FSP returns with an error and what you see is this (taken from
 src/drivers/intel/fsp/cache_as_ram.inc):

 /*
  * Failures for postcode 0xBB - failed in the FSP:
  *
  * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully.
  * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid.
  * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the
 microcode region.
  * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not met.
  * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed
  * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has been invoked
  */

 So what you actually see is error code 0x07 from FSP. This can mean that
 your CPU is not supported by this FSP version.
 If you use GOLD1 or GOLD2, then a D0 stepping is not supported and if
 you have in advance a D0 stepping installed on your board,
 than you have to use GOLD3 FSP release as it was already mentioned.

 I had the same issue and it was due to missing D0-Support in GOLD1
 release. So, I would suggest to try the right FSP-release from Intel.

 Bye
 Werner

 Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot:
  With the changed TXE/descriptor, it moved ahead but now toggling
  between POST codes 0x66 and 0x07. I checked
  ./src/include/console/post_codes.h and these POST codes are not
  defined there so I doubt that these are coming from coreboot code. Are
  these post codes coming from FSP code? If yes, How do I interpret
  them? Do I need to ask Intel? Any pointers please?
 
  On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil seanmcne...@gmail.com
  mailto:seanmcne...@gmail.com seanmcne...@gmail.com wrote:

 
  You mentioned just copying the .fd file, so I assumed it was being
  used directly in your coreboot image. FSP needs to be incorporated
  into flash, yes. It should, however, be patched with the BCT
  program as what is provided in the .fd is usually not patched with
  the a configuration that you desire. Thus you should run bct and
  configure/patch the .fd and generate a .bin to include into coreboot.
 
  I am a little confused by your email below. You state that you are
  not using the .fd directly then contradict yourself in the next
  sentence. Bottom line is I would not include any .fd file from the
  FSP archive directly. Use BCT to patch it and do not name it .fd.
  This avoids 

Re: [coreboot] Coreboot console_init() doesn't work on Rangeley board?

[WANG FEI via coreboot]

As I remember, Rangeley FSP is using UART1(0x2F8) as default, can you try
to configure UART1 on your platform?

On Tue, Sep 16, 2014 at 11:50 PM, Qinqxin Wei q...@infinera.com wrote:

 Hi,

 I am managing to replace BIOS with coreboot on a Rangeley evaluation
 board, but the serial console cannot display message after coreboot calls
 console_init() in src/southbridge/intel/fsp_rangeley/romstage.c.

 The console is connected to UART0 (0x3f8), which has been verified by BIOS.

 My configuration of coreboot includes:
 Mainboard: Intel-Mohon Peak CRB, which is the only choice for Rangeley
 FSP and microcode: downloaded from Intel FSP (
 https://downloadcenter.intel.com/Detail_Desc.aspx?agr=YDwnldID=23676).
 Payload: U-boot-x86 (should be irrelevant to payload, since coreboot just
 enters romstage)

 I have checked that the UART0 registers should have been initialized.
 The TX FIFO should also work: after out something to 0x3f8, LSR will
 change.
 I have also checked some other registers might related to UART.
 The UART_CONT (0:1f.0-0x80) is in the default state (0x0003).
 The GPIO Use Select is also in default state: GPIOS_13 is 0.

 Is there any other register can block the UART output?

 Besides, actually the coreboot finally run deeply.
 The post code changes from 47-66-67-69-...72-73-77... and finally
 stop at 0xE2.
 But there's no console display so I cannot know where it stops.

 Regards,
 Qingxin


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

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

Re: [coreboot] Wiki access

[WANG FEI]

I've sent out for Wiki access few days ago, but still have not got any
response yet.

On Mon, Oct 13, 2014 at 10:50 PM, Nico Huber nic...@gmx.de wrote:

 Hi,

 looks like I don't have an account for the coreboot wiki, yet.
 Well, at least I don't remember, and can't find any stale email...

 Nico

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

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

[coreboot] Can anyone grant me the permission to edit corboot wiki?

[WANG FEI]

I'm planning to update few pages on coreboot.org, do I need specify the
page(s) I am going to edit? If so, http://www.coreboot.org/TianoCore.

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

Re: [coreboot] Suggested readings

[WANG FEI]

The most useful boot refer to legacy system I believe:

http://www.amazon.com/The-Undocumented-PC-Programmers-Edition/dp/0201479508

Beside Aaron's suggestion of Intel manuals, I also recommend AMD
programming manuals,

http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/


On Tue, Oct 7, 2014 at 3:35 PM, Gregg Levine gregg.drw...@gmail.com wrote:

 Hello!
 I'll echo what you also said Aaron with this one on the X86 family as well:

 http://www.amazon.com/Computer-organization-Hardware-software-Gorsline/dp/0131652907/ref=cm_wl_huc_item

 That book happens to be extremely important to almost any programmer.
 It contains several sadly retired part numbers in the book, and of
 course the members of the original series of system members. It
 largely talks about the actual beginning entries, the 8086 itself, and
 others. People here would find it useful because it still describes
 useful ideas.

 Even Intel is realizing that the retired the X86 working entries in
 the series too early, that's why the QUARK family is out now.
 -
 Gregg C Levine gregg.drw...@gmail.com
 This signature fought the Time Wars, time and again.


 On Tue, Oct 7, 2014 at 9:22 AM, Aaron Durbin adur...@chromium.org wrote:
  On Tue, Oct 7, 2014 at 4:59 AM, Peter Stuge pe...@stuge.se wrote:
  pras...@anche.no wrote:
  do you mean that no book (that you know) talks about x86 systems?
 
  Some books do, no single book covers the 35+ years of legacy which is
  still very much present in the latest x86 hardware.
 
  I'll definitely echo what Peter said. There are the intel manuals:
 
 
 http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
 
  While those are good, there are a lot of quirky things that are chip
  specific that aren't covered. And as Peter said there is a lot of
  legacy.
 
 
 http://www.amazon.com/The-Indispensable-Hardware-Book-Edition/dp/0201596164/ref=sr_1_2?ie=UTF8qid=1412688038sr=8-2
 
  That one is very much oriented to BIOS and PCs proper. There are some
  gems in there, but I wouldn't go to that if one wanted to understand
  computer architecture.
 
  -Aaron
 
  --
  coreboot mailing list: coreboot@coreboot.org
  http://www.coreboot.org/mailman/listinfo/coreboot

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

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

Re: [coreboot] Lanner 7525 , Intel Atom C2000 Rangeley

[WANG FEI]

Franz, Intel Rangeley SoC and Intel Mohon Peak platform have been supported
in coreboot, mainboard directory path is src\mainboard\intel\mohonpeak. You
need download coreboot source code and Rangeley FSP binary from
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html#downloads,
after integrating Intel FSP into coreboot, you should be able to start
porting it on your project.

Please search in the archive mails, you will be able to find useful mails.

On Tue, Sep 23, 2014 at 7:51 PM, Franz Schober franz.scho...@firmos.at
wrote:

  Hi,

 I would like to use coreboot on a fairly new Lanner FW-7525 Network
 Security Platform
 with Atom C2358 CPU and 6 Intel Nics.

 Is this platform supported or are there any patches / or someone working
 on this or a similar device or mainboard?

 Many thanks,
 Franz Schober

 --

 -franz.scho...@firmos.at
 FirmOS Business Solutions Gmbh
 Obstweg 4
 A-8073 Graz-Neupirka


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

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

Re: [coreboot] [Heads up] CPU_ADDR_BITS set to 36 bits again on most Intel device

[WANG FEI]

Good news!


On Wed, Aug 13, 2014 at 9:48 PM, Paul Menzel 
paulepan...@users.sourceforge.net wrote:

 Am Dienstag, den 12.08.2014, 11:01 +0100 schrieb WANG FEI:
  I noticed this issue before, Kconfig will take default CPU_ADDR_BITS with
  the value 32 in src\cpu\intel\model_106cx\Kconfig instead of the value 36
  src\cpu\x86\Kconfig. To avoid this issue, you have to override
  CPU_ADDR_BITS in your own Kconfig file same as what Baytrail project has
  done.

 Indeed. As the change set #6535 [1] has been submitted, you do not need
 to do that anymore.


 Thanks,

 Paul


 PS: Did you report that issue to the list? It might have been fixed
 earlier if you had done that.


 [1] http://review.coreboot.org/6535

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

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

Re: [coreboot] [Heads up] CPU_ADDR_BITS set to 36 bits again on most Intel device (was: [coreboot-gerrit] Patch merged into coreboot/master: a438049 model_106cx: don't blindly set Kconfig settings)

[WANG FEI]

I noticed this issue before, Kconfig will take default CPU_ADDR_BITS with
the value 32 in src\cpu\intel\model_106cx\Kconfig instead of the value 36
src\cpu\x86\Kconfig. To avoid this issue, you have to override
CPU_ADDR_BITS in your own Kconfig file same as what Baytrail project has
done.


On Tue, Aug 12, 2014 at 7:41 AM, Paul Menzel 
paulepan...@users.sourceforge.net wrote:

 Dear coreboot folks,


 Am Sonntag, den 10.08.2014, 16:34 +0200 schrieb ger...@coreboot.org:
  the following patch was just integrated into master:
  commit a438049422fae85fe4df3ab3f89dbca797d6f5a9
  Author: Aaron Durbin adur...@chromium.org
  Date:   Tue Sep 17 22:01:48 2013 -0500
 
  model_106cx: don't blindly set Kconfig settings
 
  The CPU_ADDR_BITS was being unconditionally set.
  Don't do that.

 […]

  See http://review.coreboot.org/6535 for details.

 since the submission of the commit above `CONFIG_CPU_ADDR_BITS` is set
 to 36 bits on most Intel devices instead of 32 bit, which it has been
 since almost two years after a bad conflict resolution in the revert
 commit 51676b14 (Revert Use broadcast SIPI to startup siblings) [1],
 where the checks from commit c7fb2ae6 (Intel cpus: use CPU_ADDR_BITS
 from Kconfig during CAR) [2] were removed.

 I was told it should not make a difference for machines below 4 GB, but
 it’d be great if you could test it on your Intel boards.


 Thanks,

 Paul


 [1] http://review.coreboot.org/1381
 [2] http://review.coreboot.org/639

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

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

Re: [coreboot] Will an ASUS M5A97 R2.0 work with coreboot?

[WANG FEI]

Tom, I'm not an expert of AMD products, I just have a quick search on the
Device IDs in your mail, your platform's southbridge is SB800, which is
already supported by coreboot, AMD's processor/northbridge is definitely
supported by coreboot, but I dont believe the mainboard is supported by
coreboot.


On Wed, Jul 23, 2014 at 10:54 AM, Peter Stuge pe...@stuge.se wrote:

 Tom wrote:
  Hello I own an ASUS M5A97 R2.0 and I would like to know if coreboot is
  supported.

 The simple answer is that if the mainboard is listed as supported on
 the coreboot.org webpage then it might work, and in all other cases
 it will certainly not work, and you will need to spend weeks to years
 on education and implementation for the board - how much depends on
 your background.


 //Peter

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

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

[coreboot] Something wrong in last week's check-in

[WANG FEI]

coreboot guys,

I noticed the source code check-in last week have a problem - modifying
some items with make menuconfig, such as bootsplash file, then building
with make command, the new bootsplash file will be **NOT** compiled into
new coreboot image.

I dont notice this issue one week before (I update my coreboot source code
one a week), does anyone have the same issue?

This is just a quick query, I can update the details tomorrow.

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

Re: [coreboot] BayleyBay FSP booting

[WANG FEI]

Tuan,

Your platform's northbirdge and GFX device ID is 0x0 and 0x0031? It's
definitely wrong, I would suggest you to download the Bayley Bay platform's
official UEFI BIOS from Intel IBL and flash it to you Bayley Bay platform,
then see what's the correct ID.


On Fri, Jul 11, 2014 at 4:36 AM, Patrick Georgi patr...@georgi-clan.de
wrote:

 Am 01.07.2014 17:55, schrieb Tuan Vu:
  Typically, what creates the memory ranges?
 To a large degree the memory init code, which is closed source in the
 FSP model and thus unavailable to us.

 When it comes to memory issues with FSP, it might be better to ask Intel
 directly.


 Regards,
 Patrick


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

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

Re: [coreboot] sgabios no console output from Seabios (was: coreboot Digest, Vol 113, Issue 17)

[WANG FEI]

Wang Wen,

I found following message in the coreboot-seabios log,

[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.3.4-5.fc17.x86_64
root=UUID=c4d4a429-d880-4caa-831e-9e95b5595f67 ro rd.md=0 rd.lvm=0 rd.dm=0
SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 console=ttyS1,115200n8

It shows console=ttyS1,115200n8, it means the Linux kernel is using ttyS1
as the primary serial console, which is I/O port 0x2f8. But the seabios
configure file shows seabios is configured using I/O port 0x3f8. it might
be the problem.

Please run make menuconfig in seabios and reconfigure the serial port to
0x2f8, let us know any difference.

-Wang Fei


On Mon, Jul 14, 2014 at 9:53 PM, Paul Menzel 
paulepan...@users.sourceforge.net wrote:

 Dear Wen,


 Am Montag, den 14.07.2014, 11:32 -0400 schrieb Wen Wang:

  Thanks for looking into to it!
 
  I pulled the seabios tree and built seabios manually (.config shown
  below). I then loaded seabios/out/bios.bin.elf as coreboot payload and
  sgabios as option rom. Unfortunately the same result, no output from
  seabios at all.

 If you build and run the utility `cbmem` as shown below, what is the
 output of the last two commands?

 $ cd util/cbmem
 $ make
 $ sudo cbmem -l
 $ sudo cbmem -c


 Thanks,

 Paul

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

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

Re: [coreboot] compiling error with fsp_baytrail's asl code

[WANG FEI]

I'm using IASL 20140214-32, it does report a lot warning, but no errors, it
does not cause compiling failed.


On Wed, Jun 4, 2014 at 7:31 AM, Mike Hibbett mhibb...@ircona.com wrote:

   When did that error appear Tank? And what version of the iasl compiler
 are you using?

 Mike

 Sent with AquaMail for Android
 http://www.aqua-mail.com

 On 4 June 2014 03:27:35 jstkf2...@126.com wrote:

 Hi all,
 There is something wrong with fsp_baytrail's asl code, as shown
 below:
   dsdt.ramstage.asl 24: Store (0, TRP0)
 Error 4064 - Object does not exist ^ (TRP0)

 dsdt.ramstage.asl 970: FixedDMA (0x10, 0x0, Width32Bit, )
 Error 4096 - ^ syntax error, unexpected PARSEOP_NAMESEG

 dsdt.ramstage.asl 1018: FixedDMA (0x10, 0x0, Width32Bit, )
 Error 4096 - ^ syntax error, unexpected PARSEOP_NAMESEG

 dsdt.ramstage.asl 1066: FixedDMA (0x10, 0x0, Width32Bit, )
 Error 4096 - ^ syntax error, unexpected PARSEOP_NAMESEG

 dsdt.ramstage.asl 1071: CreateDwordField (^RBUF, ^BAR0._BAS, RBAS)
 Error 4065 - ^ Object not found or not accessible from scope (^RBUF)

 dsdt.ramstage.asl 1071: CreateDwordField (^RBUF, ^BAR0._BAS, RBAS)
 Error 4065 - ^ Object not found or not accessible from scope (^BAR0._BAS)

 dsdt.ramstage.asl 1073: Return (^RBUF)
 Error 4065 - ^ Object not found or not accessible from scope (^RBUF)

 dsdt.ramstage.asl 1114: FixedDMA (0x10, 0x0, Width32Bit, )
 Error 4096 - ^ syntax error, unexpected PARSEOP_NAMESEG

 dsdt.ramstage.asl 1119: CreateDwordField (^RBUF, ^BAR0._BAS, RBAS)
 Error 4065 - ^ Object not found or not accessible from scope (^RBUF)

 dsdt.ramstage.asl 1119: CreateDwordField (^RBUF, ^BAR0._BAS, RBAS)
 Error 4065 - ^ Object not found or not accessible from scope (^BAR0._BAS)

 dsdt.ramstage.asl 1121: Return (^RBUF)
 Error 4065 - ^ Object not found or not accessible from scope (^RBUF)

 dsdt.ramstage.asl 1148: Device }
 Error 4096 - ^ syntax error, unexpected PARSEOP_DEVICE, expecting $end
 

 --
  Thanks,
 Tank


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

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

Re: [coreboot] Intel FSP on Bayley Bay CRB: No output

[WANG FEI]

I thought microcode files are kind of patches for CPU, it suppose to be
loaded before MRC just in case it fixes any issues related with CPU. I
actually did encounter an system random halt issue related with no loading
microcode before MRC training.

Martin, how do you think to display a warning during coreboot compiling
if PLATFORM_USES_FSP selected but microcode does not configure properly.


On Wed, Jun 4, 2014 at 5:43 PM, Martin Roth martin.r...@se-eng.com wrote:

 Thanks Paul.

 I'm working on a fix for this. Right now the option get selected correctly
 if you set it at the first menuconfig run. If you go back and select the
 microcode options later, they don't get correctly enabled even though
 they're turned on with a select statement.

 I hope to have a patch up for this today.

 Martin




 On 06/03/2014 04:17 PM, Paul Menzel wrote:

 Dear Gerald,


 Am Dienstag, den 03.06.2014, 14:03 +0200 schrieb Gerald Otter:

  I am trying to run coreboot + seabios payload on the bayley bay crb
 with the recently committed FSP integration, but have had no luck so
 far.
 This crb uses the bay trail I (now atom e3800) soc from intel.

 Following the instructions from commit d75800c7f , I have built a 2MB
 image and flashed it to the upper 2MB of the 8MB flash, leaving the
 TXE / flash descriptor intact.
 I have added the config from the build. The FSP I used is
 BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash
 descriptor and TXE from the 80.21 bios provided by intel, and vga bios
 36.2.2.
 Fwiw, I have tried both the 32bit and 64bit releases of the bios, even
 though the flash descriptor and TXE binary seem to be exactly the
 same.

 The issue I’m running into is that I have no idea if anything is
 running at all.
 There is no output on the VGA/HDMI ports or uart.

 The legacy uart referred to in the source is working correctly with
 the original intel bios, but does not produce any output with the
 coreboot image.
 I have tried the most common baud rates (115200, 19200, 9600 ) and did
 some measurements with a scope in case I got the baud rate wrong, but
 no cigar.
 The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the
 superIO uart. This matches with the configuration in coreboot when
 compared to the datasheet, so I’m assuming I got this set up
 correctly.
 Unfortunately, this is about all the information I have, so I hope I
 am missing something obvious when building the image / flashing it,
 etc.

 […]

 it looks like you are missing the microcode. (Next time please also send
 the output of `build/cbfstool build/coreboot.rom print`.)

 Could you please test if selecting “Generate from tree” in the prompt
 “Include CPU microcode in CBFS”?

 In the `.config`, instead of

  # CONFIG_CPU_MICROCODE_CBFS_GENERATE is not set
  # CONFIG_CPU_MICROCODE_CBFS_EXTERNAL is not set
  CONFIG_CPU_MICROCODE_CBFS_NONE=y

 you should have the one below.

  CONFIG_CPU_MICROCODE_CBFS_GENERATE=y
  # CONFIG_CPU_MICROCODE_CBFS_EXTERNAL is not set
  # CONFIG_CPU_MICROCODE_CBFS_NONE is not set


 Thanks,

 Paul




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

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

Re: [coreboot] [ANNOUNCE] SeaBIOS 1.7.5

[WANG FEI]

XHCI support is what I want, currently what's payload have a better XHCI
support? Seabios or U-Boot?


On Wed, May 28, 2014 at 3:34 PM, Peter Stuge pe...@stuge.se wrote:

 Kevin O'Connor wrote:
  New in this release:
 
  * SeaVGABIOS improvements
* New driver for coreboot native vga support

 When coreboot is built with native graphics init and SeaBIOS is the
 payload we should hide the VGA BIOS Kconfig filename option behind
 EXPERT and simply build SeaVGABIOS by default.


 //Peter

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

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

Re: [coreboot] Errors in Memtest86 with 4 or 8GB memory

[WANG FEI]

I noticed the MTRR(base:2944MB, range:64MB, type WB ) has covered the TSEG
hole(Adding hole at 2992MB-3008MB), I can not remember if this will cause a
problem or not.

Anyone knows?

BTW, what is the value of B0:D0:F0:REG70h?


On Tue, May 27, 2014 at 9:30 AM, Krzysztof Pierwieniecki 
kpierwienie...@teldat.com.pl wrote:

 This is my coreboot log.

 Chris


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

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

[coreboot] Is there a proper way to skip a specific PCI device during PCI enumeration

[WANG FEI]

Gents,

What I'm doing is to avoid PCI enumeration code
allocating/setting/configuring resource to a specific PCI device
(Bus:Device:Function), is there a mechanism in coreboot to achieve this?

I've achieved this by setting this specific PCI device's read_resources to
NULL, just wondering what's the best way to get this done.

Many thanks,

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

Re: [coreboot] Errors in Memtest86 with 4 or 8GB memory

[WANG FEI]

I guess the errors might related with MTRR/E820 Memory reporting etc.

System with 2GB RAM definitely does have a memory allocated to 2990.8MB.

I would suggest you uploading the coreboot log and MTRR dump here to review.


On Mon, May 26, 2014 at 8:28 AM, Krzysztof Pierwieniecki pierw...@wp.plwrote:

 I have a problem on Intel DQ77KB board. I use Coreboot with FSP and
 Seabios as a payload. I have two the same boards and on every board
 Memtest86 reports a problem at 2990.8MB. That problem occur only if I use 4
 or 8GB memory. With 2GB memory everything is OK.

 What may be causing errors in Test2 Address test, own address, Parallel
 in Memtest86?
 http://www.memtest86.com/technical.htm

 Chris





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

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

[coreboot] Latest coreboot compiling failure on ubuntu 14.04

[WANG FEI]

Hi, all

I noticed coreboot compiles failed on my system since the following change
committed.




*Author: Furquan Shaikh furq...@google.com furq...@google.com
2014-04-23 18:18:48Committer: Furquan Shaikh furq...@google.com
furq...@google.com  2014-05-06 19:23:31Parent:
fb494d68ff92d036adf10fb7eacf97ed9f1a4391 (baytrail: gpio: Add support for
direct / dedicated IRQs)Child:  9547f8d799829ddab9196c4e0cad644a06db49e9
(rambi: Add DIRQs for trackpad and touchscreen)*

The compiling log as below,








































*ubuntu@ubuntu:~/work/coreboot$ make/bin/sh: 1: Syntax error: redirection
unexpected/bin/sh: 1: -print-libgcc-file-name: not found/bin/sh: 1:
-print-libgcc-file-name: not found/bin/sh: 1: Syntax error: redirection
unexpected/bin/sh: 1: -print-libgcc-file-name: not found/bin/sh: 1:
-print-libgcc-file-name: not found/bin/sh: 1: Syntax error: redirection
unexpected/bin/sh: 1: -print-libgcc-file-name: not found/bin/sh: 1:
-print-libgcc-file-name: not foundwarning: (BOARD_SPECIFIC_OPTIONS 
NORTHBRIDGE_INTEL_NEHALEM  SOUTHBRIDGE_VIA_K8M890_VGA_EN 
DRIVERS_EMULATION_QEMU_BOCHS) selects VGA which has unmet direct
dependencies (VENDOR_INTEL  BOARD_INTEL_COUGAR_CANYON2)## configuration
written to .config#warning: (BOARD_SPECIFIC_OPTIONS 
NORTHBRIDGE_INTEL_NEHALEM  SOUTHBRIDGE_VIA_K8M890_VGA_EN 
DRIVERS_EMULATION_QEMU_BOCHS) selects VGA which has unmet direct
dependencies (VENDOR_INTEL  BOARD_INTEL_COUGAR_CANYON2)warning:
(BOARD_SPECIFIC_OPTIONS  NORTHBRIDGE_INTEL_NEHALEM 
SOUTHBRIDGE_VIA_K8M890_VGA_EN  DRIVERS_EMULATION_QEMU_BOCHS) selects VGA
which has unmet direct dependencies (VENDOR_INTEL 
BOARD_INTEL_COUGAR_CANYON2)HOSTCC nvramtool/cli/nvramtool.o
HOSTCC nvramtool/cli/opts.oHOSTCC nvramtool/cmos_lowlevel.o
HOSTCC nvramtool/cmos_ops.oHOSTCC nvramtool/common.o
HOSTCC nvramtool/compute_ip_checksum.oHOSTCC
nvramtool/hexdump.oHOSTCC nvramtool/input_file.oHOSTCC
nvramtool/layout.oHOSTCC nvramtool/accessors/layout-common.o
HOSTCC nvramtool/accessors/layout-text.oHOSTCC
nvramtool/accessors/layout-bin.oHOSTCC nvramtool/lbtable.o
HOSTCC nvramtool/reg_expr.oHOSTCC nvramtool/cbfs.o
HOSTCC nvramtool/accessors/cmos-mem.oHOSTCC nvramtool/nvramtool
(link)OPTION option_table.hGENbuild.hCC
romstage.incmake: MMD: Command not foundPOST   romstage.incsed:
can't read build/mainboard/emulation/qemu-i440fx/romstage.pre.inc: No such
file or directorymake: ***
[build/mainboard/emulation/qemu-i440fx/romstage.inc] Error 2*

It looks the bash on my system does not compatible with the new committed
makefile, does anyone get the failure?

The bash I'm using is,







*ubuntu@ubuntu:~/work/coreboot$ /bin/bash --versionGNU bash, version
4.3.11(1)-release (i686-pc-linux-gnu)Copyright (C) 2013 Free Software
Foundation, Inc.License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html http://gnu.org/licenses/gpl.htmlThis
is free software; you are free to change and redistribute it.There is NO
WARRANTY, to the extent permitted by law.*

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

Re: [coreboot] Compling error in ubuntu 14.04

[WANG FEI]

Many thanks.


On Fri, May 9, 2014 at 12:41 AM, Furquan Shaikh
furquan.m.sha...@gmail.comwrote:

 Hello Wang Fei,

 This CL has been submitted which fixes the issue:
 http://review.coreboot.org/#/c/5701/

 Thanks,
 Furquan


 On Thu, May 8, 2014 at 4:36 PM, WANG FEI wangfei.ji...@gmail.com wrote:

 Hi, all

 I noticed coreboot compiles failed on my ubuntu 14.04 since the following
 change committed.




 *Author: Furquan Shaikh furq...@google.com furq...@google.com
 2014-04-23 18:18:48 Committer: Furquan Shaikh furq...@google.com
 furq...@google.com  2014-05-06 19:23:31Parent:
 fb494d68ff92d036adf10fb7eacf97ed9f1a4391 (baytrail: gpio: Add support for
 direct / dedicated IRQs) Child:  9547f8d799829ddab9196c4e0cad644a06db49e9
 (rambi: Add DIRQs for trackpad and touchscreen)*

 The compiling log as below,








































 *ubuntu@ubuntu:~/work/coreboot$ make /bin/sh: 1: Syntax error:
 redirection unexpected/bin/sh: 1: -print-libgcc-file-name: not
 found/bin/sh: 1: -print-libgcc-file-name: not found/bin/sh: 1: Syntax
 error: redirection unexpected/bin/sh: 1: -print-libgcc-file-name: not found
 /bin/sh: 1: -print-libgcc-file-name: not found/bin/sh: 1: Syntax error:
 redirection unexpected/bin/sh: 1: -print-libgcc-file-name: not
 found/bin/sh: 1: -print-libgcc-file-name: not foundwarning:
 (BOARD_SPECIFIC_OPTIONS  NORTHBRIDGE_INTEL_NEHALEM 
 SOUTHBRIDGE_VIA_K8M890_VGA_EN  DRIVERS_EMULATION_QEMU_BOCHS) selects VGA
 which has unmet direct dependencies (VENDOR_INTEL 
 BOARD_INTEL_COUGAR_CANYON2) ## configuration written to .config#warning:
 (BOARD_SPECIFIC_OPTIONS  NORTHBRIDGE_INTEL_NEHALEM 
 SOUTHBRIDGE_VIA_K8M890_VGA_EN  DRIVERS_EMULATION_QEMU_BOCHS) selects VGA
 which has unmet direct dependencies (VENDOR_INTEL 
 BOARD_INTEL_COUGAR_CANYON2) warning: (BOARD_SPECIFIC_OPTIONS 
 NORTHBRIDGE_INTEL_NEHALEM  SOUTHBRIDGE_VIA_K8M890_VGA_EN 
 DRIVERS_EMULATION_QEMU_BOCHS) selects VGA which has unmet direct
 dependencies (VENDOR_INTEL  BOARD_INTEL_COUGAR_CANYON2) HOSTCC
 nvramtool/cli/nvramtool.oHOSTCC nvramtool/cli/opts.oHOSTCC
 nvramtool/cmos_lowlevel.oHOSTCC nvramtool/cmos_ops.oHOSTCC
 nvramtool/common.oHOSTCC nvramtool/compute_ip_checksum.o
 HOSTCC nvramtool/hexdump.oHOSTCC nvramtool/input_file.o
 HOSTCC nvramtool/layout.oHOSTCC
 nvramtool/accessors/layout-common.oHOSTCC
 nvramtool/accessors/layout-text.o HOSTCC
 nvramtool/accessors/layout-bin.oHOSTCC nvramtool/lbtable.o
 HOSTCC nvramtool/reg_expr.oHOSTCC nvramtool/cbfs.o
 HOSTCC nvramtool/accessors/cmos-mem.oHOSTCC nvramtool/nvramtool
 (link) OPTION option_table.hGENbuild.hCC
 romstage.incmake: MMD: Command not foundPOST   romstage.incsed:
 can't read build/mainboard/emulation/qemu-i440fx/romstage.pre.inc: No such
 file or directory make: ***
 [build/mainboard/emulation/qemu-i440fx/romstage.inc] Error 2*

 It looks the bash on my system does not compatible with the new committed
 makefile, does anyone get the same failure? How to solve it?

 The bash I'm using is,









 *ubuntu@ubuntu:~/work/coreboot$ /bin/bash --versionGNU bash, version
 4.3.11(1)-release (i686-pc-linux-gnu)Copyright (C) 2013 Free Software
 Foundation, Inc.License GPLv3+: GNU GPL version 3 or later
 http://gnu.org/licenses/gpl.html http://gnu.org/licenses/gpl.html This
 is free software; you are free to change and redistribute it.There is NO
 WARRANTY, to the extent permitted by law.*

 *-Fei *

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



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

Re: [coreboot] FSP, SNB, and a new board

[WANG FEI]

Ron,

The current coreboot already supported Sandy Bridge FSP, downloading a
Sandy Bridge FSP form Intel website and placing it to current coreboot, it
might work immediately.

-Fei


On Fri, May 9, 2014 at 9:21 PM, ron minnich rminn...@gmail.com wrote:

 Oh no, I don't want to try FSP, I just want to do the thing that's the
 least work for me, and it sounds like Google mrc.bin is what I want,
 since I know where to find it :-)

 Thanks

 ron

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

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

[coreboot] Compling error in ubuntu 14.04

[WANG FEI]

Hi, all

I noticed coreboot compiles failed on my ubuntu 14.04 since the following
change committed.




*Author: Furquan Shaikh furq...@google.com furq...@google.com
2014-04-23 18:18:48 Committer: Furquan Shaikh furq...@google.com
furq...@google.com  2014-05-06 19:23:31Parent:
fb494d68ff92d036adf10fb7eacf97ed9f1a4391 (baytrail: gpio: Add support for
direct / dedicated IRQs) Child:  9547f8d799829ddab9196c4e0cad644a06db49e9
(rambi: Add DIRQs for trackpad and touchscreen)*

The compiling log as below,








































*ubuntu@ubuntu:~/work/coreboot$ make /bin/sh: 1: Syntax error: redirection
unexpected/bin/sh: 1: -print-libgcc-file-name: not found/bin/sh: 1:
-print-libgcc-file-name: not found/bin/sh: 1: Syntax error: redirection
unexpected/bin/sh: 1: -print-libgcc-file-name: not found /bin/sh: 1:
-print-libgcc-file-name: not found/bin/sh: 1: Syntax error: redirection
unexpected/bin/sh: 1: -print-libgcc-file-name: not found/bin/sh: 1:
-print-libgcc-file-name: not foundwarning: (BOARD_SPECIFIC_OPTIONS 
NORTHBRIDGE_INTEL_NEHALEM  SOUTHBRIDGE_VIA_K8M890_VGA_EN 
DRIVERS_EMULATION_QEMU_BOCHS) selects VGA which has unmet direct
dependencies (VENDOR_INTEL  BOARD_INTEL_COUGAR_CANYON2) ## configuration
written to .config#warning: (BOARD_SPECIFIC_OPTIONS 
NORTHBRIDGE_INTEL_NEHALEM  SOUTHBRIDGE_VIA_K8M890_VGA_EN 
DRIVERS_EMULATION_QEMU_BOCHS) selects VGA which has unmet direct
dependencies (VENDOR_INTEL  BOARD_INTEL_COUGAR_CANYON2) warning:
(BOARD_SPECIFIC_OPTIONS  NORTHBRIDGE_INTEL_NEHALEM 
SOUTHBRIDGE_VIA_K8M890_VGA_EN  DRIVERS_EMULATION_QEMU_BOCHS) selects VGA
which has unmet direct dependencies (VENDOR_INTEL 
BOARD_INTEL_COUGAR_CANYON2) HOSTCC nvramtool/cli/nvramtool.o
HOSTCC nvramtool/cli/opts.oHOSTCC nvramtool/cmos_lowlevel.o
HOSTCC nvramtool/cmos_ops.oHOSTCC nvramtool/common.o
HOSTCC nvramtool/compute_ip_checksum.o HOSTCC
nvramtool/hexdump.oHOSTCC nvramtool/input_file.oHOSTCC
nvramtool/layout.oHOSTCC nvramtool/accessors/layout-common.o
HOSTCC nvramtool/accessors/layout-text.o HOSTCC
nvramtool/accessors/layout-bin.oHOSTCC nvramtool/lbtable.o
HOSTCC nvramtool/reg_expr.oHOSTCC nvramtool/cbfs.o
HOSTCC nvramtool/accessors/cmos-mem.oHOSTCC nvramtool/nvramtool
(link) OPTION option_table.hGENbuild.hCC
romstage.incmake: MMD: Command not foundPOST   romstage.incsed:
can't read build/mainboard/emulation/qemu-i440fx/romstage.pre.inc: No such
file or directory make: ***
[build/mainboard/emulation/qemu-i440fx/romstage.inc] Error 2*

It looks the bash on my system does not compatible with the new committed
makefile, does anyone get the same failure? How to solve it?

The bash I'm using is,









*ubuntu@ubuntu:~/work/coreboot$ /bin/bash --versionGNU bash, version
4.3.11(1)-release (i686-pc-linux-gnu)Copyright (C) 2013 Free Software
Foundation, Inc.License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html http://gnu.org/licenses/gpl.html This
is free software; you are free to change and redistribute it.There is NO
WARRANTY, to the extent permitted by law.*

*-Fei*
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Bug in your code

[WANG FEI]

The first option to change makemagic('B', 'S', 'S', ' ') of
PAYLOAD_SEGMENT_BSS in util/cbfstool/cbfs.h would be a better solution.

On Fri, Apr 18, 2014 at 4:52 PM, Aaron Durbin adur...@chromium.org wrote:

 On Fri, Apr 18, 2014 at 9:49 AM, ron minnich rminn...@gmail.com wrote:
  Can somebody give me a sanity check? I can't see the error with the
 macro.
  I won't say too much here -- just take a look. I'm not convinced the
  code is wrong.


 http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/cbfs_core.h;h=a1d8127de20d997359cb86757dc46345ac14a88c;hb=refs/heads/master

 shows

 #define PAYLOAD_SEGMENT_CODE   0x45444F43
 #define PAYLOAD_SEGMENT_DATA   0x41544144
 #define PAYLOAD_SEGMENT_BSS0x20535342
 #define PAYLOAD_SEGMENT_PARAMS 0x41524150
 #define PAYLOAD_SEGMENT_ENTRY  0x52544E45

 and

 http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/selfboot.c;h=feff03e14385f85f0606e83359ae2b17ca52ea51;hb=refs/heads/master

 does no endianness correction. The segment-type is taken verbatim
 what is in cbfs.

 #define makemagic(b3, b2, b1, b0)\
 (((b3)24) | ((b2)  16) | ((b1)  8) | (b0))

 #define PAYLOAD_SEGMENT_CODEmakemagic('C', 'O', 'D', 'E')
 #define PAYLOAD_SEGMENT_DATAmakemagic('D', 'A', 'T', 'A')
 #define PAYLOAD_SEGMENT_BSS makemagic(' ', 'B', 'S', 'S')
 #define PAYLOAD_SEGMENT_PARAMS  makemagic('P', 'A', 'R', 'A')
 #define PAYLOAD_SEGMENT_ENTRY   makemagic('E', 'N', 'T', 'R')

 I would see the following result for all host cbfstool compilations:

 0x434F4445
 0x44415441
 0x20425353
 0x50415241
 0x454E5452

 But we xdr to big endian...  so one needs to make the
 src/include/cbfs_core.h be architecture endian aware which it isn't.

 For the x86 case:

 makemagic('B', 'S', 'S', ' ') would make the xdr.be_put32 yield
 0x20535342 when a little endian machine read the 32-bit word from a
 big endian serialization.

 The real question is what are the payload magic numbers and what
 should the encoding be? If they are serialized as big endian then the
 runtime needs an equivalent makemagic and be2host() to do the proper
 comparison. Having the runtime code be compiled as a straight up
 define is not correct for every machine because the underlying
 endinanness could be different.

 I think people are getting hung up on strings when the code is dealing
 w/ 32-bit values.

 1. change makemagic('B', 'S', 'S', ' ') for PAYLOAD_SEGMENT_BSS that
 should fix little endian target machines
 2. fix the runtime in coreboot to match cbfsutil where it sucks out
 the data as big endian and compares against the correct value.



 
  thanks
 
  ron
 
  On Fri, Apr 18, 2014 at 7:39 AM, WANG FEI wangfei.ji...@gmail.com
 wrote:
  Ronald,
 
  I just noticed a bug in your code, I've added the comment to coreboot
 review
  syste, but I'm not farmilar with this system, not sure if it will send
 you a
  notice mail automatically, so I just send you a mail to inform you this.
 
  Here is the link of comment,
  http://review.coreboot.org/#/c/5098/
 
  -Fei
 
  --
  coreboot mailing list: coreboot@coreboot.org
  http://www.coreboot.org/mailman/listinfo/coreboot

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