Hi there- I'd like to increase the size of my flash chip from 8MB to 16MB. From poking at stuff and asking dumb questions in the #coreboot channel, I've gathered I need to make the following changes, but I'm not 100% sure these are correct.
If anyone could look this over and point me in the right direction before I flash a broken image, I would appreciate that.
*1)* descriptor.ifd: Use ifdtool on descriptor.bin to increase the density from 8M to 16M. This appears to work.
*2)* Modify fmap - currently looks like this:
FLASH@0xff800000 0x800000 { BIOS@0x200000 0x600000 { EC@0x0 0x10000 RW_MRC_CACHE@0x10000 0x10000 SMMSTORE@0x20000 0x40000 FMAP@0x60000 0x200 CONSOLE@0x60200 0x20000 COREBOOT(CBFS)@0x80200 0x57FE00 } }
and it should become:
FLASH@0xff800000 0x1000000 { <- new chip size BIOS@0x200000 0xE00000 { <-new BIOS region size EC@0x0 0x10000 RW_MRC_CACHE@0x10000 0x10000 SMMSTORE@0x20000 0x40000 FMAP@0x60000 0x200 CONSOLE@0x60200 0x20000 COREBOOT(CBFS)@0x80200 0xD7FE00 <- new CBFS size } }
Question: I read that an FMAP file overrides CBFS_SIZE, if such is provided.Since the coreboot .config still says CBFS_SIZE=0x200000, but an FMAP has always been provided, is it true that 0x200000 was never the result / used?
*4) *Adjust ROM size to 16MB in menuconfig *5)* Provide new FMAP and descriptor to menuconfig *6) *Use an external flasher to flash this new image
Am I missing any steps, and are the above modifications correct?
Thanks, Rafael
Hi Rafael,
On 14.01.20 02:18, Rafael Send wrote:
*2)* Modify fmap - currently looks like this:
... and it should become:
FLASH@0xff800000 0x1000000 { <- new chip size
you should also lower the offset to 0xff000000. The flash is (assumed) to be mapped right below 4GiB. So it should end (sum of the two numbers) at 0x100000000 (excluding).
Question: I read that an FMAP file overrides CBFS_SIZE, if such is provided.Since the coreboot .config still says CBFS_SIZE=0x200000, but an FMAP has always been provided, is it true that 0x200000 was never the result / used?
That's correct.
Am I missing any steps, and are the above modifications correct?
What happened to 3)? :)
Don't you need an ME image? how does it get to the new flash chip?
You also have to increase the size of the BIOS region in the IFD.
The IFD also contains a small table about flash chips (e.g. to know the erase opcode / block size). I'm not sure if you need to adapt it or if the PCH would fall back to automatic discovery via SFDP. Might also depend on the PCH generation. I would match it with the new chip to be on the safe side.
IMHO, the worst thing you can do is to assume that it will work on the first try. Better be prepared for more external flashing.
Nico
I am really curious how will it go. Please do post updates here. Since I was thinking about doing the same just to fit freedos and space invaders on the chip^^
May I ask which board is it?
Greets,
On January 14, 2020 1:18:09 AM UTC, Rafael Send flyingfishfinger@gmail.com wrote:
Hi there- I'd like to increase the size of my flash chip from 8MB to 16MB. From poking at stuff and asking dumb questions in the #coreboot channel, I've gathered I need to make the following changes, but I'm not 100% sure these are correct.
If anyone could look this over and point me in the right direction before I flash a broken image, I would appreciate that.
*1)* descriptor.ifd: Use ifdtool on descriptor.bin to increase the density from 8M to 16M. This appears to work.
*2)* Modify fmap - currently looks like this:
FLASH@0xff800000 0x800000 { BIOS@0x200000 0x600000 { EC@0x0 0x10000 RW_MRC_CACHE@0x10000 0x10000 SMMSTORE@0x20000 0x40000 FMAP@0x60000 0x200 CONSOLE@0x60200 0x20000 COREBOOT(CBFS)@0x80200 0x57FE00 } }
and it should become:
FLASH@0xff800000 0x1000000 { <- new chip size BIOS@0x200000 0xE00000 { <-new BIOS region size EC@0x0 0x10000 RW_MRC_CACHE@0x10000 0x10000 SMMSTORE@0x20000 0x40000 FMAP@0x60000 0x200 CONSOLE@0x60200 0x20000 COREBOOT(CBFS)@0x80200 0xD7FE00 <- new CBFS size } }
Question: I read that an FMAP file overrides CBFS_SIZE, if such is provided.Since the coreboot .config still says CBFS_SIZE=0x200000, but an FMAP has always been provided, is it true that 0x200000 was never the result / used?
*4) *Adjust ROM size to 16MB in menuconfig *5)* Provide new FMAP and descriptor to menuconfig *6) *Use an external flasher to flash this new image
Am I missing any steps, and are the above modifications correct?
Thanks, Rafael
On Tue, Jan 14, 2020 at 10:32 AM Nico Huber nico.h@gmx.de wrote:
The IFD also contains a small table about flash chips (e.g. to know the erase opcode / block size). I'm not sure if you need to adapt it or if the PCH would fall back to automatic discovery via SFDP. Might also depend on the PCH generation. I would match it with the new chip to be on the safe side.
This is an optional step. This table is more about letting ME know how to write to the specific chip. see https://github.com/corna/me_cleaner/issues/80
IMHO, the worst thing you can do is to assume that it will work on the first try. Better be prepared for more external flashing
It doesnt work on the first try, take it from me. I found the easiest way to do it was to use the stock factory rom, modify that with IFDtool and then use the newly modified IFD to build coreboot (while specifying new CBFS size inside of coreboot menuconfig)
I did this exact thing while porting heads to a new motherboard, as the 4mb SPI was too small. Heres the steps, and they work.
https://github.com/osresearch/heads/issues/547#issuecomment-485887948
Step2 is optional and makes no difference to coreboot functionality. As noted above, its purely for ME.
re-sending to coreboot list due to a problem with my gmail subscription.
On Tue, Jan 14, 2020 at 10:32 AM Nico Huber nico.h@gmx.de wrote:
The IFD also contains a small table about flash chips (e.g. to know the erase opcode / block size). I'm not sure if you need to adapt it or if the PCH would fall back to automatic discovery via SFDP. Might also depend on the PCH generation. I would match it with the new chip to be on the safe side.
This is an optional step. This table is more about letting ME know how to write to the specific chip. see https://github.com/corna/me_cleaner/issues/80
IMHO, the worst thing you can do is to assume that it will work on the first try. Better be prepared for more external flashing
It doesnt work on the first try, take it from me. I found the easiest way to do it was to use the stock factory rom, modify that with IFDtool and then use the newly modified IFD to build coreboot (while specifying new CBFS size inside of coreboot menuconfig)
I did this exact thing while porting heads to a new motherboard, as the 4mb SPI was too small. Heres the steps, and they work.
https://github.com/osresearch/heads/issues/547#issuecomment-485887948
Step2 is optional and makes no difference to coreboot functionality. As noted above, its purely for ME.
I did this exact thing while porting heads to a new motherboard, as the 4mb SPI was too small. Heres the steps, and they work.
Ok now I'm a bit confused. Can you elaborate on what some of your steps do?
- When you set chip size to 16MB but use the stock descriptor, you've basically got a coreboot build with an empty / unused top half? So then step 3 tells the IFD to actually use the rest, so to speak? - I need to adjust my FMAP in addition to performing step 5? I think that's what I was missing in my initial assumptions. - In step 6, can one not modify the IFD without doing it through the actual ROM image?
Thanks, R
On Tue, Jan 14, 2020 at 9:26 AM Simon Newton simon.newton@gmail.com wrote:
re-sending to coreboot list due to a problem with my gmail subscription.
On Tue, Jan 14, 2020 at 10:32 AM Nico Huber nico.h@gmx.de wrote:
The IFD also contains a small table about flash chips (e.g. to know the erase opcode / block size). I'm not sure if you need to adapt it or if the PCH would fall back to automatic discovery via SFDP. Might also depend on the PCH generation. I would match it with the new chip to be on the safe side.
This is an optional step. This table is more about letting ME know how to write to the specific chip. see https://github.com/corna/me_cleaner/issues/80
IMHO, the worst thing you can do is to assume that it will work on the first try. Better be prepared for more external flashing
It doesnt work on the first try, take it from me. I found the easiest way to do it was to use the stock factory rom, modify that with IFDtool and then use the newly modified IFD to build coreboot (while specifying new CBFS size inside of coreboot menuconfig)
I did this exact thing while porting heads to a new motherboard, as the 4mb SPI was too small. Heres the steps, and they work.
https://github.com/osresearch/heads/issues/547#issuecomment-485887948
Step2 is optional and makes no difference to coreboot functionality. As noted above, its purely for ME. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Tue, Jan 14, 2020 at 5:49 PM Rafael Send flyingfishfinger@gmail.com wrote:
Ok now I'm a bit confused. Can you elaborate on what some of your steps
do?
1. Make an image of 16M in coreboot for your supported device 2. Set VSCC table to new chip (I found this not really necessary, ive seen no PCH problems by zeroing this out on a P8h61) 3. IFDtool to set density 4. rename file (I hate the .new extension thing) 5&6. Use IFDtool to dump ROM layout to layout.txt and edit it to 16M or 8M BIOS region and write back 7. rename (i really hate the whole .new.new.new extension thing) 8. Extract new IFD with correct sizing 9. make coreboot 16M rom (dont forget to include a ME image int he build config - neutered if you prefer)
(at that point, you use your flasher - ch341a for me - to burn the new rom and fit it to the mobo)
- I need to adjust my FMAP in addition to performing step 5? I think
that's what I was missing in my initial assumptions.
sizing is handed via step1, step 3 and setting CBFS size in menuconfig in coreboot.
- In step 6, can one not modify the IFD without doing it through the
actual ROM image?
Dont see why not. I just edited it before i extracted the IFD as it seemed logically correct.
-
AreYouLoco? -
Nico Huber -
Rafael Send -
Simon Newton