Re: [coreboot] Windows only seeing 2GB of 4G (Seabios

[Naveed Ghori]

But I should still see 4GB without any patch. Right?
Windows only see 1.92GB as “Installed Memory (RAM)” in Control Panel->System.
I am happy for the system to see up to 4GB only.

From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
Sent: Tuesday, 7 June 2016 1:13 PM
To: Naveed Ghori
Cc: coreboot
Subject: Re: [coreboot] Windows only seeing 2GB of 4G (Seabios

Hello Naveed,

For you to read: https://en.wikipedia.org/wiki/Physical_Address_Extension

Important: With PAE, IA-32 architecture is 
augmented with additional address lines used to select the additional memory, 
so physical address size increases from 32 bits to 36 bits.

Then, after reading, this can/will help you: 
https://wj32.org/wp/2011/02/23/pae-patch-updated-for-windows-7-sp1/

Zoran


On Tue, Jun 7, 2016 at 6:23 AM, Naveed Ghori 
> wrote:
Hi all,

I am booting a 32 bit Win 7 image (via Seabios).

Windows is detecting only 1.92GB (even though there is 8GB of memory available.
Being a 32 bit OS I would have expected it to see at least 4GB.

Coreboot logs shows:
Available memory below 4GB: 0x7ae0 (1966M)
Available memory above 4GB: 6144M

What can cause the full 4GB to not be seen. Should I install only 4GB of memory 
instead of 4GB? I have ordered some to try in any case.

Best Regards,
Naveed

Naveed Ghori | Lead Firmware & Driver Engineer

DTI Group Ltd | Transit Security & Surveillance

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

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



Visit our website 
www.dti.com.au

The information contained in this email is confidential. If you receive this 
email in error, please inform DTI Group Ltd via the above contact details. If 
you are not the intended recipient, you may not use or disclose the information 
contained in this email or attachments.

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

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

Re: [coreboot] BSOD Win7 x86 for Baytrail E3845 Dsplay Driver

[Naveed Ghori]

Sorry I meant v36_15_0_1091 (x86) which is the latest on the Intel website that 
I can find.
I cannot find v36.15.0.1127.
I am quite sure the driver is OK but that there is something else fundamental 
causing the BSOD. I have used it on another system (non coreboot) with an E3845 
processor.

Regards,
Naveed

From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
Sent: Tuesday, 7 June 2016 12:52 PM
To: Naveed Ghori
Cc: coreboot
Subject: Re: [coreboot] BSOD Win7 x86 for Baytrail E3845 Dsplay Driver

Hello Naveed,

Little bit of google searching:
http://wikifixes.com/en/errors/0x/0xC005/?gclid=CJDYx4WIlc0CFY9uGwodBrIHbQ

As I understood, you are using 36.15.0.1 (x86 aka 32b). This is very old one.

The latest to use is: 36.15.0.1127 for x86 and 37.15.0.1127 for x86_64. Please, 
contact INTEL for these EMGD based WIN7/WIN 8.1 GFX drivers.

Zoran

On Tue, Jun 7, 2016 at 5:16 AM, Naveed Ghori 
> wrote:
Hi all,

I have Windows Embedded Standard 7 x86 working in with SeaBIOS. If I install 
the graphics driver for it however I get a BSOD while Windows is booting up 
(screen flashes before the BSOD)

As a Coreboot newbie it would be good to get an idea as to what may cause this. 
I am thinking video memory allocation.

The error is below:
*** STOP: 0x007E (0xC005, 0x8D58B437, 0x92717C04, 0x927177E0)
*** igdkmd32.sys – Address 8D58B437 base at 8D423000, DateStamp, 53ac9002

The driver version is the Intel EMGD v 36.15.0.1.

Thanks in advance.
Naveed.

Naveed Ghori | Lead Firmware & Driver Engineer

DTI Group Ltd | Transit Security & Surveillance

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

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



Visit our website 
www.dti.com.au

The information contained in this email is confidential. If you receive this 
email in error, please inform DTI Group Ltd via the above contact details. If 
you are not the intended recipient, you may not use or disclose the information 
contained in this email or attachments.

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

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

Re: [coreboot] Windows only seeing 2GB of 4G (Seabios

[Zoran Stojsavljevic]

Hello Naveed,

For you to read: https://en.wikipedia.org/wiki/Physical_Address_Extension

Important: With PAE, IA-32  architecture
is augmented with additional address lines used to select the additional
memory, so physical address size increases from 32 bits to 36 bits.

Then, after reading, this can/will help you:
https://wj32.org/wp/2011/02/23/pae-patch-updated-for-windows-7-sp1/

Zoran


On Tue, Jun 7, 2016 at 6:23 AM, Naveed Ghori 
wrote:

> Hi all,
>
>
>
> I am booting a 32 bit Win 7 image (via Seabios).
>
>
>
> Windows is detecting only 1.92GB (even though there is 8GB of memory
> available.
>
> Being a 32 bit OS I would have expected it to see at least 4GB.
>
>
>
> Coreboot logs shows:
>
> Available memory below 4GB: 0x7ae0 (1966M)
>
> Available memory above 4GB: 6144M
>
>
>
> What can cause the full 4GB to not be seen. Should I install only 4GB of
> memory instead of 4GB? I have ordered some to try in any case.
>
>
>
> Best Regards,
>
> Naveed
>
> *Naveed Ghori* | Lead Firmware & Driver Engineer
>
> *DTI Group Ltd* | *Transit Security & Surveillance*
>
> 31 Affleck Road, Perth Airport, Western Australia 6105, AU
>
> P +61 8 9373 2905,151 | F +61 8 9479 1190 | naveed.gh...@dti.com.au
>
>
>
> Visit our website www.dti.com.au
>
> The information contained in this email is confidential. If you receive
> this email in error, please inform DTI Group Ltd via the above contact
> details. If you are not the intended recipient, you may not use or disclose
> the information contained in this email or attachments.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BSOD Win7 x86 for Baytrail E3845 Dsplay Driver

[Zoran Stojsavljevic]

Hello Naveed,

Little bit of google searching:
http://wikifixes.com/en/errors/0x/0xC005/?gclid=CJDYx4WIlc0CFY9uGwodBrIHbQ

As I understood, you are using 36.15.0.1 (x86 aka 32b). This is very old
one.

The latest to use is: 36.15.0.1127 for x86 and 37.15.0.1127 for x86_64.
Please, contact INTEL for these EMGD based WIN7/WIN 8.1 GFX drivers.

Zoran

On Tue, Jun 7, 2016 at 5:16 AM, Naveed Ghori 
wrote:

> Hi all,
>
>
>
> I have Windows Embedded Standard 7 x86 working in with SeaBIOS. If I
> install the graphics driver for it however I get a BSOD while Windows is
> booting up (screen flashes before the BSOD)
>
>
>
> As a Coreboot newbie it would be good to get an idea as to what may cause
> this. I am thinking video memory allocation.
>
>
>
> The error is below:
>
> *** STOP: 0x007E (0xC005, 0x8D58B437, 0x92717C04, 0x927177E0)
>
> *** igdkmd32.sys – Address 8D58B437 base at 8D423000, DateStamp, 53ac9002
>
>
>
> The driver version is the Intel EMGD v 36.15.0.1.
>
>
>
> Thanks in advance.
>
> Naveed.
>
> *Naveed Ghori* | Lead Firmware & Driver Engineer
>
> *DTI Group Ltd* | *Transit Security & Surveillance*
>
> 31 Affleck Road, Perth Airport, Western Australia 6105, AU
>
> P +61 8 9373 2905,151 | F +61 8 9479 1190 | naveed.gh...@dti.com.au
>
>
>
> Visit our website www.dti.com.au
>
> The information contained in this email is confidential. If you receive
> this email in error, please inform DTI Group Ltd via the above contact
> details. If you are not the intended recipient, you may not use or disclose
> the information contained in this email or attachments.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Windows only seeing 2GB of 4G (Seabios

[Naveed Ghori]

Hi all,

I am booting a 32 bit Win 7 image (via Seabios).

Windows is detecting only 1.92GB (even though there is 8GB of memory available.
Being a 32 bit OS I would have expected it to see at least 4GB.

Coreboot logs shows:
Available memory below 4GB: 0x7ae0 (1966M)
Available memory above 4GB: 6144M

What can cause the full 4GB to not be seen. Should I install only 4GB of memory 
instead of 4GB? I have ordered some to try in any case.

Best Regards,
Naveed

Naveed Ghori | Lead Firmware & Driver Engineer

DTI Group Ltd | Transit Security & Surveillance

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

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



Visit our website www.dti.com.au

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

[coreboot] BSOD Win7 x86 for Baytrail E3845 Dsplay Driver

[Naveed Ghori]

Hi all,

I have Windows Embedded Standard 7 x86 working in with SeaBIOS. If I install 
the graphics driver for it however I get a BSOD while Windows is booting up 
(screen flashes before the BSOD)

As a Coreboot newbie it would be good to get an idea as to what may cause this. 
I am thinking video memory allocation.

The error is below:
*** STOP: 0x007E (0xC005, 0x8D58B437, 0x92717C04, 0x927177E0)
*** igdkmd32.sys - Address 8D58B437 base at 8D423000, DateStamp, 53ac9002

The driver version is the Intel EMGD v 36.15.0.1.

Thanks in advance.
Naveed.

Naveed Ghori | Lead Firmware & Driver Engineer

DTI Group Ltd | Transit Security & Surveillance

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

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



Visit our website www.dti.com.au

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

Re: [coreboot] PC Engines APU2 support

[Zaolin]

Hi Piotr,
> Hi all,
> I'm working on support for PC Engines APU2 (AMD GX-412TC) board and I
> finally manage to boot Voyage Linux and run memtest86+. There some
> limitations and concerns that I have and hope you can advise how to
> proceed.
>
> 1. Platform doesn't show anything on UART after power off. It works fine
> when going through reset after flashing new firmware. It seems to do
> something because LEDs light up. Any idea what can be wrong or how to
> approach that ?
>
> 2. Platform boots only with AGESA <= 1.0.0.3. With newer version (>=
> 1.0.0.4) it hangs right after passing control to Linux (GRUB seems to
> work fine). Binary from master (1.0.0.A) reboots in the same place when
> it pass control or start testing memory. Anyone saw similar behavior ?
> If yes what is the approach to debug that ? Or maybe there known fixes
> for that ?
I added Rudolf Marek as reviewer maybe he has an idea.
>
> 3. APU2 got only UART interface and to make it accept input character I
> had to port some changes from out of tree SeaBIOS. I managed to merge it
> with upstream version and it seems to work for APU2. Some of those
> changes are very specific to APU2. Code is here:
> https://github.com/pcengines/seabios/commits/apu2-support
>
> At this point, for testers (if any), I changed Makefiles to point to
> gihub repo, but wonder if pushing those changes make sense before
> merging APU2 support ?
It would make sense to push a change for the seabios project itself and
select it for the apu2 change.
In general it will take some time to land your changes in tree ;) so
just do it now !
>
> 4. I also had to modify memtest86plus because it hanged on code looking
> for SPD. This platform do not use memory modules, just chips soldered on
> board. At this point there is SPD_DISABLE define that disable SPD
> reading. I'm not sure if this is correct approach and if this should be
> pushed for review before proving it work ?
> https://github.com/pcengines/memtest86plus/commits/apu2
>
> My changes to coreboot are under review here:
> https://review.coreboot.org/#/c/14138/
>
> Any help appreciated.
>
Best Regards
Philipp


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

[coreboot] PC Engines APU2 support

[Piotr Król]

Hi all,
I'm working on support for PC Engines APU2 (AMD GX-412TC) board and I
finally manage to boot Voyage Linux and run memtest86+. There some
limitations and concerns that I have and hope you can advise how to
proceed.

1. Platform doesn't show anything on UART after power off. It works fine
when going through reset after flashing new firmware. It seems to do
something because LEDs light up. Any idea what can be wrong or how to
approach that ?

2. Platform boots only with AGESA <= 1.0.0.3. With newer version (>=
1.0.0.4) it hangs right after passing control to Linux (GRUB seems to
work fine). Binary from master (1.0.0.A) reboots in the same place when
it pass control or start testing memory. Anyone saw similar behavior ?
If yes what is the approach to debug that ? Or maybe there known fixes
for that ?

3. APU2 got only UART interface and to make it accept input character I
had to port some changes from out of tree SeaBIOS. I managed to merge it
with upstream version and it seems to work for APU2. Some of those
changes are very specific to APU2. Code is here:
https://github.com/pcengines/seabios/commits/apu2-support

At this point, for testers (if any), I changed Makefiles to point to
gihub repo, but wonder if pushing those changes make sense before
merging APU2 support ?

4. I also had to modify memtest86plus because it hanged on code looking
for SPD. This platform do not use memory modules, just chips soldered on
board. At this point there is SPD_DISABLE define that disable SPD
reading. I'm not sure if this is correct approach and if this should be
pushed for review before proving it work ?
https://github.com/pcengines/memtest86plus/commits/apu2

My changes to coreboot are under review here:
https://review.coreboot.org/#/c/14138/

Any help appreciated.

-- 
Best Regards,
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com

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

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86

[Kyösti Mälkki]

On Mon, Jun 6, 2016 at 10:36 PM, ron minnich  wrote:
> I'm getting the sense here that reasonably modern CPUs can easily handle the
> 2G hole. From what I've seen, it would not cause trouble for older CPUs
> because they're most likely to be in small systems that are not likely to
> have more than 2G memory anyway (I'm thinking of the vortex).
>

Not that I would particularly care, but was i945 able to reclaim
memory from below 4GiB to above 4GiB? There used to be a fair amount
of Lenovo T60/X60(s) users.

Additionally, early Atom (model_106cx) might have 32-bit physical
address space only without PAE.

Kyösti

> The 2G hole seems like a reasonable way go to.
>
> ron
>
> On Mon, Jun 6, 2016 at 1:01 AM Gerd Hoffmann  wrote:
>>
>>   Hi,
>>
>> > I think one can go with 2GB MMIO hole.
>>
>> Agreeing here.  We have PAE.  Non-ancient 32bit kernels should support
>> and use it, for both security reasons (nox support requires PAE page
>> table format) and accessing physical address space above 4G.
>>
>> > The PCIe > 4GB is a question, I don't
>> > think Windows have good support for this.
>>
>> Depends on the version.  Recent windows versions have no problems
>> handling it.  WinXP throws a BSOD though in case it finds a 64bit mmio
>> window described in \_SB.PCI0._CRS ...
>>
>> cheers,
>>   Gerd
>>
>>
>> --
>> 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] Discussion about dynamic PCI MMIO size on x86

[Peter Stuge]

Patrick Rudolph wrote:
> The easy way is to use 2G.

Do this now.


> The preferred way would be to mimic mrc behaviour and reboot after
> finding the correct size.

As Ron writes, I don't think it's neccessarily preferable to do
something significantly more complex, if it isn't actually
significantly better.

Keep it simple, so to say. Thanks!


//Peter

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

[coreboot] UEFI project ideas

[Rudolf Marek]

Hi all,

I noticed that seabios/libpayload could have interresting use cases and I want
to share/discuss them.

1) Have a SeaBIOS be a UEFI application. This would benefit on UEFI platforms
without CSM.

2) Provide a minimum UEFI environment. As I noticed u-boot started to have such
support. In fact it has UEFI glue to u-boot drivers. As such it provides a
minimal boot services + minimum runtime services. In seabios, it is almost
there, only PE loader and filesystem support is missing.

The 2) could be perhaps be some independent project utilizing the coreboot
libpayload library.

Maybe those can be done in next year GSoC.

I guess 2) could be useful to boot future OSes without legacy support.

Thanks
Rudolf

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

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86

[ron minnich]

On Mon, Jun 6, 2016 at 12:52 PM Patrick Rudolph  wrote:

> To summarize:
> The easy way is to use 2G.
> The preferred way would be to mimic mrc behaviour and reboot after
> finding the correct size.
>
>
>
I'm not sure it's "easy vs. preferred" so much as
- simple that has no known failure cases (yet).
- best that requires that we have another variable we have to store in flash

At least to me, it's not as cut and dried as easy vs. preferred. The
preferred way adds a lot of moving runtime parts, and we'll need to cover
for the case that the stored variable gets damaged somehow. The easy way is
a runtime constant, which I kind of like.

If the "easy" way always works, i.e. we never find a case where it causes a
problem, then it seems superior to me.

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

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86

[Patrick Rudolph]

To summarize:
The easy way is to use 2G.
The preferred way would be to mimic mrc behaviour and reboot after
finding the correct size.

On 2016-06-06 09:36 PM, ron minnich wrote:
> I'm getting the sense here that reasonably modern CPUs can easily
> handle the 2G hole. From what I've seen, it would not cause trouble
> for older CPUs because they're most likely to be in small systems that
> are not likely to have more than 2G memory anyway (I'm thinking of the
> vortex).
> 
> The 2G hole seems like a reasonable way go to.
> 
> ron
> 
> On Mon, Jun 6, 2016 at 1:01 AM Gerd Hoffmann 
> wrote:
> 
>> Hi,
>>
>>> I think one can go with 2GB MMIO hole.
>>
>> Agreeing here.  We have PAE.  Non-ancient 32bit kernels should
>> support
>> and use it, for both security reasons (nox support requires PAE page
>> table format) and accessing physical address space above 4G.
>>
>>> The PCIe > 4GB is a question, I don't
>>> think Windows have good support for this.
>>
>> Depends on the version.  Recent windows versions have no problems
>> handling it.  WinXP throws a BSOD though in case it finds a 64bit
>> mmio
>> window described in \_SB.PCI0._CRS ...
>>
>> cheers,
>> Gerd
>>
>> --
>> 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] Discussion about dynamic PCI MMIO size on x86

[ron minnich]

I'm getting the sense here that reasonably modern CPUs can easily handle
the 2G hole. From what I've seen, it would not cause trouble for older CPUs
because they're most likely to be in small systems that are not likely to
have more than 2G memory anyway (I'm thinking of the vortex).

The 2G hole seems like a reasonable way go to.

ron

On Mon, Jun 6, 2016 at 1:01 AM Gerd Hoffmann  wrote:

>   Hi,
>
> > I think one can go with 2GB MMIO hole.
>
> Agreeing here.  We have PAE.  Non-ancient 32bit kernels should support
> and use it, for both security reasons (nox support requires PAE page
> table format) and accessing physical address space above 4G.
>
> > The PCIe > 4GB is a question, I don't
> > think Windows have good support for this.
>
> Depends on the version.  Recent windows versions have no problems
> handling it.  WinXP throws a BSOD though in case it finds a 64bit mmio
> window described in \_SB.PCI0._CRS ...
>
> cheers,
>   Gerd
>
>
> --
> 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] autoport

[Chris Ching via coreboot]

Thanks Martin,

I would be willing to add a command line argument to autoport for
enable/disabling the glx flag passed to the inteltool if that is a
preferable solution.

Regards,
Chris Ching

On Wed, Jun 1, 2016 at 4:50 PM Martin Roth  wrote:

> Hi phcoder,
>   I'm trying to resolve a question that came up with inteltool &
> autoport regarding how the probing of graphics should behave.
>
> Stefanct kept having his board reboot when he was running autoport, so
> he added this change to separate out the graphics call as "unsafe"
> when probing all.
> https://review.coreboot.org/#/c/14627/4
>
> Because this changes the behavior of autoport, I suggested we ask the
> user what they want to do when running autoport.
>
> https://review.coreboot.org/#/c/14901/
>
> What's your opinion?
>
> Martin
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 

<- Gmail suggested reply
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to change the Core input voltage setting?

[Zoran Stojsavljevic]

Hello Kay,

I have one good advice for you. Do you have some average laptops to play
with?

If you do, please, install the following SW (CPU-Z) there (under
WIN7/8.x/10):  http://www.cpuid.com/softwares/cpu-z.html

Since I am reading many email (under few identities) from you. Please,
carefully explore the options under this tool, to try to understand most of
them, in order to explore deeper what you are asking here about? Deal?

Then you come back... With more questions.

Thank you,
Zoran


On Wed, May 25, 2016 at 7:56 AM, 김유석 책임연구원  wrote:

> Dear Sir.
>
>
> My HW enginner required to me. that Change the setting of "Core input
> voltage".
>
>
> But, I don't know everything this one. Because x86 platform is first time
> of my develop life.
>
> Anyway, I'm try to find the something on coreboot source code.
>
> But, still unknow.
>
>
> So, I need a start point or key point that Initial code for "Core input
> voltage".
>
>
> 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] Discussion about dynamic PCI MMIO size on x86

