Hi,
in v2 we enable full ROM decoding before initram. For VIA C7 and Intel Core 2 Duo, that means the CAR area is inside the mapped ROM contents.
The most obvious problem arising from that is having to make sure fallback/initram and normal/initram end up in a place in ROM that is _not_ behind CAR.
One solution is to restrict the location of initram to the upper 1 MB of the ROM chip. I can work with that, but we should definitely document these restrictions.
Oh, and for chips which are behind some translation unit with limited window capabilities (like the IT8716 LPC->SPI translation) we need to have initram inside the decoded window anyway.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
in v2 we enable full ROM decoding before initram. For VIA C7 and Intel Core 2 Duo, that means the CAR area is inside the mapped ROM contents.
Yes. Is that a CPU requirement or just a decision made in code?
It would of course be best to have CAR at an address not so likely to collide with the flash.
//Peter
Sent from my iPhone
On 21.11.2008, at 16:47, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
wrote:
Hi,
in v2 we enable full ROM decoding before initram. For VIA C7 and Intel Core 2 Duo, that means the CAR area is inside the mapped ROM contents.
The most obvious problem arising from that is having to make sure fallback/initram and normal/initram end up in a place in ROM that is _not_ behind CAR.
One solution is to restrict the location of initram to the upper 1 MB of the ROM chip. I can work with that, but we should definitely document these restrictions.
Oh, and for chips which are behind some translation unit with limited window capabilities (like the IT8716 LPC->SPI translation) we need to have initram inside the decoded window anyway.
Regards, Carl-Daniel
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On 21.11.2008, at 16:47, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
wrote:
Hi,
in v2 we enable full ROM decoding before initram. For VIA C7 and Intel Core 2 Duo, that means the CAR area is inside the mapped ROM contents.
That observation is wrong for the intel core case. CAR lives 1MiB below the rom there. So no problems arise.
Stefan
On 21.11.2008 21:34, Stefan Reinauer wrote:
On 21.11.2008, at 16:47, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi,
in v2 we enable full ROM decoding before initram. For VIA C7 and Intel Core 2 Duo, that means the CAR area is inside the mapped ROM contents.
That observation is wrong for the intel core case. CAR lives 1MiB below the rom there. So no problems arise.
Core 2 Duo CAR lives at 0xFFEF0000 with a size of 32 kiB in v3. Core 2 Duo CAR lives at 0xFFDF8000 with a size of 32 kiB in v2 for the Kontron board.
My observation is correct for any ROM larger than 1 MiB (to be exact, 1024+64 kiB) in v3 and for any ROM larger than 2 MiB (2048+32 kiB) in v2.
How variable is the location where we can have CAR in the Core 2 Duo? Is anything in the top 16 MiB allowed?
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 21.11.2008 21:34, Stefan Reinauer wrote:
On 21.11.2008, at 16:47, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi,
in v2 we enable full ROM decoding before initram. For VIA C7 and Intel Core 2 Duo, that means the CAR area is inside the mapped ROM contents.
That observation is wrong for the intel core case. CAR lives 1MiB below the rom there. So no problems arise.
Core 2 Duo CAR lives at 0xFFEF0000 with a size of 32 kiB in v3. Core 2 Duo CAR lives at 0xFFDF8000 with a size of 32 kiB in v2 for the Kontron board.
Non of the Intel stuff in v3 even compiles, so don't worry about that too much.
In v2, the CAR lives 1M below the ROM. If you change the ROM size, you have to change the CAR BASE too. The code can use a little brush-up there, but since we never had to use flash chips larger than 8MBit it does not really matter.
How variable is the location where we can have CAR in the Core 2 Duo? Is anything in the top 16 MiB allowed?
It needs to live 1MB below the flash part.
On 21.11.2008 22:48, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 21.11.2008 21:34, Stefan Reinauer wrote:
On 21.11.2008, at 16:47, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi,
in v2 we enable full ROM decoding before initram. For VIA C7 and Intel Core 2 Duo, that means the CAR area is inside the mapped ROM contents.
That observation is wrong for the intel core case. CAR lives 1MiB below the rom there. So no problems arise.
Core 2 Duo CAR lives at 0xFFEF0000 with a size of 32 kiB in v3. Core 2 Duo CAR lives at 0xFFDF8000 with a size of 32 kiB in v2 for the Kontron board.
None of the Intel stuff in v3 even compiles, so don't worry about that too much.
OK. I'll use v2 as reference for C2D from now on.
In v2, the CAR lives 1M below the ROM. If you change the ROM size, you have to change the CAR BASE too. The code can use a little brush-up there, but since we never had to use flash chips larger than 8MBit it does not really matter.
How variable is the location where we can have CAR in the Core 2 Duo? Is anything in the top 16 MiB allowed?
It needs to live 1MB below the flash part.
Since the flash part size can't be determined automatically (the flash chip will decode any address you throw at it), that means the "1 MB below flash" requirement is either overspecified or incorrect for flash sizes != 1 MB. I'm not blaming you, I'm just trying to understand and it wouldn't be the first time that some data sheets are unclear.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Since the flash part size can't be determined automatically (the flash chip will decode any address you throw at it), that means the "1 MB below flash" requirement is either overspecified or incorrect for flash sizes != 1 MB. I'm not blaming you, I'm just trying to understand and it wouldn't be the first time that some data sheets are unclear.
The data sheet is perfectly clear about this. And of course it does not explain why. Anyways, I don't want to have to shoot you because I talked about this topic too much.
Hi Jason,
do you know if the C7 CAR location is fixed at 0xFFEF0000? It would be great if we could move it to 0xFFBF0000. That way, the CAR area will not collide with 4 MByte ROMs anymore.
Regards, Carl-Daniel
On 21.11.2008 16:47, Carl-Daniel Hailfinger wrote:
in v3 we enable full ROM decoding before initram. For VIA C7 and Intel Core 2 Duo, that means the CAR area is inside the mapped ROM contents.
The most obvious problem arising from that is having to make sure fallback/initram and normal/initram end up in a place in ROM that is _not_ behind CAR.
One solution is to restrict the location of initram to the upper 1 MB of the ROM chip. I can work with that, but we should definitely document these restrictions.
Oh, and for chips which are behind some translation unit with limited window capabilities (like the IT8716 LPC->SPI translation) we need to have initram inside the decoded window anyway.
Regards, Carl-Daniel
Hi Carl, No VIA's datasheet tell about the location of C7 CAR, and I remember once I used an address even lower than 0xFFBF0000 (NOT 0xc8000). Also I tried 0xFFBF0000 on my current v2-coreboot just now, the result is ok.
-----Original Message----- From: Carl-Daniel Hailfinger
[mailto:c-d.hailfinger.devel.2006@gmx.net]
Sent: Monday, November 24, 2008 10:51 AM To: Jason Zhao Cc: Coreboot Subject: Re: [coreboot] v3 CAR/ROM area collision on C7 and Core2Duo
Hi Jason,
do you know if the C7 CAR location is fixed at 0xFFEF0000? It would be great if we could move it to 0xFFBF0000. That way, the CAR area will
not
collide with 4 MByte ROMs anymore.
Regards, Carl-Daniel
On 21.11.2008 16:47, Carl-Daniel Hailfinger wrote:
in v3 we enable full ROM decoding before initram. For VIA C7 and
Intel
Core 2 Duo, that means the CAR area is inside the mapped ROM
contents.
The most obvious problem arising from that is having to make sure fallback/initram and normal/initram end up in a place in ROM that is _not_ behind CAR.
One solution is to restrict the location of initram to the upper 1
MB of
the ROM chip. I can work with that, but we should definitely
document
these restrictions.
Oh, and for chips which are behind some translation unit with
limited
window capabilities (like the IT8716 LPC->SPI translation) we need
to
have initram inside the decoded window anyway.
Regards, Carl-Daniel
Hi Jason,
On 24.11.2008 04:31, JasonZhao@viatech.com.cn wrote:
No VIA's datasheet tell about the location of C7 CAR, and I remember once I used an address even lower than 0xFFBF0000 (NOT 0xc8000). Also I tried 0xFFBF0000 on my current v2-coreboot just now, the result is ok.
Thanks a lot for checking this. If you find some free time, it would be great if you could test 0xFEC00000 as well. That location is 20 MB below 4GB and the lowest location inside the DEVICE_MEM_HIGH protection window where coreboot will not place any device memory regions, so it is free for ROM and CAR. If that works, we have found a really collision-free window even for the biggest SPI ROMs.
Regards, Carl-Daniel
Hi Jason,
thanks for checking this so fast!
On 26.11.2008 01:05, Carl-Daniel Hailfinger wrote:
On 24.11.2008 04:31, JasonZhao@viatech.com.cn wrote:
No VIA's datasheet tell about the location of C7 CAR, and I remember once I used an address even lower than 0xFFBF0000 (NOT 0xc8000). Also I tried 0xFFBF0000 on my current v2-coreboot just now, the result is ok.
Thanks a lot for checking this. If you find some free time, it would be great if you could test 0xFEC00000 as well. That location is 20 MB below 4GB and the lowest location inside the DEVICE_MEM_HIGH protection window where coreboot will not place any device memory regions, so it is free for ROM and CAR. If that works, we have found a really collision-free window even for the biggest SPI ROMs.
0xFEC00000 with size 0x8000 (32k) works as confirmed by you in IRC.
I'll prepare a patch for v2 and v3 to move the VIA CAR location to 0xFEC00000.
Regards, Carl-Daniel
On Tue, Nov 25, 2008 at 7:33 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
0xFEC00000 with size 0x8000 (32k) works as confirmed by you in IRC.
I'll prepare a patch for v2 and v3 to move the VIA CAR location to 0xFEC00000.
I am somewhat concerned about this idea. FExxxxxx seems to be the "vendor play area" for putting hardware in, FEC even more so.
Can we back out to our original motivation for doing this? I think I understand it but can we go through it one more time?
As I understand it the idea of moving this around it so limit restrictions on where initram can be in FLASH -- I'm not sure it would not make more sense to just tell people "initram must be in high 1 MB" and leave it at that.
Generality is nice, but taken to extremes it can make life more complex. See Moon's old essay from long ago (I posted it to the list) on that topic.
What are we gaining? Do we really need it?
ron
On 28.11.2008 07:43, ron minnich wrote:
On Tue, Nov 25, 2008 at 7:33 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
0xFEC00000 with size 0x8000 (32k) works as confirmed by you in IRC.
I'll prepare a patch for v2 and v3 to move the VIA CAR location to 0xFEC00000.
I am somewhat concerned about this idea. FExxxxxx seems to be the "vendor play area" for putting hardware in, FEC even more so.
Yes, it seems that way.
Can we back out to our original motivation for doing this? I think I understand it but can we go through it one more time?
Sure.
As I understand it the idea of moving this around it so limit restrictions on where initram can be in FLASH -- I'm not sure it would not make more sense to just tell people "initram must be in high 1 MB" and leave it at that.
Sure, that would work as well. However, my goal is to make sure that CAR contents will never be written to flash address space. That may sound strange, but if you recall the ICH network ROM disaster (not related to coreboot in any way), it suddenly becomes obvious that protecting flash from accidental writes is indeed a priority. Due to the way SPI flash is addressed out-of-band, I'm not particularly worried about it, but I'd prefer to keep CAR outside the decode area for any FWH/LPC/parallel flash chip. Many chipsets map the ROMs in 4 MByte chunks to the address space, so any write outside the top 4 MB should in theory go to a flash chip which is not the boot flash chip. On regular boards with only one flash chip, this means writes outside the top 4MB will get discarded.
Generality is nice, but taken to extremes it can make life more complex. See Moon's old essay from long ago (I posted it to the list) on that topic.
What are we gaining? Do we really need it?
See above. I have become paranoid about v3 behaviour. We still have too many nasty bugs in there and it looks like some of them are coming to bite us or are already doing so. The recent problems where simple changes seemed to kill booting on Core2Duo demonstrate the fragility of our code.
Short version: CAR outside top 4 MB would be nice, but it should be at least outside top 1 MB. And we need to figure out the problems Intel has.
Regards, Carl-Daniel
0xFEC00000 as well. That location is 20 MB below 4GB and the lowest
0xFEC0_0000 may be fixed location IO APIC. Other possible locations are 0xFECX_YZ00 (not that 0xFEC cannot be changed) 0xFEEx_xxxx are internal APIC cycles for IRQ (MSI)
FEC0_0000 - FEC7_FFFF VIA APIC in SB (fixed) (FEC8_0000 - FECB_FFFF -VIA VPXII APIC)
FED4_4000 - FED4_FFFF trusted platform module MEM decode (fixed)
Rudolf
On 26.11.2008 23:02, Rudolf Marek wrote:
0xFEC00000 as well. That location is 20 MB below 4GB and the lowest
0xFEC0_0000 may be fixed location IO APIC. Other possible locations are 0xFECX_YZ00 (not that 0xFEC cannot be changed) 0xFEEx_xxxx are internal APIC cycles for IRQ (MSI)
FEC0_0000 - FEC7_FFFF VIA APIC in SB (fixed) (FEC8_0000 - FECB_FFFF -VIA VPXII APIC)
FED4_4000 - FED4_FFFF trusted platform module MEM decode (fixed)
Thanks, I added this information to a wiki page. The wiki page is incomplete, feel free to extend it. http://www.coreboot.org/Memory_map
Regards, Carl-Daniel
FECC_0000 to FECC_00FF is used by VIA I/O APIC in NB(P4M890,CN896,VX8000...) (It also use 0xFECX_YZ00,but X default =0Ch) E000_0000_? is MMIO for PCI-E's Extended Configuration Space
SMI handler:may locate at CSEG or HSEG or TSEG (mostly use) SMI-CSEG A0000h-BFFFFh (128KB) HSEG FEEA0000h-FEEBFFFFh TSEG MEMTOP-1MB-MEMTOP (1M size)
-----Original Message----- From: Carl-Daniel Hailfinger
[mailto:c-d.hailfinger.devel.2006@gmx.net]
Sent: Friday, November 28, 2008 12:08 AM To: Rudolf Marek Cc: coreboot@coreboot.org; Jason Zhao Subject: Re: [coreboot] v3 CAR/ROM area collision on C7 and Core2Duo
On 26.11.2008 23:02, Rudolf Marek wrote:
0xFEC00000 as well. That location is 20 MB below 4GB and the lowest
0xFEC0_0000 may be fixed location IO APIC. Other possible locations are 0xFECX_YZ00 (not that 0xFEC cannot be changed) 0xFEEx_xxxx are internal APIC cycles for IRQ (MSI)
FEC0_0000 - FEC7_FFFF VIA APIC in SB (fixed) (FEC8_0000 - FECB_FFFF -VIA VPXII APIC)
FED4_4000 - FED4_FFFF trusted platform module MEM decode (fixed)
Thanks, I added this information to a wiki page. The wiki page is incomplete, feel free to extend it. http://www.coreboot.org/Memory_map
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
JasonZhao＠viatech.com.cn -
Peter Stuge -
ron minnich -
Rudolf Marek -
Stefan Reinauer