Dear Keith,
Am 11.01.20 um 06:35 schrieb Keith Hui:
As I am still chasing how to enable SCSI termination on the board,
Due to the conversion, please always write if that worked with romcc, that means, a regression with C environment bootblock.
I've recompiled a few more times. Therefore I was able to upload two more clean board statuses, one with serial enabled and one without as you asked.
Thank you. Though I only see one more upload after the one I referred to.
$ git log --oneline -2 asus/p2b-ls dde01d781 asus/p2b-ls/4.11-839-g11c5b3b180/2020-01-10T21_51_08Z 5550a954e asus/p2b-ls/4.11-711-gd913036e18/2020-01-05T00_12_56Z
Without serial (`CONFIG_CONSOLE_SERIAL is not set`) has a total time of 2.9 seconds compared to 5.7 before.
Unfortunately without serial it still takes 2.5s in the romstage, and I can visually see the serial output going much slower than in ramstage. We should check the serial enabling code in romstage or even bootblock.
Is that a regression compared to romcc bootblock?
Also PS/2 keyboard init and sometimes video init is still finicky.
Ditto. Regression or not.
There are times when keyboard does not respond before the linux kernel is completely done,
Maybe that can be debugged in SeaBIOS, which you use as payload. Please increase the debug level for SeaBIOS, and post the logs from the working and non-working cases. (Please start a separate mailing list thread for that.)
and that could also be preventing my SCSI BIOS (extracted as is from factory image) from running through as it watches for a key combo to enter its setup interface.
Did that work with romcc. Please paste verbose SeaBIOS logs.
What is the commit that I should branch off of to get my romcc romstage back?
I assume it is the parent of commit 1fa240a3 (cpu/intel/slot_1: Move to C_ENVIRONMENT_BOOTBLOCK) [1], so commit df0c731e (mb/Kconfig: Add a warning on boards with a ROMCC_BOOTLOCK). Please test df0c731e, and upload the logs to the board status repository too.
Kind regards,
Paul
Hi,
On Sun, Jan 12, 2020 at 1:25 AM Paul Menzel pmenzel@molgen.mpg.de wrote:
Dear Keith,
Am 11.01.20 um 06:35 schrieb Keith Hui:
As I am still chasing how to enable SCSI termination on the board,
Due to the conversion, please always write if that worked with romcc, that means, a regression with C environment bootblock.
I've recompiled a few more times. Therefore I was able to upload two more clean board statuses, one with serial enabled and one without as you asked.
Thank you. Though I only see one more upload after the one I referred to.
$ git log --oneline -2 asus/p2b-ls dde01d781 asus/p2b-ls/4.11-839-g11c5b3b180/2020-01-10T21_51_08Z 5550a954e asus/p2b-ls/4.11-711-gd913036e18/2020-01-05T00_12_56ZWithout serial (`CONFIG_CONSOLE_SERIAL is not set`) has a total time of 2.9 seconds compared to 5.7 before.
Without considering the 2.5s in romstage mentioned below, the remaining 400 ms for the other stages is not bad.
Unfortunately without serial it still takes 2.5s in the romstage, and I can visually see the serial output going much slower than in ramstage. We should check the serial enabling code in romstage or even bootblock.
Is that a regression compared to romcc bootblock?
That might happen if there's no ROM caching. I saw something similar on gm45 until it was addressed. However, I am not sure if caching is doable on such old hardware.
Also PS/2 keyboard init and sometimes video init is still finicky.
Ditto. Regression or not.
There are times when keyboard does not respond before the linux kernel is completely done,
Maybe that can be debugged in SeaBIOS, which you use as payload. Please increase the debug level for SeaBIOS, and post the logs from the working and non-working cases. (Please start a separate mailing list thread for that.)
Note that coreboot should not do PS/2 keyboard init when SeaBIOS is used, as SeaBIOS already does its own keyboard init.
and that could also be preventing my SCSI BIOS (extracted as is from factory image) from running through as it watches for a key combo to enter its setup interface.
Did that work with romcc. Please paste verbose SeaBIOS logs.
What is the commit that I should branch off of to get my romcc romstage back?
I assume it is the parent of commit 1fa240a3 (cpu/intel/slot_1: Move to C_ENVIRONMENT_BOOTBLOCK) [1], so commit df0c731e (mb/Kconfig: Add a warning on boards with a ROMCC_BOOTLOCK). Please test df0c731e, and upload the logs to the board status repository too.
Kind regards,
Paul
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Best regards,
Angel
Dear Angel,
On 2020-01-12 10:50, Angel Pons wrote:
On Sun, Jan 12, 2020 at 1:25 AM Paul Menzel pmenzel@molgen.mpg.de wrote:
Dear Keith,
Am 11.01.20 um 06:35 schrieb Keith Hui:
As I am still chasing how to enable SCSI termination on the board,
Due to the conversion, please always write if that worked with romcc, that means, a regression with C environment bootblock.
I've recompiled a few more times. Therefore I was able to upload two more clean board statuses, one with serial enabled and one without as you asked.
Thank you. Though I only see one more upload after the one I referred to.
$ git log --oneline -2 asus/p2b-ls dde01d781 asus/p2b-ls/4.11-839-g11c5b3b180/2020-01-10T21_51_08Z 5550a954e asus/p2b-ls/4.11-711-gd913036e18/2020-01-05T00_12_56ZWithout serial (`CONFIG_CONSOLE_SERIAL is not set`) has a total time of 2.9 seconds compared to 5.7 before.
Without considering the 2.5s in romstage mentioned below, the remaining 400 ms for the other stages is not bad.
Unfortunately without serial it still takes 2.5s in the romstage, and I can visually see the serial output going much slower than in ramstage. We should check the serial enabling code in romstage or even bootblock.
Is that a regression compared to romcc bootblock?
That might happen if there's no ROM caching. I saw something similar on gm45 until it was addressed. However, I am not sure if caching is doable on such old hardware.
Interesting. Could you please provide the commit or code in question?
Also PS/2 keyboard init and sometimes video init is still finicky.
Ditto. Regression or not?
There are times when keyboard does not respond before the linux kernel is completely done,
Maybe that can be debugged in SeaBIOS, which you use as payload. Please increase the debug level for SeaBIOS, and post the logs from the working and non-working cases. (Please start a separate mailing list thread for that.)
Note that coreboot should not do PS/2 keyboard init when SeaBIOS is used, as SeaBIOS already does its own keyboard init.
Indeed. In the recent upload it’s not set though.
# CONFIG_DRIVERS_PS2_KEYBOARD is not set
and that could also be preventing my SCSI BIOS (extracted as is from factory image) from running through as it watches for a key combo to enter its setup interface.
Did that work with romcc. Please paste verbose SeaBIOS logs.
What is the commit that I should branch off of to get my romcc romstage back?
I assume it is the parent of commit 1fa240a3 (cpu/intel/slot_1: Move to C_ENVIRONMENT_BOOTBLOCK) [1], so commit df0c731e (mb/Kconfig: Add a warning on boards with a ROMCC_BOOTLOCK). Please test df0c731e, and upload the logs to the board status repository too.
Kind regards,
Paul
-
Angel Pons -
Paul Menzel