[Gerd Hoffmann]

  Hi,

> I think one can go with 2GB MMIO hole.

Agreeing here.  We have PAE.  Non-ancient 32bit kernels should support
and use it, for both security reasons (nox support requires PAE page
table format) and accessing physical address space above 4G.

> The PCIe > 4GB is a question, I don't 
> think Windows have good support for this.

Depends on the version.  Recent windows versions have no problems
handling it.  WinXP throws a BSOD though in case it finds a 64bit mmio
window described in \_SB.PCI0._CRS ...

cheers,
  Gerd


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

Re: [coreboot] 16GB dimm on Sandy/Ivy Bridge status

[Zoran Stojsavljevic]

Hello Iru,

Here is sku you are using:
http://ark.intel.com/products/71459/Intel-Core-i7-3630QM-Processor-6M-Cache-up-to-3_40-GHz

I am very sure 16MB DIMM (single memory stick) is NOT supported by MRC.
Since I used to work with both IVB Emerald Lake 2 and Cougar Canyon 2 INTEL
CRBs (legacy BIOS driven). Both of them had four DIMM sockets (2 channels),
and both of them could support to maximum of 8MB of DDR3 per socket. In
total 32MB.

I had 2MB x 2: 4MB at that time (Q1 2012). Worked also with 4MB DIMM
modules as well (as I recall).

