* Per Hallsmark perh@t2data.se [060403 10:19]:
Stefan, thanks for you answers. I'm still a bit puzzled though why PPC, ARM, XScale, MIPS manages same thing without romcc or similar.
Cache-As-Ram works reliably on most platforms and it is definitely the way to go. Romcc helps in cases where we don't have that, so we get something up easily. On PPC it just works I think. Arm and Mips are not supported in LinuxBIOS yet, but many of these systems (embedded and/or with a fixed amount of memory soldered on) are a lot easier to set up than the x86 (-64) boxes we support in LinuxBIOS.
Is memory setup done so very much different and is so much more complex in x86? For my port, SC2200, it looks about same to me.
It is pretty complex on AMD64 which was the reason for romcc. And since its there we use it to make readable C code rather than Assembler init code. It's a matter of maintainability and ease of use. 100 lines of C are easier to read than 100 lines of Assembler. Well, for most of us.
(could be because of my embedded background, most targets have had defined memory size so mem sizing isn't a problem...)
Yeah, with a fixed memory size the ram initialization is more or less poking some values into some machine specific registers. There you dont even gain a lot of readability with C. But imagine you read the SPD rom sitting on each DDR Ram module and you have to find out how many rows and columns it is, find a timing supported by all installed modules and generate values that the chipset understands. And then something doesnt work and you want to output some debugging information but your functions are tight in registers (which is usually the case on x86 machines) so you have to reorganize lots of your code.
romcc does that. It's a great tool. But in a "perfect world" we would not need it ;-)
Stefan