Re: [coreboot] Building AMD Persimmon in MinGW
Am 2013-05-07 01:56, schrieb Peter Stuge: Sounds right. Would be great to find out more details about why and how nvramtool is being used during the build! During the handling of cmos.layout and cmos.settings (if present and used). We don't need any special hardware access for that and should not use any such code while building coreboot. One place to look at is the win32mmap implementation, which _is_ used. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Building AMD Persimmon in MinGW
Scott Duplichan wrote: > why should the coreboot build process need to access the cmos of > the build machine? I assume the answer is that it does not, and > accessing the cmos of the build machine is an unintentional side > effect of the way nvramtool works. Sounds right. Would be great to find out more details about why and how nvramtool is being used during the build! //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Building AMD Persimmon in MinGW
]2013/5/6 Wim Vervoorn : ]> Hello, ]> ]> ]> ]> I am trying to build CoreBoot from Windows using MingGW. ]> ]> ]> ]> After downloading the latest version of the complete package to enable ]> this it is possible to build this without problem. ]> ]> ]> ]> As this package contains an old version of the tree I updated this to ]> the latest one. After doing this it's not possible to build the ]> Persimmon tree any longer. ]> ]> ]> ]> In the latest CoreBoot version the Persimmon tree uses the ]> nvramtool.exe to generate "option_table.h". When this is started I get ]> a "nvramtool.exe has stopped working message" is anyone familiar with ]> that? Is there a solution for this so I can get the tree building with the latest version as well? ] ]My guess is that nvramtool won't work on any Windows build since Windows most likely blocks CMOS ](nvram) access. ]Most developers are using Linux; if you are in dire need of a persimmon coreboot.rom: please say so (I or ]someone else can send you one off-list). I looked at this problem a while back and found the same thing as you. Because Windows blocks direct hardware access attempts by applications, nvramtool fails. Routing I/O access through a driver was easy until Microsoft came up with their signed driver requirement. The question in my mind is why should the coreboot build process need to access the cmos of the build machine? I assume the answer is that it does not, and accessing the cmos of the build machine is an unintentional side effect of the way nvramtool works. Thanks, Scott ]> Best regards, ]> ]> Wim Vervoorn -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cooperative multitasking
Updated patches: remote: http://review.coreboot.org/3204 remote: http://review.coreboot.org/3205 remote: http://review.coreboot.org/3206 remote: http://review.coreboot.org/3207 On Mon, May 6, 2013 at 9:26 AM, Aaron Durbin wrote: > On Fri, May 3, 2013 at 4:27 PM, Aaron Durbin wrote: >> Hi, >> >> I just uploaded some patches that implement the ability to >> cooperatively multitask on the boot cpu. The patches still need some >> cleaning up, but I wanted to start the conversation. Fwiw, Ron claims >> he needs this. So blame him. This notion does allow for people to >> write state machines using the callbacks and can still rely on >> synchronous programming. >> >> Patches are here: >> remote: http://review.coreboot.org/3191 >> remote: http://review.coreboot.org/3192 >> remote: http://review.coreboot.org/3193 > > I'm going to work on a revised set of patches that makes things less > ugly. I'll also attempt to split out the arch-specific code bits so > that adding arm support, for instance, should be easier. The current > behavior of the patches does not please me because it changes the > behavior of the boot sequence without the user knowing. A more > explicit opt-in for creating threads will be employed. > > -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Building AMD Persimmon in MinGW
2013/5/6 Wim Vervoorn : > Hello, > > > > I am trying to build CoreBoot from Windows using MingGW. > > > > After downloading the latest version of the complete package to enable this > it is possible to build this without problem. > > > > As this package contains an old version of the tree I updated this to the > latest one. After doing this it’s not possible to build the Persimmon tree > any longer. > > > > In the latest CoreBoot version the Persimmon tree uses the nvramtool.exe to > generate “option_table.h”. When this is started I get a “nvramtool.exe has > stopped working message” is anyone familiar with that? Is there a solution > for this so I can get the tree building with the latest version as well? My guess is that nvramtool won't work on any Windows build since Windows most likely blocks CMOS (nvram) access. Most developers are using Linux; if you are in dire need of a persimmon coreboot.rom: please say so (I or someone else can send you one off-list). > > > > Best regards, > > Wim Vervoorn > > > > > > > -- > 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] Building AMD Persimmon in MinGW
Hello, I am trying to build CoreBoot from Windows using MingGW. After downloading the latest version of the complete package to enable this it is possible to build this without problem. As this package contains an old version of the tree I updated this to the latest one. After doing this it's not possible to build the Persimmon tree any longer. In the latest CoreBoot version the Persimmon tree uses the nvramtool.exe to generate "option_table.h". When this is started I get a "nvramtool.exe has stopped working message" is anyone familiar with that? Is there a solution for this so I can get the tree building with the latest version as well? Best regards, Wim Vervoorn -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Terminology
> a simple CL I guess that CL may be another term for "commit", but coreboot uses Git, where the correct term for "commit" is "commit" and nothing else. Please remember to use the correct term in the community, to avoid any unneccessary confusion. Thanks //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cooperative multitasking
On Fri, May 3, 2013 at 4:27 PM, Aaron Durbin wrote: > Hi, > > I just uploaded some patches that implement the ability to > cooperatively multitask on the boot cpu. The patches still need some > cleaning up, but I wanted to start the conversation. Fwiw, Ron claims > he needs this. So blame him. This notion does allow for people to > write state machines using the callbacks and can still rely on > synchronous programming. > > Patches are here: > remote: http://review.coreboot.org/3191 > remote: http://review.coreboot.org/3192 > remote: http://review.coreboot.org/3193 I'm going to work on a revised set of patches that makes things less ugly. I'll also attempt to split out the arch-specific code bits so that adding arm support, for instance, should be easier. The current behavior of the patches does not please me because it changes the behavior of the boot sequence without the user knowing. A more explicit opt-in for creating threads will be employed. -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] OT: Submitted MTRR patches for Linux kernel
Dear coreboot folks,
just a note to inform you, that Andy Lutomirski sent some MTRR patches
to the Linux kernel lists [1] with the following cover letter.
[PATCH 0/7] Clean up write-combining MTRR addition
A fair number of drivers (mostly graphics) add write-combining MTRRs.
Most ignore errors and most add the MTRR even on PAT systems which don't
need to use MTRRs.
This series adds new functions mtrr_{add,del}_wc_if_needed and
drm_mtrr_{add,del}_wc that report errors and do nothing if PAT is
enabled.
I've only tested the radeon driver, since I don't have test hardware
easily available for the other drivers.
Benefits include:
- Simpler code
- No more complaints about MTRR conflict warnings on PAT systems
- Eventual unexporting of the MTRR API?
This series eliminates about half of the mtrr_add calls in drivers/.
The series is also at:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup
Andy Lutomirski (7):
x86: Add mtrr_{add,del}_wc_if_needed
drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Rework
drm_mtrr_{add,del}
drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
drm: Use drm_mtrr_add_wc for the AGP aperture
i915: Use drm_mtrr_{add,del}_wc
radeon: Switch to drm_mtrr_add_wc and add a missing drm_mtrr_del_wc
uvesafb: Clean up MTRR code
I have not looked at them, but maybe some of the ideas can be used for
coreboot too.
Thanks,
Paul
[1] http://www.spinics.net/lists/dri-devel/msg38048.html
signature.asc
Description: This is a digitally signed message part
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
