Am 06.04.2012 22:38 schrieb ron minnich:
On Fri, Apr 6, 2012 at 11:12 AM, Marc Jones marcj303@gmail.com wrote:
One such a nice app would be zmodem download of raminit.
This is an interesting thought, but really a debug/development feature.
We even talked about this in v3. But it never got done, seems there is no interest.
I think it didn't get done for the same reason we had to abandon v3: lack of manpower. A few highly motivated developers spent pretty much all of their time on v3, but bringing a completely new design and codebase from zero to production was simply too big of a task, yielding stable Qemu and GeodeLX ports but not much for other hardware. At the same time, v2 was moving along and getting new hardware support all the time. In the end, it was decided that the v2 codebase should get some of the designs proven in v3, and thus v4 was born.
There is still some stuff I would love to prototype in v3 and then move to v4, and downloading raminit is one of those features. However, I won't have sufficient spare time this year to attempt that.
I am not convinced of the value of earlier serial console. It adds complexity where things should be simple. I hesitate to continue moving more code before CAR. We have had a long standing goal to reduce code before CAR.
CAR is fragile! I agree. It should be reduced as much as possible.
You may want to look at what we did in v3, it has some similarities to your ideas. And, we dropped it :-)
We already have multiple pre-CAR serial consoles if you want to build them: llshell, SerialICE and a few others. The trick is to integrate them into the coreboot execution flow in a way which lets the boot continue automatically in the normal case, and allow console access when you need it.
This also has a CAR and RAM environment (GCC-build) that can execute XIP stages from Flash ROM or decompress stages to CAR/RAM from Flash ROM.
At least with AMD processors, you can't execute code out of the data cache. The only way to get instructions cached is with a code fetch, which doesn't hit the data cache.
By the way, if you're into really weird stuff, you could try to work around the apparent "data writes hit dcache, not icache" limitation by running the downloaded code in x86emu in CAR because for x86emu the emulated instructions are data. You'll need flameproof underwear if you plan to submit such a patch, though.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger