Thanks, I was thinking of increasing this to match the normal target.
Thoughts?
Marc
svn@coreboot.org wrote:
Author: hailfinger Date: 2008-04-24 00:54:40 +0200 (Thu, 24 Apr 2008) New Revision: 3259
Modified: trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb Log: Same old story: Fam10 needs more space again. My calculations say it needs 172 more bytes, give it 512 and hope that's enough for a while. Trivial.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Modified: trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb
--- trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb 2008-04-23 22:01:55 UTC (rev 3258) +++ trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb 2008-04-23 22:54:40 UTC (rev 3259) @@ -13,7 +13,7 @@
romimage "fallback" option USE_FALLBACK_IMAGE=1
- option ROM_IMAGE_SIZE=0x22000
- option ROM_IMAGE_SIZE=0x22200 option COREBOOT_EXTRA_VERSION=".0-fallback" payload __PAYLOAD__
end
On 24.04.2008 01:25, Marc Jones wrote:
Thanks, I was thinking of increasing this to match the normal target.
You're welcome.
Thoughts?
I think most of the size problems can be fixed by removing all those "inline" keywords (unless this is required by the processor).
So far, these size problems have only been appearing on Stefan's build host (probably due to gcc version), so I'm a bit reluctant to see these patches as more than a band-aid until we remove unnecessary "inline"s.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 24.04.2008 01:25, Marc Jones wrote:
Thanks, I was thinking of increasing this to match the normal target.
You're welcome.
Thoughts?
I think most of the size problems can be fixed by removing all those "inline" keywords (unless this is required by the processor).
So far, these size problems have only been appearing on Stefan's build host (probably due to gcc version), so I'm a bit reluctant to see these patches as more than a band-aid until we remove unnecessary "inline"s.
Regards, Carl-Daniel
I think some of those inlines should go away. They are certainly left over from previous versions of the code. They are no longer important when the ROM is instruction cached and you have CAR for a stack. Historically, without instruction caching you can loose performance doing random reads to the ROM. You can also lose any prefetch advantage your CPU and/or chipset might be doing.
Marc
On 24.04.2008 18:37, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
I think most of the size problems can be fixed by removing all those "inline" keywords (unless this is required by the processor).
So far, these size problems have only been appearing on Stefan's build host (probably due to gcc version), so I'm a bit reluctant to see these patches as more than a band-aid until we remove unnecessary "inline"s.
I think some of those inlines should go away. They are certainly left over from previous versions of the code. They are no longer important when the ROM is instruction cached and you have CAR for a stack. Historically, without instruction caching you can loose performance doing random reads to the ROM. You can also lose any prefetch advantage your CPU and/or chipset might be doing.
Dumb question: Do we use instruction caching during CAR? (I ask because I want to make sure the v3 design I have in mind for K8 bringup fits reality.)
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 24.04.2008 18:37, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
I think most of the size problems can be fixed by removing all those "inline" keywords (unless this is required by the processor).
So far, these size problems have only been appearing on Stefan's build host (probably due to gcc version), so I'm a bit reluctant to see these patches as more than a band-aid until we remove unnecessary "inline"s.
I think some of those inlines should go away. They are certainly left over from previous versions of the code. They are no longer important when the ROM is instruction cached and you have CAR for a stack. Historically, without instruction caching you can loose performance doing random reads to the ROM. You can also lose any prefetch advantage your CPU and/or chipset might be doing.
Dumb question: Do we use instruction caching during CAR? (I ask because I want to make sure the v3 design I have in mind for K8 bringup fits reality.)
Regards, Carl-Daniel
That is what XIP_ROM_BASE should be setting up. We also turned it on for Geode in v3 because the LAR parsing and decompress was taking so long. Marc
-
Carl-Daniel Hailfinger -
Marc Jones -
Marc Jones