lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
ohama has quit [Disconnected by services]
ohama has joined #m-labs
nicksydney has quit [Remote host closed the connection]
stekern has quit [Read error: Connection reset by peer]
stekern has joined #m-labs
sb0 has joined #m-labs
<ysionneau>
mwalle: in NetBSD generic tlb code, ASID 0 is only for kernel, so he is proposing that a tlb entry which ASID is 0 would always match if we are in kernel mode (PSW.USR == 0)
<ysionneau>
then you can directly change the ASID while still being executing a bit of kernel code
<ysionneau>
then I am just wondering how to handle tlb misses for kernel pages when the asid is switched and the page table is switched as well ...
nicksydney has joined #m-labs
Alain_ has joined #m-labs
zeiris_ has quit [Ping timeout: 240 seconds]
zeiris has joined #m-labs
<ysionneau>
sb0: wow, seems like a big piece of work
<ysionneau>
(github link)
<sb0>
yeah, his blog is quite interesting too
<ysionneau>
oh and the kickstarter project is not bad also
<sb0>
port to altera board using the new build system
sb0 has quit [Ping timeout: 245 seconds]
sb0 has joined #m-labs
<ysionneau>
nice, the port is pretty small with this new build system
Alain_ has quit [Remote host closed the connection]
<mwalle>
ysionneau: i see, so if USR=0 and ITLB=1 then ASID is always 0, regardless whats written to the ASID field
<mwalle>
but USR=1 ITLB=1 and ASID=0 is also valid, right?
<mwalle>
eg that would be user space program running with asid 0
<mwalle>
(of course not in netbsd but maybe some standalone stuff
<ysionneau>
16:12 < mwalle> ysionneau: i see, so if USR=0 and ITLB=1 then ASID is always 0, regardless whats written to the ASID field < we could see it that way, but I was more seeing it like "even if asid is not 0, tlb entries with asid 0 match anyway, if USR==0 and *TLB==1"
<ysionneau>
so that would mean that if for instance current ASID is 1
<ysionneau>
tlb entries with asid 1 would match as well
<ysionneau>
16:14 < mwalle> but USR=1 ITLB=1 and ASID=0 is also valid, right? < it's valid, but NetBSD will not do it, but yes I think it should stay valid
<ysionneau>
mwalle: about qemu, when you are in the
<ysionneau>
translate.c (for instance dec_b)
<ysionneau>
you cannot do "flush_tlb()" directly, right?
<ysionneau>
you need to generate code that flush the tlb
<ysionneau>
and then you need to wrap it inside an helper, right?
<ysionneau>
I guess that's why you used gen_helper_wcsr_psw () inside the dec_wcsr() in translate.c
<mwalle>
(two asid matches) mhh, is this a good idea?
<ysionneau>
honestly, I don't know
<ysionneau>
but it just seems natural, at first, that when current asid is "1" then it is matched in tlb
<ysionneau>
and it seems that it would simplify copyout code as Matt said
<ysionneau>
copyout is just copyout(void *uaddr, void *kaddr, size_t len)
<ysionneau>
you copy from kernel address space to user address space
<ysionneau>
mwalle: I guess it's not an issue as long as user and kernel spaces are disjoints
<ysionneau>
like [0->MAX_USER] ; [MIN_KERNEL ; 0xffff.ffff]
<ysionneau>
like linux 3G/1G
<mwalle>
and if they are not?
<mwalle>
eg. the worst case :)
<mwalle>
translate.c: this is only executed on code translation
<mwalle>
eg in the best case only once
<mwalle>
so if you do a flush_tlb() there this will only be executed during translation time
<ysionneau>
ok so that's not what I wanted to do :p
<mwalle>
translation time: the time when the binary is translated to intermediate operation which will then be executed on the host
<ysionneau>
for instance if we switch ASID upon eret, we want to flush tlb upon eret
<ysionneau>
but not during "translation" of an eret
<ysionneau>
so I was right about needing to wrap the tlb_flush inside an "helper" ?
<mwalle>
do we want this to be implicit on eret/bret or may it also be explicitly done with wcsr?
<ysionneau>
what do you mean?
<mwalle>
mhh, flush_tlb() means actually flush the tlb on the (actual) hardware, right?
<mwalle>
erm
<mwalle>
actual=emulated
<ysionneau>
no, flushing the qemu tlb
<mwalle>
ah
<ysionneau>
in hw no need to flush tlb when switching asid, it's the all purpose of asid
<mwalle>
sorry, then, forgot what i was saying ;)
<ysionneau>
ok :)
<ysionneau>
sorry I must have badly explained
<mwalle>
nah i have to refresh my qemu wisdom, i guess ;)
<ysionneau>
ah, it's tlb_flush(env, 1), not flush_tlb
<ysionneau>
maybe that will ring a bell :p
<mwalle>
nah :b
<ysionneau>
ok, it was just to make sure what I understood was OK
<ysionneau>
but after what you described about the translation process I think it's ok :)
<ysionneau>
thanks for the details
<ysionneau>
16:54 < mwalle> and if they are not? < if they are not, then ... the user space mapping can be used instead of the kernel one :x
<ysionneau>
and it can start to get messy
<ysionneau>
I have the feeling that all of this would be much less trouble prone if we would just add a "global" bit in tlb entries
<ysionneau>
and not tread ASID 0 in any special manner
<ysionneau>
so that if you know that your user space/kernel space are disjoints, you can always put Global bit to kernel tlb entries
<ysionneau>
and then ... maybe indeed switch only asid upon eret with the usual latching (BASID, EASID)
<ysionneau>
well, switching asid upon eret would be enough to solve our problem in fact
<ysionneau>
that would mean that the kernel will need to map user space pages to his own address space upon copyin / copyout but that's not so big an issue
<mwalle>
btw the index to the CAM is still the lower address bits, right?
<ysionneau>
we don't use CAM but yes it's the lowest address bits which is not in the page offset part
<mwalle>
well isnt your block ram sth like a CAM? :)
<mwalle>
yes it is not really a cam
<ysionneau>
well I guess we can say it's a very special case of CAM
<ysionneau>
where it's index addressed
<ysionneau>
nevermind
<mwalle>
but the global bit would have the same "there might be multiple matches" problem, right?
<mwalle>
only that the user is in control of it
<ysionneau>
yes, but in this case, the user controls it
<mwalle>
which is fine
<ysionneau>
so the user knows what he is doing
<mwalle>
yeah
<ysionneau>
I would prefer ASID0 to stay generic enough
<ysionneau>
not to bind the MMU to some OS
<mwalle>
me too
<mwalle>
but instead of using a global bit for each entry
<mwalle>
we could use just one
<mwalle>
which says ASID0 is 'global'
<ysionneau>
good idea :)
<ysionneau>
a 5 bit register somewhere, where you can put the ID of the global asid
<ysionneau>
then we take for granted we only want one ASID to be global
<ysionneau>
and that we don't have global entries among several asids
<mwalle>
or just pin it to ASID0
<mwalle>
or do that need to change at runtime
<mwalle>
?
<ysionneau>
I don't know where to put the threshold between genericity and hardware optimization choices :p
<ysionneau>
for NetBSD , just having ASID0 global is fine
<ysionneau>
but we could imagine some other application having different needs
<ysionneau>
dunno
<ysionneau>
but I like the idea of saving RAM
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #m-labs
<ysionneau>
on another hand, by using "ASID0 global or not controlled by one bit" the code would be like
<ysionneau>
if ( ( current_asid == tlbe[ASID] ) OR ( tlbe[ASID] == 5'b0 and asid0_global ) )
<ysionneau>
by using just a global bit it becomes
<ysionneau>
if ( ( current_asid == tlbe[ASID] ) OR ( tlbe[g] ) )
<ysionneau>
so there is one less5-bits comparator in the path
<ysionneau>
don't know if it is important or not
<mwalle>
well actually, asid0 is global and one asid bit for every entry is the same, isnt it?
<mwalle>
because if the global bit is set, the asid doesnt matter anymore
<mwalle>
so you could say, your asid range is 1..0x1f and asid = 0 is global bit
<mwalle>
so having and unconditional asid0 seem equal to have global bits to me
<mwalle>
if you agree, i'd prefer the unconditional asid0 maching
<mwalle>
matching
<mwalle>
bbl
<ysionneau>
so, asid0 would be reserved for global mappings?
<ysionneau>
only if PSW.USR == 0
FabM has quit [Quit: ChatZilla 0.9.90.1 [Iceweasel 24.4.0/20140319080549]]
<GitHub161>
[misoc] sbourdeauducq pushed 2 new commits to master: http://git.io/LGppdA
<GitHub161>
misoc/master 2fca8d4 Florent Kermarrec: programmer: add USBBlaster and use platform.bitstream_ext in make
<GitHub176>
[misoc] sbourdeauducq pushed 2 new commits to master: http://git.io/kLGmlA
<GitHub176>
misoc/master 41c35e7 Florent Kermarrec: simple: create PowerOnRst and use it (remove vendor-dependent code)
<GitHub176>
misoc/master 1adceb8 Florent Kermarrec: sdramphy: move and clean up s6ddrphy, add generic SDRAM PHY
<GitHub102>
[migen] sbourdeauducq pushed 2 new commits to master: http://git.io/EbVdjA
<GitHub102>
migen/master 8c03cb0 Florent Kermarrec: mibuild: force shell script generation to unix format (will be executed with cygwin's bash on windows)
<GitHub102>
migen/master d1a96bc Florent Kermarrec: mibuild/altera_quartus: enforce use of SystemVerilog in Quartus (Verilog does not support global parameters)
mumptai has joined #m-labs
<rjo>
sb0, florent: nice work! would the sdram phy work with the sdram on the papilio pro?
<sb0>
rjo, yes, it should
<sb0>
haven't tested it yet, but it should be fine
<sb0>
but one patch is missing - the WB/LASMI bridge won't handle the 16-bit LASMI bus
<sb0>
there are a few things to clean up before I commit it
<sb0>
also, the PPro SDRAM could use IDDR/ODDR and run at 2x the system clock rate :) but of course, it's a bit harder than just reuse that PHY
<rjo>
sb0: i see. thanks.
<rjo>
sb0: did i understand that correctly: you are working on the wb/lasmi bridge currently thus pushing to papilio pro to complete support?
<sb0>
Florent did most of the wb/lasmi bridge work, but yes
<rjo>
by the way. i have tried to get higher uart speeds to work but failed so far. anyone have success with that? i know the rates come out slightly off (more than the few percent that are usually ok).
<rjo>
sb0, Florent: excellent.
<sb0>
got it to work at 230400bps, failed at higher speeds, and I didn't insist
<rjo>
sb0: yes. but in that case one could just have the dcm generate the fastest sensible uart clock (brobably 16MHz) and then divide jitter-free down from that.
<rjo>
sb0: i also tried to use the custom baud rate stuff to match the actual rate but that did not work either. ftdi broken or custom baud rate bugs.
<sb0>
yeah, but this needs several clocks (and the associated ISE bugs and other mishaps), and an asynchronous design
<rjo>
custom baud rte stuff in flterm, that is.
<sb0>
jitter at the ~80MHz system clock rate should actually be rather small compared to a transmission rate of a few Mbps at most
<rjo>
sb0: but the DDS-style solution from that web link also needs those, doesn't it?
<rjo>
sb0: oh. you want to use sys_clk
<sb0>
yes
<rjo>
then not.
<rjo>
sb0: max jitter will be one sys_clk period. not much, yes.
<rjo>
sb0: and it doesn't really matter for a UART anyway AFAICT