Not to mention that IVB FSP is derived from IVB BIOSes (SEC + PEI phases),
thus IVB FSP MRCs are IVB BIOS MRCs (true for other/newer INTEL skus as
well).

Zoran
___

On Tue, May 31, 2016 at 5:04 AM, Iru Cai  wrote:

> Hi,
>
> I'm tesing to see if the coreboot Sandy/Ivy MRC supports 16GB DIMMs.
> Here's my result.
>
> I'm using a MT16KTF2G64HZ-1G6A1[1]. My machine is Lenovo T420 with
> i7-3630QM. With this module inserted (I've tested 16G+0 and 16G+8G), the
> system can light up, but it'll then get crashed.
> - with GRUB2 payload, it'll crash after the payload loads
> - with SeaBIOS payload with proprietary VGABIOS, I can see the prompt, and
> can boot to a GRUB or syslinux loader on my USB stick, but when I try to
> boot a system, it get crashed. If I boot to Memtest86+ on my USB stick, the
> system will crash when memtest starts to test the memory.
>
> And another thing I can see is, the first boot can boot to payload, but
> the second boot will fail. I think it's caused by the MRC cache.
>
> I'm still wondering if Sandy/Ivy northbridge can support 16GB DIMMs. I'll
> give a more detailed EHCI debug output later. According to [2], I think the
> incompatibility is an MRC issue instead of hardware incompatibility.
>
> [1]
> https://www.micron.com/parts/modules/ddr3-sdram/mt16ktf2g64hz-1g6?pc={E1D8F1A9-3DFC-4BD2-8A1E-C26ED261EB0A}
> [2]
> http://www.intelligentmemory.com/fileadmin/download/compatibilitylist.pdf
>
> Iru.
>
>
> --
> 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] Discussion about dynamic PCI MMIO size on x86

[Rudolf Marek]

Hi all,

Most of 32-bit kernels (Unix/OS/whatever) usually have PAE support, so in fact 
they can cope with 36 bits of memory. The CPU PAE support started around 
Pentium. Windows XP+ has support for this.


I think one can go with 2GB MMIO hole. The PCIe > 4GB is a question, I don't 
think Windows have good support for this. So, using 2GB memory hole and having 
MMIO < 4GB seems like a good idea.


Thanks
Rudolf


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