<sb0>
cr1901_modern: why does xpra attempt to create a virtual console, with screen flickering and all?
<sb0>
anyway, works much better than X. thanks!
sb0 has quit [Quit: Leaving]
_whitelogger has joined #m-labs
proteusguy has quit [Ping timeout: 245 seconds]
proteusguy has joined #m-labs
<cr1901_modern>
lkcl: Hmmm, interesting strategy re: debootstrap. And yes, xpra does cope w/ session disconnect.
<cr1901_modern>
sb0/sb10q: Idk anything about screen flickering, but if you used the quickstart I gave you, the reason xpra created a virtual console is because I used a command line switch to tie the lifetime of the xpra session to xterm
<cr1901_modern>
you don't have to do that, it's just my personal preference to stop the server once children have exited
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 259 seconds]
proteusguy has quit [Remote host closed the connection]
proteusguy has joined #m-labs
<lkcl>
cr1901_modern: the bind-mount to specific subdirectories is to avoid the scenario of forgetting that the bind-mount is there, and accidentally doing "rm -fr /opt/chroot/debian-devenv1"... ya see where that goes... :)
<lkcl>
whitequark: yay, that covers some of the use-cases that we have. unfortunately it doesn't cover all of them.
<whitequark>
such as?
<lkcl>
i'll have to track it down, from the runtime error
<lkcl>
File "/home/lkcl/src/riscv/nmigen/nmigen/back/rtlil.py", line 566, in _prepare_value_for_Slice
<lkcl>
"value must be Signal, Slice or Cat, was: %s" % repr(value)
<lkcl>
just to see what was going on
<whitequark>
oh sorry i can't read
<lkcl>
i didn't send it, so there wasn't anything to read :)
<lkcl>
btw great to see Record.connect added, that means minerva works without needing patches
<whitequark>
not added yet
<whitequark>
anyway
<whitequark>
can you make a minimal repro for that bug?
<cr1901_modern>
lkcl: Like most ppl on this planet, I'm accidentally nuked /usr before w/ root privs. I'd like to think I'm more careful now (if rm were smarter it would warn for both "/" and "/usr"
<whitequark>
there should be just an xattr that indicates "you prob don't want to rm this"
<whitequark>
hilariously, windows has it, it's called the system attribute
<cr1901_modern>
Think that goes back to the FAT12 days tbh :D
<cr1901_modern>
system/ro/archive/hidden
<whitequark>
yes but dos didn't warn on del system iirc
<lkcl>
whitequark: i can give it a shot
<cr1901_modern>
Can't remember offhand if DEL will remove system attr, tbh. AIUI, IO.SYS and IBMBIO.COM had to actually be on certain sectors of track 0 (CHS emulation) of a hard disk to properly work, and system was an attribute to say "if you even move this file, bad things will happen"
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
<lkcl>
whitequark: the alternative is to have a recursive array of SyncFIFOs
<lkcl>
i got it (untested):
<lkcl>
Record.__iter__:
<lkcl>
yield Cat(*self.fields.values())
<whitequark>
no.
<whitequark>
that's an XY problem again.
<lkcl>
let me take a look at the resultant output from the mods to rtlil
<lkcl>
ok so assigning to a Cat(*flatten(r)) results in the god-awful mess
<lkcl>
assigning *from* a Cat(*flatten(r)) is ok
<lkcl>
however they're both functional.
<whitequark>
you could also remove the Cat(*flatten(...)) and get the exact same behavior.
<lkcl>
we can't.
<lkcl>
it would require a recursive tree-walk of the Record data structure, allocating MULTIPLE SyncFIFOs as a substutite
<lkcl>
one each per record field
<lkcl>
then creating a massive combinatorial block linking up all of the resultant writable/we+readable/re signals
<whitequark>
please learn what an XY problem is.
<lkcl>
Questions of this form often indicate a person who is not merely ignorant about X, but confused about what problem Y they are solving and too fixated on the details of their particular situation.
<lkcl>
i am neither ignorant of X nor confused about Y
<whitequark>
exactly
<whitequark>
if you want to demonstrate that, produce a minimal example where Cat(*flatten(r)) cannot be replaced with r.
<whitequark>
i am very much not interested in what you think is the solution, which is always a hacky workaround. nmigen is not your personal collection of hacks
<lkcl>
that's tricky as it involves SyncFIFO
<lkcl>
gently, whitequark.
<lkcl>
we're using a recursive Records-based data structure on the front and back of SyncFIFO
<lkcl>
that's basically the use-case
<lkcl>
as a general-purpose API rather than a one-off
mauz555 has joined #m-labs
<whitequark>
sure. that's reasonable. i don't see any reason that requires Cat(flatten())
<lkcl>
if it was a one-off, then creating a god-awful morass of multiple SyncFIFOs...
<lkcl>
it's to get the data structure flattened down into a single din
<lkcl>
and de-flattened on the output dout
<whitequark>
fifo.din.eq(r).
<whitequark>
that's it.
<lkcl>
last time we tried that, it failed.
<whitequark>
then that is the bug, and you should report that
<whitequark>
instead of speculating on what the fix is
<lkcl>
plus... although i said it's Records-based, it's a general API where Records are just one of the data structures.
<lkcl>
i'll experiment further now that the Slice fix is in
<lkcl>
leave it with me
<whitequark>
in the future, please report the actual bug you encounter.
<whitequark>
this would waste significantly less time.
mauz555 has quit [Ping timeout: 252 seconds]
<lkcl>
apologies: i'm used to flowing round problems very very rapidly
<lkcl>
setting e.g. extras=() creates a SINGLETON pattern!
<lkcl>
the parameter extras becomes a unique by-ref variable
<lkcl>
that, if modified (in the __init__ or elsewhere)
<lkcl>
gets propagated as the default in ALL OTHER PLACES IT'S USED!
<whitequark>
lkcl: you can't modify a tuple.
<whitequark>
if it was extras=[] it would be a bug
<lkcl>
hmm... yes, usually i've seen it with [] and {}
<whitequark>
well, not really since extras is not captured.
<whitequark>
but yes. code review is for catching this thing too. i considered it.
<whitequark>
i asked jf to redo an earlier version because it had mutation similar to this.
<whitequark>
(not related to default args)
<lkcl>
now that i think about it, i've never used sometuple=()
<lkcl>
whew, ok so you're aware of the details. whew :)
<lkcl>
i'll go back to coding... :)
Gurty has joined #m-labs
Gurty has joined #m-labs
Gurty has quit [Changing host]
futarisIRCcloud has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> any thoughts about a better CSR system for nMigen/HeavyX?
<whitequark>
on gateware side or software side?
<key2>
features ?
<key2>
such as the ability to force address
<key2>
the ability to detect a read on the reg ?
<whitequark>
read triggered regs feel wrong
<whitequark>
they do not play well with HLLs...
<key2>
I know
<whitequark>
maybe it's good that we don't have them then
<key2>
but if you want to implement a UART 16550 for example
<key2>
how would you do it without ?
<key2>
am not saying it's a good practice.
<whitequark>
hmmm if you intend to mimic existing peripherals then it is necessary.
<key2>
yeah thats my point
<whitequark>
but maybe csr is the wrong abstraction for that?
<key2>
you have let say a qemu already there
<key2>
and don't want to spent hours re-writing core/driver
<key2>
mmh ok then
<whitequark>
i'm not sure
<whitequark>
it might make sense
<key2>
but I never had the case without that
<key2>
other thing is, some cores i find in stm32 for example would be nice to be re-implemented, and they do use this clear on read
<whitequark>
really? i thought stm32 only uses r_c1
<whitequark>
other micros do clear on read
<whitequark>
but i've never seen it in stm32, link?
<key2>
ah on some stm32f4 core i remember i had smth like that
<whitequark>
oh maybe they do this when they include foreign ip
<key2>
but hey, they can buy cores anywhere
<key2>
yeah
<key2>
that is my point
<whitequark>
i think all their cores only do r_c1
<whitequark>
well
<key2>
and they do include foreing ip
<whitequark>
maybe csr is the right place for that
<whitequark>
it is not very intrusive
<key2>
anyway
<whitequark>
to have trigger on read
<key2>
with or without, we can always trick it
<key2>
by checking on the wishbone but..
<whitequark>
if people do that we need to provide some abstraction
<whitequark>
maybe csr, maybe not
<key2>
stm32 are now on octo-spi
<key2>
while their quad spi core had already a lot of bug
<key2>
when doing DDR
<key2>
but we implemented a wishbone slave on quad-spi so we can access the wishbone this way
<whitequark>
wtf is octo-spi
<key2>
but they have a memmapped version
<key2>
but it can not write :/
<key2>
just read
<whitequark>
is that 8 line spi/
<whitequark>
?
<key2>
so am curious to see if in their octo-spi tehy will write
<mtrbot-ml>
[mattermost] <sb10q> both hardware and software side. but hw for now
<key2>
yeah
<whitequark>
that's just a parallel interfac.
<key2>
yeah but alla spi
<key2>
also quad spi had already a memory orientation
<key2>
meaning it was meant to read mem only
<key2>
not like any spi
<key2>
they did that for the hyperram/flash protocol
<key2>
which is cool
<key2>
but their octospi is only on stm32l version
<key2>
which suck
<key2>
i'm waiting to see if next stm32H7/F7 do have it too
<key2>
cuz it would do interesting setup with full read/write access mem mapped from octospi to wishbone
<key2>
letting transparently the AHB of the stm access the wishbone
<whitequark>
hmm curious
<key2>
and it's clocked at AHB rate (even tho AHB is 32 or 64 bit)
<whitequark>
sb: what problems with CSR do you want to fix on hw side?
<mtrbot-ml>
[mattermost] <sb10q> the main issue I have with the current system is atomicity of reads for CSRs that are larger than the bus word
<mtrbot-ml>
[mattermost] <sb10q> but I wonder what others' perspectives are
<whitequark>
I agree that atomicity is an important issue
<whitequark>
I haven't really used CSR outside of ARTIQ so I don't have an in-depth perspective on it
<whitequark>
it's a fairly simple system that does its job
<whitequark>
the software generator I do not like very much, I think it should export some structured format (JSON?) and then languages would have tools or macros to convert that to actual registers
<lkcl>
whitequark, key2: there was exactly this discussion on the risc-v hw-dev mailing list, about 10 days ago (interrupts generated on read of IO mem)
hartytp has joined #m-labs
<lkcl>
it was pointed out that not everyone will want to do that (as it is quite complex to implement)
<hartytp>
if you do go for a JSON or something route, would it make sense to add some meta data?
<lkcl>
however, conversely, *not* implementing interrupts-generated-by-read makes for fantastically complex firmware when it comes to memory-precious bootloaders for example
<hartytp>
e.g. to make it a little easier to follow where in the gateware the CSRs are, or what they're for?
<hartytp>
also, out of curiosity, how far do you think we are from being able to build misoc/artiq in nMigen?
<mtrbot-ml>
[mattermost] <sb10q> things that change on read sounds messy
<mtrbot-ml>
[mattermost] <sb10q> unless it's really necessary for performance... but you could use another interface than the csr generator then, I guess
<lkcl>
sb10q: it's standard practice for IO peripherals. from a software perspective, it's dead-simple: a FIFO responds with the incoming data on each read... therefore all you need do on the software-side to get at the data is: create a for-loop, reading from an address!
<lkcl>
bleumph. job done.
<lkcl>
dozens of peripherals, for decades, have been designed this way.
<lkcl>
the problem is: it's a bit of a bitch to implement in HW.
<mtrbot-ml>
[mattermost] <sb10q> you can also just add one write in that for loop to go to the next word.
<lkcl>
the risc-v spec covering this feature is sufficiently complex that some implementors are seriously, seriously considering avoiding it, and using DMA instead
<mtrbot-ml>
[mattermost] <sb10q> and it's not that simple anyway. what if the FIFO is empty?
<lkcl>
sb10q: yes, this was an alternative method that was suggested in the same discussion
<lkcl>
yes, typically a hardware MUTEX is needed (a 2nd read) that checks first if the readable-register is actually readable
<lkcl>
writing-to-move-the-register-forward was *suggested* (requested to be added to the spec)
<lkcl>
the request was ignored / denied.
<whitequark>
hartytp: re metadata: yes I agree, location tags would be excellent.
hartytp has quit [Ping timeout: 256 seconds]
<lkcl>
it is however a perfectly valid pattern
<lkcl>
in our design, we are considering going with a separate I/O co-processor, that does bit-banging of early-boot peripherals
<lkcl>
has a hardware mutex to the "main" processors
<lkcl>
and does direct memory-to-memory write (DMA in effect)
<lkcl>
effectively taking over the role *of* a DMA engine
<lkcl>
using the hardware mutexes as the DMA gateway
<lkcl>
it would save a lot of arseing about, and would not need read *or* write triggering of IO memory :)
<lkcl>
however... hum... clearly... it needs *two* processors. one to do the bit-banging of the peripheral GPIO bits, the other to be the "main processor"
<whitequark>
more processors means more bugs
<whitequark>
and usually the hard to find ones
_whitelogger has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has joined #m-labs
X-Scale` has joined #m-labs
X-Scale has quit [Ping timeout: 245 seconds]
X-Scale` is now known as X-Scale
rohitksingh has quit [Ping timeout: 255 seconds]
anuejn has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 268 seconds]
mauz555 has quit [Remote host closed the connection]