Re: [coreboot] Offtopic - tapping TxFP packages with flat cables?

[Peter Stuge]

Andrey Korolyov wrote:
> tap 0.5mm pitched packages - how it could be done

Buy another chip, make a breakout board, remove onboard chip, connect
probes to breakout board, connect breakout board to mainboard.
> i945, so initial porting has been done with very small effort, but

..
> raminit run after first poweron fails
> (device turns off within a half of second):
>
> PM1_CNT: 00001c00
> SMBus controller enabled.
> Setting up RAM controller.
> This mainboard supports Dual Channel Operation.
> DDR II Channel 0 Socket 0: x8DS
> DDR II Channel 0 Socket 1: N/A
> DDR II Channel 1 Socket 0: x8DS
> DDR II Channel 1 Socket 1: N/A
> SLP S4# Assertion Width Violation.
> Reset required.
>
> when second power-on goes just well

This is documented behavior of the chipset.

"SLP S4# Assertion Width Violation" is the hardware telling the
firmware (you) that the hardware has not been in S4# long enough,
and simply isn't ready just yet.

Chipset docs specify how long firmware should wait, before it can try
to power the platform up again.

coreboot on the X60 (also i945) does this on cold boot, leading to a
second or so delay after power button until coreboot fully starts.

You could also delay much shorter, effectively busy-waiting on the
bit, but with full power cycles.

//Peter

Offtopic - tapping TxFP packages with flat cables?

[Andrey Korolyov]

> Buy another chip, make a breakout board, remove onboard chip, connect
> probes to breakout board, connect breakout board to mainboard.

Thanks, but this is a pretty time-consuming method if I need to tap
four consecutive legs out of one hundred. Also BBs adding extra
crosstalk which could lead to erroneous behavior even for tens of
megahertz when scheme is coupled with high-impedance logic analyzer.
> This is documented behavior of the chipset.
>
> "SLP S4# Assertion Width Violation" is the hardware telling the
> firmware (you) that the hardware has not been in S4# long enough,
> and simply isn't ready just yet.
>
> Chipset docs specify how long firmware should wait, before it can try
> to power the platform up again.

Awesome, thank you, I never had a single thought that this could be a
documented behavior - EEPROM read stage takes a plenty of time
(something around sixty milliseconds) and I`ve automatically threw all
time-related chipset initialization stuff out of scope.