Hi,
I've narrowed down where the CBMEM console is getting corrupted and found a work around that gets it working again. It is getting corrupted in the FSP Early Init function. So in the Intel blob, not coreboot.
I added logs to cbmemc_init() and cbmrmc_reinit() that show the console pointer, size, cursor and the first 64 bytes of the console (including size and console).
Right before the call to FspInitApi() in fsp_early_init(): fsp_early_init: cbm_cons_p: fef00000 size=3064 cur=2606 fef00000: f8 0b 00 00 7b 0a 00 00 63 62 6d 65 6d 63 5f 69 ........cbmemc_i fef00010: 6e 69 74 3a 20 63 62 6d 5f 63 6f 6e 73 5f 70 3a nit: cbm_cons_p: fef00020: 20 66 65 66 30 30 30 30 30 20 73 69 7a 65 3d 33 fef00000 size=3 fef00030: 30 36 34 20 63 75 72 3d 30 0a 66 65 66 30 30 30 064 cur=0.fef000
And this is at the top of romstage_main_continue(): romstage_main_continue: cbm_cons_p: 00000b96 size=2052398204 cur=1024945500 00000b96: 7c 1c 55 7a bd 6d 17 3d 17 a9 76 69 ee 07 d1 b8 |.Uz.m.=..vi.... 00000ba6: fa 6b 75 85 ee 7a dd 8f e9 48 59 93 b4 f8 0a ce .ku..z...HY..... 00000bb6: 1c dc fe a4 09 d6 ba 1d 88 8f 23 e4 40 cc 88 cd ..........#.@... 00000bc6: 90 91 53 e4 71 6d 90 1d bd e9 fa 13 a8 16 fd b5 ..S.qm..........
So, the FSP is trashing the CAR variables.
I looked at the changes to src/arch/x86/car.ld and see that the CONSOLE line was moved before _car_data_start. That move appears to have been in commit dd6fa93d by Aaron Durbin. http://review.coreboot.org/#/c/11740/3/src/arch/x86/car.ld
When I moved that CONSOLE line back to after _car_data_end, the console works again. That also fixes the timestamp table infinite loop issue.
So, I have a work-around. However, I suspect that the root issue of the FSP trashing CAR variables persists.
My initial email about the timestamp issue is here: http://www.coreboot.org/pipermail/coreboot/2015-November/080719.html
I'm not sure what to do about this. The above change seems reasonable and needed for verstage support, so sending my 'fix' upstream probably isn't viable.
Suggestions?
Thanks, Ben
Hi Ben, I'm still trying to get to this. I don't know if you saw how different the fsp cbmem route is from other platforms. The fsp copies the contents of the car stack to the top of memory when it tears down the cache as ram. The pointer to that gets saved and passed to the cbmem transfer code. Something has obviously happened to this sequence. I plan on trying to bisect the change. The latest I'll be able to get to that is this weekend.
Martin On Thu, Nov 19, 2015 at 17:07 Ben Gardner gardner.ben@gmail.com wrote:
Hi,
I've narrowed down where the CBMEM console is getting corrupted and found a work around that gets it working again. It is getting corrupted in the FSP Early Init function. So in the Intel blob, not coreboot.
I added logs to cbmemc_init() and cbmrmc_reinit() that show the console pointer, size, cursor and the first 64 bytes of the console (including size and console).
Right before the call to FspInitApi() in fsp_early_init(): fsp_early_init: cbm_cons_p: fef00000 size=3064 cur=2606 fef00000: f8 0b 00 00 7b 0a 00 00 63 62 6d 65 6d 63 5f 69 ........cbmemc_i fef00010: 6e 69 74 3a 20 63 62 6d 5f 63 6f 6e 73 5f 70 3a nit: cbm_cons_p: fef00020: 20 66 65 66 30 30 30 30 30 20 73 69 7a 65 3d 33 fef00000 size=3 fef00030: 30 36 34 20 63 75 72 3d 30 0a 66 65 66 30 30 30 064 cur=0.fef000
And this is at the top of romstage_main_continue(): romstage_main_continue: cbm_cons_p: 00000b96 size=2052398204 cur=1024945500 00000b96: 7c 1c 55 7a bd 6d 17 3d 17 a9 76 69 ee 07 d1 b8 |.Uz.m.=..vi.... 00000ba6: fa 6b 75 85 ee 7a dd 8f e9 48 59 93 b4 f8 0a ce .ku..z...HY..... 00000bb6: 1c dc fe a4 09 d6 ba 1d 88 8f 23 e4 40 cc 88 cd ..........#.@... 00000bc6: 90 91 53 e4 71 6d 90 1d bd e9 fa 13 a8 16 fd b5 ..S.qm..........
So, the FSP is trashing the CAR variables.
I looked at the changes to src/arch/x86/car.ld and see that the CONSOLE line was moved before _car_data_start. That move appears to have been in commit dd6fa93d by Aaron Durbin. http://review.coreboot.org/#/c/11740/3/src/arch/x86/car.ld
When I moved that CONSOLE line back to after _car_data_end, the console works again. That also fixes the timestamp table infinite loop issue.
So, I have a work-around. However, I suspect that the root issue of the FSP trashing CAR variables persists.
My initial email about the timestamp issue is here: http://www.coreboot.org/pipermail/coreboot/2015-November/080719.html
I'm not sure what to do about this. The above change seems reasonable and needed for verstage support, so sending my 'fix' upstream probably isn't viable.
Suggestions?
Thanks, Ben
On Thu, Nov 19, 2015 at 4:07 PM, Ben Gardner gardner.ben@gmail.com wrote:
Hi,
I've narrowed down where the CBMEM console is getting corrupted and found a work around that gets it working again. It is getting corrupted in the FSP Early Init function. So in the Intel blob, not coreboot.
I added logs to cbmemc_init() and cbmrmc_reinit() that show the console pointer, size, cursor and the first 64 bytes of the console (including size and console).
Right before the call to FspInitApi() in fsp_early_init(): fsp_early_init: cbm_cons_p: fef00000 size=3064 cur=2606 fef00000: f8 0b 00 00 7b 0a 00 00 63 62 6d 65 6d 63 5f 69 ........cbmemc_i fef00010: 6e 69 74 3a 20 63 62 6d 5f 63 6f 6e 73 5f 70 3a nit: cbm_cons_p: fef00020: 20 66 65 66 30 30 30 30 30 20 73 69 7a 65 3d 33 fef00000 size=3 fef00030: 30 36 34 20 63 75 72 3d 30 0a 66 65 66 30 30 30 064 cur=0.fef000
And this is at the top of romstage_main_continue(): romstage_main_continue: cbm_cons_p: 00000b96 size=2052398204 cur=1024945500 00000b96: 7c 1c 55 7a bd 6d 17 3d 17 a9 76 69 ee 07 d1 b8 |.Uz.m.=..vi.... 00000ba6: fa 6b 75 85 ee 7a dd 8f e9 48 59 93 b4 f8 0a ce .ku..z...HY..... 00000bb6: 1c dc fe a4 09 d6 ba 1d 88 8f 23 e4 40 cc 88 cd ..........#.@... 00000bc6: 90 91 53 e4 71 6d 90 1d bd e9 fa 13 a8 16 fd b5 ..S.qm..........
So, the FSP is trashing the CAR variables.
I looked at the changes to src/arch/x86/car.ld and see that the CONSOLE line was moved before _car_data_start. That move appears to have been in commit dd6fa93d by Aaron Durbin. http://review.coreboot.org/#/c/11740/3/src/arch/x86/car.ld
When I moved that CONSOLE line back to after _car_data_end, the console works again. That also fixes the timestamp table infinite loop issue.
That says to me that FSP is corrupting memory in general. It just so happens that moving console/timestamp away from that area means those things were corrupted. But... that moving may have broken CAR data migration. FSP 1.0 is not really coreboot friendly w.r.t. every other CAR implementation and how coreboot works.
So, I have a work-around. However, I suspect that the root issue of the FSP trashing CAR variables persists.
My initial email about the timestamp issue is here: http://www.coreboot.org/pipermail/coreboot/2015-November/080719.html
I'm not sure what to do about this. The above change seems reasonable and needed for verstage support, so sending my 'fix' upstream probably isn't viable.
Suggestions?
Thanks, Ben
-
Aaron Durbin -
Ben Gardner -
Martin Roth