Dear coreboot folks,
following up on Ron’s comment to Gerrit item(?) 2695 [1]
We can't break out each and every vendor TLA (Three Letter
Acronym) or we'll be here for years. I understand the possible
confusion, but at the same time, there are terms of the art that
we just use, ULT, PCI, DMA, HT, PNP, I2C, being some of them.
It's a dreadful learning curve, but we all get to climb it :-)
I propose the following rule (suggestion, guideline) for usage of
abbreviations in commit messages and code.
Abbreviations – mostly three letter acronyms (TLA) – should be
written out in full additionally once when used the first time
in a file or commit message, when no Wikipedia article exists
for that abbreviation or pops up when searching for that
abbreviation.
Following that rule, PCI, USB or GPIO would not have to be written out
fully, but CRB (Customer Reference Board) or ULT (low power Haswell
variant) would be needed to be written out or explained once.
The reasoning is that coreboot should be attractive to hobby hackers too
and not having to look up these terms saves them some time and eases the
“dreadful learning curve” in my opinion. Especially writing them out
takes programmers less than five seconds as they can type really fast.
Following this rule would make it easier for outsiders to dive into
coreboot.
What do you think? If you agree, I’ll put it to the development
guidelines or Git section of the coreboot Wiki.
Thanks,
Paul
[1] http://review.coreboot.org/#/c/2695/3//COMMIT_MSG
On Tue, 2013-03-19 at 23:16 -0500, Aaron Durbin wrote:
> Hi corebooters,
>
> I'm trying to understand the reason for the existence of
> IORESOURCE_UMA_FB. Is this to allow one to carve out an uncacheable
> MTRR region for the UMA framebuffer? If so, why was that ram added as
> cacheable to begin with?
>
> Thanks for the help. Full disclosure: I'd like to get rid of it and
> handle these concepts in a different manner.
>
> -Aaron
>
Hi Aaron
Reasons are in the poor implementation of variable MTRRs and choice of
defined IORESOURCE flags.
Variable MTRR routine causes excessive use of MTRRs when the cacheable
resources do not add to powers of 2. Try describing 3 GiB - 128 MiB
cacheable memory, and current variable MTRR routines might use 5 MTRRs
for that (2048+1024+512+256+128 MiB).
I did quite a few changes on this topic last summer to fix issues with
AMD boards with 4GB or more RAM. I believe I received enough change
resistance to not touch MTRR further.
Also see: http://review.coreboot.org/#/c/1431
Kyösti
the following patch was just integrated into master:
commit 70ae9ecb9beed3964c215362494e58c6ef37f95e
Author: Ronald G. Minnich <rminnich(a)gmail.com>
Date: Thu Feb 28 11:19:23 2013 -0600
ARM: remove assembly code dump when stages.o is built
For diagnostic purposes we had been dumping the assembly
code when stages.o was built. We've past the need to do this
and it's confusing to watch.
Change-Id: Ib84cb73ed9dad3454efcb2be90d990ce88575229
Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com>
Reviewed-on: http://review.coreboot.org/2555
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix(a)chromium.org>
Build-Tested: build bot (Jenkins) at Thu Feb 28 18:29:11 2013, giving +1
See http://review.coreboot.org/2555 for details.
-gerrit
the following patch was just integrated into master:
commit 9f3a7a3251f605a30464472e91c04a1dd8baf67e
Author: Ronald G. Minnich <rminnich(a)gmail.com>
Date: Thu Feb 28 15:21:41 2013 -0600
ARM: Fix the ldscripts so that exit/enter stage work correctly.
Remove the spurious creation of a start symbol, and use the
stage_entry symbol directly.
Change-Id: Ia62d5c056ac8b20c8ffdb78bff3d306065b6c45f
Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com>
Reviewed-on: http://review.coreboot.org/2560
Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net>
Tested-by: build bot (Jenkins)
Build-Tested: build bot (Jenkins) at Fri Mar 1 01:37:34 2013, giving +1
See http://review.coreboot.org/2560 for details.
-gerrit
the following patch was just integrated into master:
commit 28b99c05a1424848254d82d0736cdf99c90f5b67
Author: Kimarie Hoot <kimarie.hoot(a)se-eng.com>
Date: Fri Mar 8 11:57:52 2013 -0700
Supermicro H8SCM: Use SPD read code from F15 wrapper
Changes:
- Get rid of the h8scm mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: I575221039ad65a59ae0f93397ef1038b669e81c7
Signed-off-by: Kimarie Hoot <kimarie.hoot(a)se-eng.com>
Reviewed-on: http://review.coreboot.org/2829
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Tue Mar 19 18:28:32 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Wed Mar 20 05:54:51 2013, giving +2
See http://review.coreboot.org/2829 for details.
-gerrit
the following patch was just integrated into master:
commit 2a9145e743ee9d10174c469a9fc1dad0ad75d73d
Author: Kimarie Hoot <kimarie.hoot(a)se-eng.com>
Date: Thu Mar 7 17:12:36 2013 -0700
AMD Dinar: Use SPD read code from F15 wrapper
Changes:
- Get rid of the dinar mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
- select_socket() and restore_socket() were created from code that
was removed from AmdMemoryReadSPD() in dimmSpd.c. The functionality
is specific to the dinar mainboard configuration and was therefore
split from the generic read SPD functionality.
Change-Id: I1e4b9a20dc497c15dbde6d89865bd5ee7501cdc0
Signed-off-by: Kimarie Hoot <kimarie.hoot(a)se-eng.com>
Reviewed-on: http://review.coreboot.org/2830
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Tue Mar 19 18:39:33 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Wed Mar 20 05:54:27 2013, giving +2
See http://review.coreboot.org/2830 for details.
-gerrit
the following patch was just integrated into master:
commit b37ec540affaaeb3a8a230895c08778c54f1d076
Author: Kimarie Hoot <kimarie.hoot(a)se-eng.com>
Date: Fri Mar 8 15:31:49 2013 -0700
Tyan S8226: Use SPD read code from F15 wrapper
Changes:
- Get rid of the s8226 mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
- select_socket() and restore_socket() started by duplicating
sp5100_set_gpio() and sp5100_restore_gpio(), which were in
dimmSpd.c. In addition to renaming the functions to more
specifically state their purpose, some cleanup and magic number
reduction was done.
Change-Id: I1eaf64986ef4fa3f89aed2b69d3f9c8c913f726f
Signed-off-by: Kimarie Hoot <kimarie.hoot(a)se-eng.com>
Reviewed-on: http://review.coreboot.org/2827
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa(a)gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Tue Mar 19 18:07:15 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Wed Mar 20 05:54:08 2013, giving +2
See http://review.coreboot.org/2827 for details.
-gerrit
the following patch was just integrated into master:
commit eef45f9cfd016343fbcf92b4df5b3d76a39c5136
Author: Kimarie Hoot <kimarie.hoot(a)se-eng.com>
Date: Fri Mar 8 13:54:10 2013 -0700
Supermicro H8QGI: Use SPD read code from F15 wrapper
Changes:
- Get rid of the h8qgi mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
- select_socket() and restore_socket() started by duplicating
sp5100_set_gpio() and sp5100_restore_gpio(), which were in
dimmSpd.c. In addition to renaming the functions to more
specifically state their purpose, some cleanup and magic number
reduction was done.
Change-Id: I346ebd8399d4ba3e280576e667fdc62fa75a63b8
Signed-off-by: Kimarie Hoot <kimarie.hoot(a)se-eng.com>
Reviewed-on: http://review.coreboot.org/2828
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Tue Mar 19 18:18:03 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Wed Mar 20 05:53:30 2013, giving +2
See http://review.coreboot.org/2828 for details.
-gerrit
the following patch was just integrated into master:
commit e4ea2ca18d4764f8c79560d373d548d52532566d
Author: Hung-Te Lin <hungte(a)chromium.org>
Date: Tue Mar 19 12:24:43 2013 +0800
cbfstool locate: Implement alignment switch --align/-a
cbfstool usage change:
"-a" for "cbfstool locate" can specify base address alignment.
To support putting a blob in aligned location (ex, microcode needs to be aligned
in 0x10), alignment (-a) is implemented into "locate" command.
Verified by manually testing a file (324 bytes) with alignment=0x10:
cbfstool coreboot.rom locate -f test -n test -a 0x10
# output: 0x71fdd0
cbfstool coreboot.rom add -f test -n test -t raw -b 0x71fdd0
cbfstool coreboot.rom print -v -v
# output: test 0x71fd80 raw 324
# output: cbfs_file=0x71fd80, offset=0x50, content_address=0x71fdd0+0x144
Also verified to be compatible with old behavior by building i386/axus/tc320
(with page limitation 0x40000):
cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000
# output: 0x44
cbfstool coreboot.rom locate -f x.bin -n romstage -P 0x40000 -a 0x30
# output: 0x60
Change-Id: I78b549fe6097ce5cb6162b09f064853827069637
Signed-off-by: Hung-Te Lin <hungte(a)chromium.org>
Reviewed-on: http://review.coreboot.org/2824
Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net>
Tested-by: build bot (Jenkins)
Build-Tested: build bot (Jenkins) at Tue Mar 19 11:22:27 2013, giving +1
Reviewed-By: Paul Menzel <paulepanter(a)users.sourceforge.net> at Tue Mar 19 10:15:17 2013, giving +2
See http://review.coreboot.org/2824 for details.
-gerrit