Josh Stump wrote:
I have a Lenovo T60 Type 8743-GZU. From experience I know that with the stock BIOS if I put in 4Gb of RAM I can only utilze 3Gb even with a 64bit OS installed. Is this a limitation of the stock BIOS that coreboot can overcome or is this simply a chipset limitation and even if I got coreboot flashed I still would only have use of 4Gb of RAM. Does anyone know for certain?
It is a limitation of the factory BIOS. For comparison, on an X60 with 4GB of RAM with coreboot there is immediately 3.2GB available for OS use.
This is with the standard resource allocator in coreboot, ie. without any intense optimizations. If you work on optimizing this, you may get even more usable RAM.
The technical limit is that many of the hardware parts in the system require that they be memory mapped into the CPU bus, and that is only 32 bits, so some of the 4GB of RAM will be "covered" by these hardware memory regions, but with coreboot you have an opportunity to work on reducing this to the bare minimum.
what parts I might need to flash my rom over.
You need the flashrom source, a small patch, and my bucts utility from http://git.stuge.se/?p=bucts.git
Patch flashrom to use RES1 SPI identification and spi_chip_write1 for your flash chip, as well as change the flash chip model id to fit the RES1 command.
then run flashrom -p internal:laptop=force_I_want_a_brick -r factory.bin # this step is IMPORTANT since the factory BIOS in your machine is # tied to your particular system board "planar in IBM FRU terms" with # a unique ID not present in factory BIOS updates
then build coreboot.rom # note that you must include the correct VGA BIOS for your machine in # order to have any graphics working when you use coreboot
then run dd if=coreboot.rom of=top64k.bin bs=1 \ skip=$[sizeof(coreboot.rom) - 0x10000] count=64k
then run dd if=top64k of=coreboot.rom bs=1 \ seek=$[sizeof(coreboot.rom) - 0x20000] count=64k conv=notrunc
then run bucts 1
then run flashrom -p internal:laptop=force_I_want_a_brick -w coreboot.rom # this will be slow, and shall generate an erase error at e.g. 0x1f0000 # when working with a 2 Mbyte flash chip.
then power cycle, now starting with coreboot
then undo the flashrom patch, so that you have a stock flashrom
then run bucts 0
then run flashrom -p internal:laptop=force_I_want_a_brick -w coreboot.rom # his will successfully overwrite the entire flash chip, including # the last 64k that were write protected with the factory BIOS.
Many thanks to Sven for figuring out this procedure! It has been successfully performed on at least two X60 machines with factory BIOS.
ron minnich wrote:
It's almost certainly impossible to get coreboot going on your T60.
I believe Sven's port is working!
//Peter
Peter Stuge wrote:
then run dd if=coreboot.rom of=top64k.bin bs=1 \ skip=$[sizeof(coreboot.rom) - 0x10000] count=64k
Insert one step here:
then run dd if=coreboot.rom bs=1 \ skip=$[sizeof(coreboot.rom) - 0x10000] count=64k | hexdump # and verify that the complete range is filled with ff bytes before # proceeding further. if this is not the case, the coreboot image # needs to be recreated with the second-to-last 64kbyte block unused
then run dd if=top64k of=coreboot.rom bs=1 \ seek=$[sizeof(coreboot.rom) - 0x20000] count=64k conv=notrunc
That should of course read:
then run dd if=top64k.bin of=coreboot.rom bs=1 \ seek=$[sizeof(coreboot.rom) - 0x20000] count=64k conv=notrunc
//Peter
On Tue, Jan 17, 2012 at 1:51 PM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
It's almost certainly impossible to get coreboot going on your T60.
I believe Sven's port is working!
on x60, good news. But T60?
ron
-
Peter Stuge -
ron minnich