rappet has quit [Read error: Connection reset by peer]
rappet has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 250 seconds]
_whitelogger has joined #glasgow
mwk has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Remote host closed the connection]
Stormwind_mobile has joined #glasgow
m4ssi has joined #glasgow
mwk has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 268 seconds]
_whitelogger has joined #glasgow
JJJollyjim has quit [Quit: killed]
jschievink has quit [Quit: killed]
chocol4te has quit [Quit: killed]
fridtjof[m] has quit [Quit: killed]
cyrillu[m] has quit [Quit: killed]
kerel has quit [Quit: killed]
disasm[m] has quit [Quit: killed]
Stormwind_mobile has joined #glasgow
fridtjof[m] has joined #glasgow
chocol4te has joined #glasgow
JJJollyjim has joined #glasgow
jschievink has joined #glasgow
kerel has joined #glasgow
disasm[m] has joined #glasgow
cyrillu[m] has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 265 seconds]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 246 seconds]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #glasgow
d0nker5 has quit [Ping timeout: 250 seconds]
d0nker5 has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 246 seconds]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 245 seconds]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 265 seconds]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 250 seconds]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 252 seconds]
<hell__>
electronic_eel: it's an asrock Q1900M with a baytrail SoC. the flash descriptor says that the frequency is 33 MHz. Looks like it can do "Dual Output Fast Read Support", but that can be disabled
<hell__>
also I think the frequency can be lowered, and fast read can also be disabled
<whitequark>
unless it comes up in some weird mode, it should just use normal SPI
<whitequark>
oh hm
<whitequark>
yes, you'll have to disable dual/quad output
<whitequark>
fast reads are fine though
<whitequark>
and 33 MHz should be well within what glasgow can provide
<whitequark>
would be neat to be able to patch SFDP on the fly to edit out unsupported features, but that's kind of hard
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 246 seconds]
Stormwind_mobile has joined #glasgow
<Ultrasauce>
.oO(glasgow UEFI runtime service widget)
<whitequark>
n-no
<whitequark>
very cursed
Stormwind_mobile has quit [Ping timeout: 268 seconds]
Stormwind_mobile has joined #glasgow
<kc8apf>
Trammell's SpiSpy let's you upload a different SFDP
Stormwind_mobile has quit [Ping timeout: 240 seconds]
<whitequark>
right, i guess glasgow could easily substitute a custom SFDP
<kc8apf>
Patching the IFD is still a problem
<whitequark>
IFD?
m4ssi has quit [Remote host closed the connection]
<kc8apf>
revC isn't going to be fast enough to emulate SPI on modern systems well
<kc8apf>
Intel flash descriptor
<whitequark>
how fast is SPI on modern systems?
ExeciN has joined #glasgow
<kc8apf>
100+ MHz
<kc8apf>
There tends to be a lower bound as well where the system takes too long to load from flash and gives up
<kc8apf>
SpiSpy handles most of this by carefully issuing DRAM accesses before the full SPI command is received.
<whitequark>
oh, ouch
<davidc__>
Most of the interesting systems I've looked at completely ignore flash descriptors; and just quickly check the JEDEC ID against a few known values
<davidc__>
(and derive operating parameters from whatever that was)
<kc8apf>
SpiSpy approach is good. UXL3S has some annoyances for this use that Glasgow is better at (I/O voltage translation)
<kc8apf>
I haven't dug into the verilog far enough to judge the implementation
<hell__>
the IFD (Intel Firmware Descriptor) is kind of like a partition table for flash chips: it defines various regions which contain different things (the descriptor itself, the ME firmware, the BIOS, the in-the-chipset LAN controller parameters, and some more things depending on the platform)
Stormwind_mobile has joined #glasgow
<whitequark>
ah
<hell__>
it also has what Intel calls "soft straps": clock controller configurations, muxing of HSIO lanes (some pins can be either xHCI or PCIe, and others can be either PCIe or SATA), the permissions for each master on some regions (e.g: the descriptor is read-only and the ME region is neither readable nor writable for the Host CPU master), and other things
<hell__>
"other things" includes the parameters of the flash chips: size, count, the frequencies to use, whether to use fast read or dual/quad fast reads...
bvernoux has joined #glasgow
Stary has joined #glasgow
<electronic_eel>
hell__: does the chipset really honor what is in these IFD soft straps? like you set a freq of 20 MHz there and it really does 20 MHz, verified with scope or logic analyzer?
<electronic_eel>
in some other tech I've seen very fine grained descriptors in flash/eeprom, but in the end most of it is ignored and the values are hardcoded
random has joined #glasgow
<hell__>
electronic_eel: I didn't try, but people have successfully changed these to use a Dediprog EM100 SPI flash emulator
<electronic_eel>
ok, that looks promising
<electronic_eel>
do you know how low you can go with the frequency?
<hell__>
it depends on the specific platform, but it's usually about 20 MHz
<electronic_eel>
and what is the flash ic you want to use behind glasgow capable of?
<hell__>
at least that
<electronic_eel>
if it can just do 20 MHz then it would be too slow, as there would be no margin for glasgow
<whitequark>
fast read usually goes >50 MHz
<electronic_eel>
the chipset is the spi master and expects the flash to answer in sync to it's clock
<hell__>
well, the glasgow would just need to mux the SPI flashing applet and a passthrough between both IO banks
<whitequark>
in this setup the glasgow is just a glorified level shifter
<hell__>
^
<whitequark>
there is a good question of what the routing delay will be
<electronic_eel>
whitequark: is it possible to directly connect the inputs and outputs of the fpga, without clocking in the inputs first?
<whitequark>
sure. most applets currently don't even use registered inputs
<whitequark>
i think the routing+io delay should be a few ns at most, but i don't know for sure
<hell__>
so, if I understand properly: the glorified level shifter can be on its own clock domain and run async with the fpga's clock?
<whitequark>
it doesn't need a clock domain
<whitequark>
you just do o.eq(i)
<whitequark>
you don't need *any* clock in an fpga
<whitequark>
it's just not very useful without a clock
<electronic_eel>
so clocking in would just be necessary if you wanted to parse the protocol and change direction dynamically for qspi
<hell__>
^ that is what I understood
<whitequark>
yes
<hell__>
but I don't need to do that, *i hope*
<whitequark>
we have 25 ns of slack per direction
<whitequark>
at 20 MHz
<whitequark>
assuming setup and sample edges are the same
<electronic_eel>
the level shifters eat about 8ns each
<whitequark>
hm
<whitequark>
that... probably won't work then
<whitequark>
i don't think the fpga is going to be faster than 9 ns
<whitequark>
much faster, at least.
<whitequark>
daveshah might know how fast the IOBs and routing are?
<daveshah>
no but 9ns seems optimistic
<daveshah>
nextpnr prints max async-async delay (currently excluding IOB) as a starting point though
<hell__>
ouch
<daveshah>
if anyone wants to try
<electronic_eel>
sorry, I was wrong in the shifter datasheet table: about 2 to 7ns for 1V8 to 3V3 and reverse
<whitequark>
interesting
pie_ has quit [Ping timeout: 265 seconds]
<whitequark>
that gets higher with temperature, right? if i remember how mosfets work correctly
<hell__>
i think so
<hell__>
maybe I should put this in the fridge then?
<whitequark>
for a moment i thought this was a metaphor
<whitequark>
no, i meant that datasheets tend to include worst case timings, like at 85°C
<whitequark>
the ice40 timings for example are extremely conservative
<hell__>
it's like capacitor lifespan
<electronic_eel>
the (nexperia) datasheet has two tables, one -40 to +85 and a second with -40 to +125. the -40 to +125 table has slower transfers
<hell__>
just realized, forgot to mention that the hardware I have is a revB
<whitequark>
it's worth measuring the phase shift with a scope in practice
<daveshah>
it recently emerged, from an icebreaker assembly mistake, that ice40s can at least vaguely function with 3.3V (rather than 1.2V) Vcore, albeit getting rather hot in the process
<whitequark>
oh
<whitequark>
forget about it with revB i think
<whitequark>
i mean... you could try but
<whitequark>
i lost my faith in the ability of FXMAs to do anything right
<whitequark>
i'm reasonably sure i was getting random rare bitflips in SPI streams with them
<whitequark>
also, UP5K is slow as fuck
<hell__>
the FXMAs are the level shifters of revB, aren't they?
<whitequark>
i was assuming HX8K
<whitequark>
yes
<electronic_eel>
hell__: so all in all I'm not sure if you aren't better off using some '45s for level shifting and for example a '244 for tristating
<hell__>
probably :S
<electronic_eel>
connect the glasgow up to the '244, so you can flash new data in on command, but then take out the glasgow when the board boots from the flash
<hell__>
it will definitely cost less than a flash emulator
<electronic_eel>
if the timing is a bit too tight and you get like one bit flip in 1000 MBits you won't have won much, as your tests don't give proper results then
<hell__>
oh, this is far from critical
<electronic_eel>
what kind of tests are you planning to do with the bios?
<hell__>
basically, porting coreboot to this thing
<electronic_eel>
ah, nice
<hell__>
and then, reimplementing memory initialization
<electronic_eel>
I have some baytrail mini-itx boards at hand, not asrock but mitac. would be nice to get them to work with coreboot too
Stormwind_mobile has quit [Ping timeout: 240 seconds]
<hell__>
platform support exists, the most annoying thing is that binaries are required
<electronic_eel>
is memory init usually done by some intel blob or why is it a special thing?
Stormwind_mobile has joined #glasgow
pie_ has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 265 seconds]
Stormwind_mobile has joined #glasgow
<hell__>
it's usually done by blobs on intel hardware
<hell__>
there's about half a dozen intel platforms with an open source raminit, though. these were either implemented with proper documentation, or reversed
<electronic_eel>
does intel provide documentation on this level?
<hl>
no
<electronic_eel>
on the i.mx8 socs from nxp most of the stuff is well documented, but ram init is not. you need a blob for it
<hl>
yeah, would need to be reversed
<hl>
and if you want HDMI out you need a NXP-signed blob
<electronic_eel>
oh, all of hdmi? or just the hdcp stuff? never looked at graphics stuff for embedded...