On 8/1/11 1:28 PM, Marc Jones wrote:
Tadas,
On Mon, Aug 1, 2011 at 1:08 PM, Tadas Slotkusdevtadas@gmail.com wrote:
Hi, thank you both for the answers. I have studied libpci from libpayload and removed that device list generation with mallocs. Done a bunch of trial-error cleanup and now chipset enable and probing for flash works in ramstage's top of hardwaremain function with this line included: x86_setup_mtrrs(36); //from cpu init routine see attached log: ramstage_with_mtrr.txt. Also attaching nonworking logs in romstage and ramstage.
Now the question is how these mtrrs should be set in cache_as_ram.inc or maybe I'm totally wrong? :)
You will need the MTRR setup from CAR. You will want your code to execute in the XIP area, so that it may be cashed. You may still have stack/mem issues. That may be the first place you look for problems. You may need to find a way to optimize for resources.
There will be a problem leaving the XIP area cached while trying to write to the flash. At the least this means it's not possible to write the whole flash. Is this intended? What's the plan here?
Stefan
There will be a problem leaving the XIP area cached while trying to write to the flash. At the least this means it's not possible to write the whole flash. Is this intended? What's the plan here?
Should it be possible to map flash contents in cache to somewhat non existing location?
Thanks, Tadas
* Tadas Slotkus devtadas@gmail.com [110811 00:32]:
There will be a problem leaving the XIP area cached while trying to write to the flash. At the least this means it's not possible to write the whole flash. Is this intended? What's the plan here?
Should it be possible to map flash contents in cache to somewhat non existing location?
I think CAR only works well for data, not for instructions. That said, you can cache the ROM, but probably not copy it to cache and jmp there.
Stefan
On 2011.08.10 23:42, Stefan Reinauer wrote:
I think CAR only works well for data, not for instructions. That said, you can cache the ROM, but probably not copy it to cache and jmp there.
I've had success doing just that (copying/uploading instructions to cache and then jumping to it) in UBRX [1]. This is basically the approach I'd envision to solve the flashrom in panic-room issues on my end.
Of course this requires initializing and using the L2-Unified cache for the program, rather than L1, since L1-Data and L1-Instructions are pretty much always separated, which in turn requires a different approach to the panic room, but at least on x86, this shouldn't be much of an issue.
For this to work, one only needs a panic room that includes a basic scripting console (such as the one UBRX provides as per see [2]), to allow the *user* to set MTRRs and L1+L2 CAR according to their CPU, as well as the upload and flush of a binary executable into L2-Unified.
While this may sound like a lot of extra work for the user, eventually this should boil down to a copy/paste of a pre-existing CPU script, which we'd provide, and some Y-modem transfer of an executable payload. In my view, this is the panic-room approach that offers the greatest flexibility as, for a flashrom payload, the immediate advantages would be: - flashrom executable from user upload rather than flash, meaning both freed up flash space and bugfixes/improvement to flashrom being able to be applied immediately rather than requiring a bootblock reflash - size of the flashrom executable only limited by the size of L2, which is a lot larger than L1 - whilst still bare-metal, flashrom can be compiled with gcc rather than ROM_CC, as stack (from the L1-Data CAR init) is available - the whole BIOS is flashable at once, since flashrom is executed from cache and not XIP.
Of course you guys may think this is a shameless plug for UBRX (and you're probably right) but I have reason to think that, at least for x86, this approach could prove very effective. Oh and of course, what works for flashrom, would also work for SerialICE and other goodies...
Regards,
/Pete
[1] http://code.google.com/p/akeo/source/browse/ubrx/scripts/intel_hello_world_p... [2] http://code.google.com/p/akeo/source/browse/ubrx/USAGE
-
Pete Batard -
Stefan Reinauer -
Tadas Slotkus