lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: EHSM Berlin Dec 28-30 http://ehsm.eu :: latest video http://www.youtube.com/playlist?list=PL181AAD8063FCC9DC
Jia` has joined #milkymist
xiangfu has joined #milkymist
methril has quit [Remote host closed the connection]
rejon has quit [Ping timeout: 244 seconds]
Jia` is now known as Jia
cladamw has joined #milkymist
mumptai has joined #milkymist
xiangfu has quit [Ping timeout: 248 seconds]
mumptai has quit [Ping timeout: 246 seconds]
Martoni has joined #milkymist
Martoni has quit [Client Quit]
Martoni has joined #milkymist
xiangfu has joined #milkymist
mumptai_ has joined #milkymist
<mumptai_> hi
<lekernel> hi
elldekaa has joined #milkymist
elldekaa has quit [Remote host closed the connection]
elldekaa has joined #milkymist
elldekaa has quit [Ping timeout: 248 seconds]
cladamw has quit [Quit: Ex-Chat]
elldekaa has joined #milkymist
mumptai_ has quit [Ping timeout: 244 seconds]
elldekaa has quit [Ping timeout: 246 seconds]
Jia has quit [Quit: Konversation terminated!]
xiangfu has quit [Ping timeout: 246 seconds]
kristianpaul has quit [Ping timeout: 272 seconds]
kristianpaul has joined #milkymist
elldekaa has joined #milkymist
kristianpaul has quit [Ping timeout: 272 seconds]
kristianpaul has joined #milkymist
elldekaa has quit [Ping timeout: 248 seconds]
mumptai_ has joined #milkymist
<qi-bot> The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120716-1155/
elldekaa has joined #milkymist
Martoni has quit [Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120615040410]]
xiangfu has joined #milkymist
Martoni has joined #milkymist
elldekaa has quit [Ping timeout: 255 seconds]
antgreen has joined #milkymist
antgreen has quit [Remote host closed the connection]
xiangfu has quit [Quit: Leaving]
mumptai_ has quit [Ping timeout: 246 seconds]
kyak has quit [Read error: Connection reset by peer]
kyak has joined #milkymist
kyak has joined #milkymist
jimmythehorn has quit [Quit: jimmythehorn]
kilae has joined #milkymist
mumptai has joined #milkymist
antgreen has joined #milkymist
Martoni has quit [Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120615040410]]
antgreen has quit [Ping timeout: 255 seconds]
kyak has quit [Ping timeout: 246 seconds]
jimmythehorn has joined #milkymist
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 246 seconds]
antgreen has joined #milkymist
robmyers has quit [Ping timeout: 265 seconds]
utzig has joined #milkymist
kyak has joined #milkymist
utzig has left #milkymist [#milkymist]
* Fallenou is trying to boot linux-milkymist on his M1
* Fallenou loaded two times simpleImage.milkymist_one into his M1 via serialboot using flterm, nothing after [DONE]
<Fallenou> kernel load address in .config is 0x40000000 and I did not specify a kernel address in flterm cmd line (since it's the default one)
<Fallenou> I just did ./flterm --port /dev/ttyUSB0 --kernel path/to/kernel
djbclark has joined #milkymist
djbclark has quit [Changing host]
djbclark has joined #milkymist
<Fallenou> and then hold one two buttons and then push the third (reboots the board afaik) and then ESC and serialboot
kilae has quit [Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120614114901]]
mwalle has joined #milkymist
<mwalle> Fallenou: you're there?
<Fallenou> yes
<mwalle> ah :)
<Fallenou> hi !
<mwalle> Fallenou: isn't it enough to set VADDR and PADDR (without the lowest bit set to anything special) and just use TLBCTRL to specify which TLB to update/flush/invalidate?
<Fallenou> yes why not
<Fallenou> for now it's not like this, but I could do it like this
<mwalle> wpwrak: btw i think we need the B* versions of the ITLB/DTLB/USR bits too, eg. the debug monitor should run with TLBs off and in kernel mode
<mwalle> Fallenou: lekernel_ had a nice idea to duplicate the IE register but just the bits we need in the new one
<mwalle> i kinda like that idea ;)
<Fallenou> what do you mean "duplicate" ?
<Fallenou> two CSR ? IE and IE2 ?
<mwalle> leave the IE register as is and use a new one (i called it PSW)
<mwalle> yes two CSRs bit with the xIE bits shadowed from the original one
<mwalle> so new programs can use this CSR and old ones the IE register
<mwalle> and we dont have to worry about backward compatibility
<mwalle> Fallenou: btw is the cache virtually indexed now?
<Fallenou> VIPT yes
<Fallenou> it was virtually indexed before as well
<Fallenou> but now it's physically tagged
<Fallenou> PSW <= is it an acronym for something ?
<mwalle> processor status word
<mwalle> if you have some better name, let me know ;)
<mwalle> hehe
<Fallenou> oh bradley manning =)
<Fallenou> I guess he is in serious shit
<mwalle> Fallenou: http://pastebin.com/z4QrHWFq these are the current csr's and bits
<Fallenou> oh !
<mwalle> and this is some small test program: http://pastebin.com/tzEtAqRS
<Fallenou> how does PSW and current IE interract ?
<mwalle> setting PSW.IE is same as setting IE.IE (rsp. EIE, BIE), its just shadowed into PSW
<mwalle> eg. setting IE.IE resutls in PSW.IE being set
antgreen has quit [Ping timeout: 250 seconds]
<Fallenou> oh ok so those 3 bits are mirrored to the two PSW and IE registers
<Fallenou> and PSW has extra bits
<Fallenou> so that we can only use PSW, but old software using IE still work
<Fallenou> sounds nice
<Fallenou> a bit weird, but it works
* Fallenou looking your pastebin
<mwalle> Fallenou: of course we could sacrifice backward compatibility and just the new CSR PSW replacing the old IE one, to be discussed ;)
<Fallenou> the reason for not using IE for TLB is that old software would mess everything up ?
<Fallenou> btw MMU stuff in lm32 would be optional (enabled or disabled in lm32_include.v) so that you can run old software without any problem synthetizing lm32 without mmu
<Fallenou> but functionally speaking I think your solution is the best
<Fallenou> it works in any case
<mwalle> Fallenou: yeah and avoid such things like TLBCHG, the bit wpwrak suggested
<mwalle> Fallenou: its not mine, its the best from lekernel_ and wpwrak ;)
<Fallenou> which adds instructions and therefore is not optimized ?
<mwalle> nah imho its a small hack ;)
<mwalle> i'll cleanup the qemu source, write some tests and put it on my github site, hopefully by tomorrow
<Fallenou> ok awesome :)
<Fallenou> I will implement CSR as we discussed ASAP
<mwalle> but as you said, nothing is fixed atm, i just wanted to provide 'some' implementation of an MMU
<mwalle> so we can play with it, i guess its easier in qemu than in hw ;)
<Fallenou> hehe easier or not it's time to spend :)
<Fallenou> your time is as valuable as mine
<Fallenou> don't want to lose your time
<Fallenou> but anyway , I think we agree on the implementation now
<mwalle> its fun ;)
<mwalle> Fallenou: btw it should be easy to read back the TLB entries, shouldn't it? maybe they are useful in debugging
<mwalle> i guess we're running out of CSRs...
<Fallenou> well I thought we were
<mwalle> iirc one of the unused csrs you mentioned is used for CSR2
<Fallenou> but I think we still have plenty of CSR
<mwalle> ähm
<mwalle> CFG2
<Fallenou> I listed in my email all IDs that I could not see in lm32_include.v
<mwalle> nonetheless there are also plenty of lower bits free in the wcsr/rcsr opcode
<Fallenou> thinking that since they were not listed, they were not used/implemented yet
<Fallenou> so free to use
<wpwrak> mwalle: PSW could also have the IE bits. so "new" software could use it instead of the IE register (why oh why did they have to use the same name for the register and the bit ?)
<wpwrak> mwalle: regarding B*, probably yes. i hadn't paid attention to them yet.
<Fallenou> B* ?
<wpwrak> BIE and corresponding B* bits for the TLB
<azonenberg> So I see some interesting blocks in the corner of spartan6
<azonenberg> anybody know what these do?
<mwalle> wpwrak: mh? my PSW suggestion have IE, USR, ITLB and DTLB in it
<azonenberg> SLAVE_SPI, SPI_ACCESS
<Fallenou> oh ok BIE, I see now, I never paid attention to breakpoint stuff :x
<azonenberg> SPI_ACCESS was mentioned briefly in these channel logs a while ago but i never heard if anyone figured out what it did
<azonenberg> you think there was originally plans for a stacked-die spartan6-N series like spartan3an?
<Fallenou> azonenberg: maybe ug333.pdf page 9/90
<azonenberg> what about SLAVE_SPI?
<Fallenou> it connects the fpga design with in-chip flash memory
<Fallenou> the spi_access
<azonenberg> yeah
<azonenberg> So that would mean there's bond pads on the s6 die
<azonenberg> intended to connect to stacked-die SPI flash
<azonenberg> that isnt actually used?
<wpwrak> mwalle: (PSW) ah, good. everything's covered then :)
<azonenberg> also, interesting
<azonenberg> spartan3an have atmel dataflash onboard
<Fallenou> hum slave_spi is maybe how to send bitstream through external spi ?
* Fallenou guessing
<azonenberg> Not sure
<azonenberg> it doesnt seem to be documented
<Fallenou> I know you can do this anyway
<Fallenou> cause I did it
<Fallenou> on a Spartan 3
<azonenberg> Yeah, i've made my own spi controllers too
<Fallenou> ok
<azonenberg> but slave implies fpga = slave
<azonenberg> so i wonder how that works
<Fallenou> well yes there is a mode in which you program the fpga, and fpga is a spi slave
<azonenberg> i know, but outside configuration what does that do
<Fallenou> an external uc sends clock and data
<Fallenou> "slave serial configuration"
<Fallenou> page 24/162 of ug380.pdf
<Fallenou> •Slave Serial configuration •Typical setup includes a processor providing data and clock.
<azonenberg> Yes, i know about that
<azonenberg> but what use is it outside of booting the fpga?
<azonenberg> having a dedicated fabric-routable block implies it's usable after configuration
<Fallenou> reconfiguration ?
<Fallenou> partial reconfiguration ?
<azonenberg> but it just looks to have connections to MISO, MOSI, CSB, CLK, etc
<azonenberg> like i would expect from external SPI
<azonenberg> how is that different from the ICAP
<Fallenou> hardware slave spi, in order for you not to implement it using fpga slice ?
<azonenberg> but it doesnt include a SERDES or parallel otput as far as i can see
<Fallenou> you seem to know more than me :)
<Fallenou> sorry I think I can't help
<azonenberg> i'm just looking at the pins hooked up in planahead
<azonenberg> w/e
<mwalle> azonenberg: maybe there are plans for the -N version of it, but no real customer yet?
<azonenberg> Perhaps
<azonenberg> also possible they just wanted to futureproof it
<azonenberg> i cant imagine those few extra bond pads cost much die area
<Fallenou> time to sleep for me, only slept 4 hours last night :)
<Fallenou> gn8 !
<mwalle> azonenberg: btw what are youre cpld reverse engineering efforts do? iirc you bought some xilinx cplds to make photos from the die?
<mwalle> Fallenou: gn8
<Fallenou> btw if someone knows why I cannot boot linux-milkymist on my M1 I am interested :p
<Fallenou> at some point I will need to have it boot :p
<azonenberg> mwalle: we took photos of an xc9536xl but have not gone any further than that
<azonenberg> at the moment my main RE efforts are focusing on a ST 24C02
<azonenberg> i want to fully understand the whole thing at transistor level
<mwalle> i2c eeprom?
<azonenberg> yes
<mwalle> because your hunting an i2c bug? :)
<azonenberg> nude photos of floating gates
<azonenberg> and no, just curious
<azonenberg> its simple and large process tech
<azonenberg> therfore shouldnt be impossibly hard to completely analyze
<mwalle> nice google maps on a chip ;)
<Fallenou> ahah yes
<Fallenou> *zZzZ*
<mwalle> i'm going to bed, too
<mwalle> gn8
mumptai has quit [Ping timeout: 246 seconds]