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_cle…
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
在 2013-04-30二的 10:00 -0700，ron minnich写道：
> OK, I took a look at the code. Nice to see such a simple startup,
> reminds of linuxbios v1 days. At least if this is the right one:
> http://fossies.org/linux/misc/grub-2.00.tar.gz:a/grub-2.00/grub-core/boot/m…
>
> I don't see a problem pulling this in to coreboot. We'd probably trim
> some bits out and let ramstage take over, but for a first cut it could
> be used as is. This code is very similar in how it works to many
> linuxbios/coreboot platforms and hence should fit into the coreboot
> structure with ease.
>
> The first step remains the same: set up crossgcc. I talked to stefan
> yesterday about incorporating extant loongson patches into a gcc build
> and he mentioned that the utility is designed to allow you to specify
> patches to be pulled at build time.
>
> So, let's start with crossgcc for mips/loongson. This is a minimum requirement.
>
AFAIK, patches for gcc has been included,
seems a patch for binutil is required,
http://sourceware.org/ml/binutils/2009-11/msg00387.html
BTW, I have to build mipsel-elf by hand for poor-internet-access-speed.
PivotMasterD1 . wrote:
> Are there any plans to support
It is safe to assume that the answer is always 'no'.
If you want the code, you have to write it.
//Peter
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
-Aaron
* Marc Jones <marcj303(a)gmail.com> [130502 20:24]:
> On Thu, May 2, 2013 at 12:22 PM, Stefan Reinauer
> <stefan.reinauer(a)coreboot.org> wrote:
> > * Aaron Durbin <adurbin(a)google.com> [130502 17:39]:
> >> OK. Thanks for the info. That does make for some huge memory
> >> footprints on the AMD machines with a large number of CONFIG_MAX_CPUS.
> >> I'd be curious to know why the BSP for the AMD code requires so much
> >> while in ramstage.
> >>
> >> -Aaron
> >
> > One of the majore things needed on the BSP used to be lzma decompression
> > which put a 16K array on the stack. We fixed this a while ago, bringing
> > down stack usage on our Intel based boards to about 1K (and giving each
> > core a 4K stack)
> >
> > We fixed the issue by putting that big array in the heap instead. Maybe
> > we can fix the AMD code in the same way.
> >
> > I would like to see some actual stack usage data first though
> >
> > Stefan
> >
>
> I agree. Can we get a list of boards (I am busy and lazy). We probably
> have some of the systems at Sage.
Asrock E350M1 (using Agesa)
CPU0: stack: 002b0000 - 002c0000, lowest used address 002bf75c, stack used: 2212 bytes
CPU1: stack: 002a0000 - 002b0000, lowest used address 002afda8, stack used: 600 bytes
So it would work just fine with the default 4K stack size, even if it
took almost twice of the above measurement due to more complex hardware
in the system (extremely unlikely)
Boards with custom stack size:
* asrock/e350m1
* asus/f2a85-m
* technexion/tim5690
* msi/ms9652_fam10
* tyan/s8226
* supermicro/h8scm
* supermicro/h8qgi
* supermicro/h8qme_fam10
* amd/inagua
* amd/parmer
* amd/south_station
* amd/thatcher
* amd/dinar
* amd/torpedo
* amd/persimmon
* amd/union_station
* lippert/frontrunner-af
* lippert/toucan-af
Regards,
Stefan
Am 02.05.2013 16:32, schrieb Aaron Durbin:
> I am wondering why the ramstage stack size is so large on a lot of boards:
> Is this just an artifact of copy-n-paste? What is driving the
> requirement for such large stack sizes?
Other than for wakeup-from-suspend, no-one ever cares if that's 4k or
400k, except that things might fail if it is too small.
And Google is the first organisation with a huge interest in an
optimized wakeup in coreboot.
Patrick
* Aaron Durbin <adurbin(a)google.com> [130502 17:39]:
> OK. Thanks for the info. That does make for some huge memory
> footprints on the AMD machines with a large number of CONFIG_MAX_CPUS.
> I'd be curious to know why the BSP for the AMD code requires so much
> while in ramstage.
>
> -Aaron
One of the majore things needed on the BSP used to be lzma decompression
which put a 16K array on the stack. We fixed this a while ago, bringing
down stack usage on our Intel based boards to about 1K (and giving each
core a 4K stack)
We fixed the issue by putting that big array in the heap instead. Maybe
we can fix the AMD code in the same way.
I would like to see some actual stack usage data first though
Stefan
