<gruetzkopf>
will be using arc debug, 25 series spi flash and uart again soonish
<whitequark>
:D
<whitequark>
thinkpad hax?
<gruetzkopf>
dell, but close
<whitequark>
ah
<gruetzkopf>
even revB not liking pulls is not a problem, as we previously moved the spi flash to it's own board for easy access
<whitequark>
yea, i actually never really got in-circuit spi flash programming to work
<whitequark>
i tried it on a ton of boards
<whitequark>
destroyed the contents on one of them, no effect on all others
<whitequark>
it would work if the controller tristates the bus...
<whitequark>
but not otherwise
<gruetzkopf>
i really need to buy a bunch of soic8 sockets
<whitequark>
yea there's cheap ones on ebay
<tnt>
yeah, I always wondered how thos people that just put a clip over the soic did it ... I never tried myself, but it always looked weird to me to just override the bus. Or do it while the machine is off but then you'r injecting power into the 3v3 rail ...
<tnt>
esden: yeah, that's what reminded me of it, but I didn't know if you unsoldered it or did it ISP.
<esden>
The biggest problem here was that if you connect 3v3 to the eeprom you will fry the CPU of the laptop. I think they removed the battery too.
<esden>
that is why they used SF600 that can set the voltage to 1v8
<esden>
we were considering desoldering the chips. But it was not necessary.
<esden>
I did think that glasgow would be a great tool for this too. But I did not know if the necessary code was already there. :)
<whitequark>
glasgow certainly has 25x flash coe.
<whitequark>
i have used it successfully many imes.
<whitequark>
on the BIOS flashes which have SFDP it is basically turnkey
<whitequark>
do not even need the datasheet
<whitequark>
it was one of the first things i added i think.
<whitequark>
wait. it uses emc?
<whitequark>
*emmc?
<esden>
sweet! Will need to snatch one of Joe's laptops and try it out. I am sure he will not mind it. :)
<whitequark>
heheh
<esden>
No I think it is just old serial flash...
<esden>
Will have to ask Maggie what it ended up being.
<tnt>
the sf600 only does spi afaik
<esden>
I think what will be very useful down the road is to have glasgow hats with different chip sockets like the sf600 has.
<esden>
I know I know... "piotr focus, first make some glasgows ..."
<esden>
anyways, back to the grinding wheel... need to make more icebreakers, also ran out of black magic probe stock so I need to change over and make a bunch of those too. Thanks Joe Grand... >_< :D
<whitequark>
esden: yes. i have plans for those hats.
<whitequark>
for now i bought some SOIC clips and wired them with an IDC cable.
<whitequark>
that's actually pretty easy and convenient.
<gruetzkopf>
when are you ever not making icebreakers
<esden>
still ~300 rewards to fullfill so yeah ...
<esden>
but getting close 4 maybe 5 full assembly days and I should have enough to cover the campaign rewards...
<esden>
then I need to assemble the led panel driver and HDMI pmods...
<esden>
then I can get to assembling some for inventory and other pre orders... so yeah still a lot of assembly in front of me :)
<esden>
But somewhere in there I want to assemble the remaining glasgow boards I have sitting here.
<jn__>
*looks at x25xx octal mode* SPI: Special Parallel Interface
<gruetzkopf>
a "fun" / useful thing to have would be lpc port 0x80 -> host and lpc_16550<->host comms (though i suspect that's best done after native multi-applet works?)
<whitequark>
gruetzkopf: no
<whitequark>
it's blocked on nmigen
<whitequark>
because async applets don't actually work on omigen
<whitequark>
not if the target clock can stop
<gruetzkopf>
ooh
<hellsenberg>
gruetzkopf: i agree, those would be nice to have.
<whitequark>
i haven't thought about lpc+16550 before actually
<whitequark>
but yes. that'd certainly work.
<whitequark>
i mean just ignore all but the data register
<gruetzkopf>
yep
<hellsenberg>
gruetzkopf: i guess lpc+16550 is "for coreboot purposes" ?
<gruetzkopf>
for baremetal work on modern x86_64 platform, yeah
<hellsenberg>
i see what you did there
<whitequark>
i can absolutely implement that
<whitequark>
i have like half of it already
<gruetzkopf>
i mean port80 is even simpler
<whitequark>
port69
<gruetzkopf>
no host->dev transfers
<whitequark>
oh that's not really the issue
<whitequark>
the lpc timings are kinda annoying
<whitequark>
like in general
<gruetzkopf>
but co-running that with the "normal" uart applet would be really helpful
<whitequark>
multi-applet with 2 applets is actually super easy
<hellsenberg>
if lpc+16550 looks like a SuperIO to the LPC host, it would be easier to support with coreboot code (just pretend it's a superio)
<whitequark>
the only missing part is the UI
<gruetzkopf>
i mean many laptops i've looked at recently pull LPC and uart onto one miniPCIe port (same pinout across dell and lenovo even)
<hellsenberg>
uart on mPCIe?
<hellsenberg>
ah, the EC debug one
<whitequark>
yep seen those
<whitequark>
i have a cursed board with lpc someone sent me
<whitequark>
with destroyed bios
<whitequark>
i will boot it off glasgow i think
<whitequark>
at least if like
<whitequark>
the lpc master will not abort transactions that wait for too long
<whitequark>
i doubt it will
<hellsenberg>
unlike SPI, which requires strict timings
<gruetzkopf>
hellsenberg: the ec-included uart can be mapped to host
<whitequark>
wait what
<hellsenberg>
whitequark: oh, lpc boot would also be good for coreboot debugging purposes: on boards which boot off SPI, leave the vendor firmware there, switch BIOS boot location via hardware straps and use a glasgow to boot-test coreboot builds over LPC
<whitequark>
where's LRST#
<whitequark>
hellsenberg: oh cool
<whitequark>
where's LCLK as well
<jn__>
hellsenberg: yeah, LPC flash emu + port80 + uart seems like the ultimate coreboot dev combo
<gruetzkopf>
PCLK_80H
<hellsenberg>
I currently do this the other way around (vendor over LPC, coreboot over SPI) on a shitty Toshiba laptop
<hellsenberg>
the first laptop ever with a GM45-series northbridge and DDR2 to boot Linux with coreboot
<gruetzkopf>
PCH_PLTRST#_EC is LRST#
<jn__>
hellsenberg: oh cool, that's relevant for Dell E6400
<gruetzkopf>
just hunted it down
<whitequark>
ah
<gruetzkopf>
jn__: yes which is why i dug it out
<jn__>
(i mean the gm45 + ddr2 part)
<hellsenberg>
jn__: I have one of these too; also a Dell E5500