coreboot June 2016

coreboot@coreboot.org

43 participants
86 discussions

Windows only seeing 2GB of 4G (Seabios
by Naveed Ghori 07 Jun '16

07 Jun '16

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: 0x7ae00000 (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.ghori(a)dti.com.au Visit our website www.dti.com.au<http://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.

2 1

BSOD Win7 x86 for Baytrail E3845 Dsplay Driver
by Naveed Ghori 07 Jun '16

07 Jun '16

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: 0x0000007E (0xC0000005, 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.ghori(a)dti.com.au Visit our website www.dti.com.au<http://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.

2 1

Re: [coreboot] PC Engines APU2 support
by Zaolin 07 Jun '16

07 Jun '16

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

1 0

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86
by Kyösti Mälkki 06 Jun '16

06 Jun '16

On Mon, Jun 6, 2016 at 10:36 PM, ron minnich <rminnich(a)gmail.com> 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 <kraxel(a)redhat.com> 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(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86
by Patrick Rudolph 06 Jun '16

06 Jun '16

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 <kraxel(a)redhat.com> > 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(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot

3 2

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86
by Rudolf Marek 06 Jun '16

06 Jun '16

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

3 2

Re: [coreboot] autoport
by Chris Ching 06 Jun '16

06 Jun '16

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 <gaumless(a)gmail.com> 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(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > -- <- Gmail suggested reply

1 0

How to change the Core input voltage setting?
by 김유석 책임연구원 06 Jun '16

06 Jun '16

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.

2 1

New on blogs.coreboot.org: [GSoC] Better RISC-V support, week #2
by WordPress 06 Jun '16

06 Jun '16

1 0

Re: [coreboot] 16GB dimm on Sandy/Ivy Bridge status
by Zoran Stojsavljevic 06 Jun '16

06 Jun '16

Hello Iru, Here is sku you are using: http://ark.intel.com/products/71459/Intel-Core-i7-3630QM-Processor-6M-Cache… 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 <mytbk920423(a)gmail.com> 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={E1D8F… > [2] > http://www.intelligentmemory.com/fileadmin/download/compatibilitylist.pdf > > Iru. > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2016