I should have fixed the sizeram function for all of the x86 ports. So while I don't expect everything to work it should mostly a matter of cleanup of the configuration files now, so it should be pretty easy.
The one remaining x86 gotcha is likely adding support for the via c3 and the transmeta TM5800 cpus that it looks like we try and support. It looks like we have a lot of ports that were started and not completed :(
PPC is still broken. I need to be fresh to tackle fixing it up. At the moment I don't have the slightest clue what the PPC code flow looks like. I don't see hide nor hare of the dynamic device tree in the ppc code I have looked at, so I don't know yet where to start to convert the code.
Anyway the maelstrom of changes is settling down. So feel free to take your favorite port and see if you can get it building or running again.
A build success report from the Stefan's all port builder would will be interesting.
Eric
sizeram removal/conversion. - mem.h and sizeram.h and all includes killed because the are no longer needed. - linuxbios_table.c updated to directly look at the device tree for occupied memory areas. - first very incomplete stab a converting the ppc code to work with the dynamic device tree - Ignore resources before we have read them from devices, (if the device is disabled ignore it's resources). - First stab at Pentium-M support - add part/init_timer.h making init_timer conditional until there is a better way of handling it. - Converted all of the x86 sizeram to northbridge set_resources functions. CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: src/arch/i386/boot/linuxbios_table.c CVS: src/arch/i386/boot/linuxbios_table.h CVS: src/arch/ppc/boot/linuxbios_table.c src/arch/ppc/boot/tables.c CVS: src/arch/ppc/lib/cpu.c src/arch/ppc/lib/cpuid.c CVS: src/boot/hardwaremain.c src/config/Options.lb CVS: src/cpu/amd/model_fxx/Config.lb src/cpu/x86/tsc/Config.lb CVS: src/devices/device.c src/include/part/fallback_boot.h CVS: src/mainboard/arima/hdama/Options.lb CVS: src/mainboard/arima/hdama/auto.c CVS: src/mainboard/digitallogic/adl855pc/Config.lb CVS: src/mainboard/emulation/qemu-i386/Config.lb CVS: src/northbridge/amd/amdk8/northbridge.c CVS: src/northbridge/emulation/qemu-i386/northbridge.c CVS: src/northbridge/intel/e7501/northbridge.c CVS: src/northbridge/intel/i855pm/northbridge.c CVS: src/northbridge/motorola/mpc107/mpc107.c CVS: src/northbridge/transmeta/tm5800/northbridge.c CVS: src/northbridge/via/vt8601/northbridge.c CVS: src/northbridge/via/vt8623/northbridge.c CVS: src/southbridge/intel/i82870/p64h2_pci_parity.c CVS: Added Files: CVS: src/include/part/init_timer.h CVS: Removed Files: CVS: src/include/mem.h src/include/part/sizeram.h CVS: ----------------------------------------------------------------------
On Wed, 27 Oct 2004, Eric W. Biederman wrote:
The one remaining x86 gotcha is likely adding support for the via c3 and the transmeta TM5800 cpus that it looks like we try and support. It looks like we have a lot of ports that were started and not completed :(
yes, transmeta refused to help with the details of DDR on the new cpu, in spite of promises to do so, hence that effort (with a 3rd party) ended.
A shame.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Wed, 27 Oct 2004, Eric W. Biederman wrote:
The one remaining x86 gotcha is likely adding support for the via c3 and the transmeta TM5800 cpus that it looks like we try and support. It looks like we have a lot of ports that were started and not completed :(
yes, transmeta refused to help with the details of DDR on the new cpu, in spite of promises to do so, hence that effort (with a 3rd party) ended.
A shame.
Yes. Somehow I would have suspected the procedure would have been the same, or simpler though. Dump the SPD values from the DIMMs into the northbridge.
Eric
On Wed, 27 Oct 2004, Eric W. Biederman wrote:
Yes. Somehow I would have suspected the procedure would have been the same, or simpler though. Dump the SPD values from the DIMMs into the northbridge.
the new policy is we put our effort first into efforts with cooperative vendors, and the other efforts take a back seat.
I agree with you, we could reverse engineer this easily, but I do know of a company that has done the port, so we are waiting to talk to them first.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Wed, 27 Oct 2004, Eric W. Biederman wrote:
Yes. Somehow I would have suspected the procedure would have been the same, or simpler though. Dump the SPD values from the DIMMs into the northbridge.
the new policy is we put our effort first into efforts with cooperative vendors, and the other efforts take a back seat.
I think that is largely how I have always worked. Although it is slowly getting to the point where it is interesting to handle more cases.
I agree with you, we could reverse engineer this easily, but I do know of a company that has done the port, so we are waiting to talk to them first.
That's fine.
Eric
-
ebiederman＠lnxi.com -
Ronald G. Minnich