Hi, I am developing coreboot on DMP/Vortex86EX board. I found recent
updated coreboot
source code made it boots slower on my board. That is because:
>From commit c6b44162f5cccd72e9b4d9dbf071911249971846, src/lib/cbfs_core.c uses
memmove instead of memcpy to load uncompressed ramstage. memmove func
It seems to me you could improve our memmove?
Also, if we want to define another Kconfig variable this is pretty easy to fix.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, Aug 15, 2013 at 8:43 AM, ron minnich wrote:
> It seems to me you could improve our memmove?
>
> Also, if we want to define another Kconfig variable this is pretty easy to
> fix.
There is CONFIG_CPU_DMP_VORTEX86EX which might be useful.
Maybe Andrew can try something like this:
diff --
It wouldn't be terrible to have a generally better memmove implementation
either.
Gabe
On Thu, Aug 15, 2013 at 6:23 PM, David Hendricks wrote:
>
>
>
> On Thu, Aug 15, 2013 at 8:43 AM, ron minnich wrote:
>
>> It seems to me you could improve our memmove?
>>
>> Also, if we want to define another
David Hendricks wrote:
> There is CONFIG_CPU_DMP_VORTEX86EX which might be useful.
I disagree.
> Maybe Andrew can try something like this:
..
> +ifeq ($(CONFIG_CPU_DMP_VORTEX86EX),y)
> +# Old memmove implementation from Linux always use REP MOVSL
> +# which is much faster on some CPUs.
> +ramsta
Am 2013-08-15 14:01, schrieb Andrew Wu:
is 256-byte aligned, otherwise it will failback to use slower MOV
loop. MOV loop is much slower then
REP MOVSL on Vortex86EX, because reading instructions from ROM is slow.
Can't you cache the ROM area?
Other than that: Optimizing the common code is bette
DMP/Vortex86EX can't cache ROM area on the top of 4G memory, so
romstage area can't be cached. :(
I am thinking...should I just replace memmove function with REP MOVS
version, or use __PRE_RAM__ macro to choose which memmove version to
use? (Because in romstage REP MOVS runs much faster).
2013/8/
7 matches
Mail list logo
