lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: Something to do? Port NuttX to Milkymist SoC
xiangfu has joined #milkymist
voidcoder has quit [Remote host closed the connection]
Jia has joined #milkymist
voidcoder has joined #milkymist
cladamw has joined #milkymist
rejon has joined #milkymist
cladamw has quit [Quit: Ex-Chat]
cladamw has joined #milkymist
Jia has quit [Quit: Konversation terminated!]
Jia has joined #milkymist
xiangfu has quit [Ping timeout: 246 seconds]
xiangfu has joined #milkymist
xiangfu has quit [Ping timeout: 250 seconds]
xiangfu has joined #milkymist
voidcoder has quit [Read error: Connection reset by peer]
xiangfu has quit [Quit: Leaving]
xiangfu has joined #milkymist
Jia has quit [Read error: Connection reset by peer]
cladamw has quit [Quit: Ex-Chat]
voidcoder has joined #milkymist
rejon has quit [Ping timeout: 245 seconds]
cladamw has joined #milkymist
<wolfspraul>
stekern: thanks for chiming in on the migen/next-gen discussion!
<wolfspraul>
I think we have a pretty nice round of thoughts and ideas, not bad
<wolfspraul>
I vaguely remember some plan of trying an openrisc core in the milky soc, do you still have that plan?
<stekern>
yes, I've got the BIOS up and running on an older milkymist soc (non -ng)
<stekern>
it was a while ago since I last tinkered with it, other projects have came in between, but I still got my m1 on my work desk, so it is by no means "drawered" ;)
<stekern>
actually, the project in between isn't completely unrelated, I'm working on a openrisc llvm backend, and part of what got me interested in looking into it was the ongoing work on llvm-lm32
rejon has joined #milkymist
<wolfspraul>
ok, nice
<wolfspraul>
that sounds like we can be hopeful there will be some completion and realization about the openrisc/milkymist marriage one day
<wolfspraul>
anything we can learn or use/reuse from openrisc is probably a good thing
<wolfspraul>
keep us posted :-)
<stekern>
I will
<wpwrak>
step 1: get openrisc to run on m1. step 2: make m1 multicore with lm32. step 3: convert one core to openrisc. step 4: brag about it in public. step 5: see if anyone can come up with an explanation why such a thing would make sense ;-)
<stekern>
isn't the generic answer to step 5: "Because we can!" ;)
<wpwrak>
that's the fallback answer :)
<stekern>
more seriously, milkymist switching to openrisc would make sense, it would lift some weights of the milkymist projects shoulders; we've got an upstream linux port, people working on the gnu toolchain (following upstream), no lattice people boosting about them being "official maintainers" ;)
<wpwrak>
how do the two compare in terms of speed, size, code quality ?
<stekern>
but, a lot of effort has been made in the milkymist project on the lm32, I kind of dislike the idea of pulling the mat from under the feets of them
Jia has joined #milkymist
<wpwrak>
does openrisc have an mmu ?
<stekern>
the or1200 implementation has one, yes
<stekern>
the biggest problem is that the or1200 implementation kind of "sucks"
<Jia>
or1200's insns code is suck
<stekern>
but that is being worked on with this effort of a new implementation (but that doesn't have an mmu yet)
<wpwrak>
it seems to have quite a fan base. two people saying it sucks, within seconds ;-)
<wpwrak>
so it looks like somthing that will get back and forth for a while longer before it's really comparable
<stekern>
openrisc and lm32 ISA is very similar
<Jia>
lm32 insns code is more clear, like mips.
<Jia>
the same at the other side.
<Jia>
but lm32 has no MMU
<wpwrak>
Fallenou: did you hear that ? :)
<wpwrak>
who do they compare in terms of gate count and performance ?
<stekern>
or1200 and lm32? or the new implementation and lm32?
<wpwrak>
best_of_openrisc vs. lm32
<stekern>
the new implementation and lm32 is about comparable in terms of gate count and fmax
cladamw has quit [Ping timeout: 260 seconds]
<stekern>
Jia: what sucks?
<Jia>
stekern: opcodes/or32-opc.c
<Jia>
AAAAA BBBBB CCCCC
<wpwrak>
stekern: why does the or1200 rewrite drop the mmu ? it is just a way of structuring the work (e.g., do without mmu first, add mmu soon thereafter) ? or may the mmu not come back at all ?
<stekern>
wpwrak: well, it's a complete rewrite, so it didn't even have caches (until I helped out implementing them)
<stekern>
so it will come in time
<wpwrak>
(caches) ;-)
<wpwrak>
sounds as if it'll take a bit to complete and mature
<wpwrak>
but of course, when done, it could be quite attractive
<stekern>
yes, most definetely will take time to mature
<stekern>
Jia: you mean how the bits in the instructions are layed out? yeah, that is a bit messy
<wpwrak>
pity we don't have any decent time machine. then we could avoid doing lm32-specific work if the 2014 edition of or1200 is clearly better for our needs
<wpwrak>
there are no ugly instruction sets. except for PIC :)
<wpwrak>
that one is so evil, it simply absorbs the entire ugliness of the universe
<stekern>
I've managed to avoid PICs for the most of my life (apart from one project) ;)
<wpwrak>
when i started to experiment with MCUs, i began with PIC. in assembler. the good thing about such a start is that no matter what happens later, it can only get better :)
<stekern>
kind of my story too, but I found AVRs early enough to ditch PICs after that first project ;)
cladamw has joined #milkymist
<stekern>
(2014 edition) I can smell the sarcasm in that ;) but I agree, lm32 is probably the still the right choice for the project (for the time being)
xiangfu has quit [Ping timeout: 256 seconds]
<wpwrak>
(2014) do you think it'll be reliably usable and with a full feature set (i.e., MMU) sooner ? especially testing and optimizing may take a bit
<wpwrak>
anyway, time to suspend. thanks for the openrisc infos ! worth keeping an eye on
<stekern>
hard to tell, time will show, but we're working on it ;)
<stekern>
suspend tight ;)
xiangfu has joined #milkymist
elldekaa has joined #milkymist
rejon has quit [Ping timeout: 246 seconds]
Jia has quit [Quit: Konversation terminated!]
Jia has joined #milkymist
methril has quit [Quit: Leaving]
Jia has quit [Quit: Konversation terminated!]
Jia` has joined #milkymist
Jia` is now known as Jia
Jia has quit [Read error: Connection reset by peer]
Jia has joined #milkymist
wolfspraul has quit [Quit: leaving]
rejon has joined #milkymist
lekernel has joined #milkymist
voidcoder has quit [Remote host closed the connection]
voidcoder has joined #milkymist
Jia has quit [Quit: Konversation terminated!]
rejon has quit [Ping timeout: 240 seconds]
rejon has joined #milkymist
rejon has quit [Ping timeout: 265 seconds]
rejon has joined #milkymist
rejon has quit [Ping timeout: 246 seconds]
<Fallenou>
wpwrak: hehe I just read, sounds like for now lm32+mmu would be the killer couple !
<Fallenou>
I thought about how we could reduce the penalty of flushing the MMU TLB during scheduling()
<Fallenou>
For things that have to be fast we could use one process and multiple threads :)
<Fallenou>
you don't have to flush MMU TLB for switching between threads
<Fallenou>
since everything is in the same virtual address space
<Fallenou>
it would be a way of taking the benefits of MMU protection to protect against other processes (DHCP ? shell ? other things ?) but keeping for instance flickernoise "reactive"
<Fallenou>
anyway, just a thought, in case there is a noticeable slowdown caused by linux scheduling (flushing and reloading MMU TLB)
<Fallenou>
reloading MMU should be done in a lazy way I guess (only on page faults) which could help to increase performance too
xiangfu has quit [Remote host closed the connection]
cladamw has quit [Quit: Ex-Chat]
Guest10379 is now known as zumbi
zumbi is now known as Guest72020
Guest72020 is now known as zumbi_
cladamw has joined #milkymist
elldekaa has quit [Read error: Connection reset by peer]
elldekaa has joined #milkymist
<lekernel>
Fallenou: yes, by all means, announce the mmu commits here
<lekernel>
so this thing used the SRAM chips in combination with the CPLD to store those 32 lines
<Fallenou>
ahah nice
<lekernel>
the thing also had a built in code breaker, that would take a few minutes and then store the result in the supercapacitor-backed main (and slower) SRAM chip of the 68HC11
<Fallenou>
I think the off chip sram was the L2 cache, L1 was on-chip
<wolfspraul>
I was trying to look at the llhdl sources but couldn't find them, github gives me a 404
<wpwrak>
lekernel: have you seen my comments about monitors with built-in touch screens ? there seem to be some quite decent models on the market now, mainly by iiyama. that should be a nice platform to develop your new gui and the things underneath.
<kristianpaul>
oh
<kristianpaul>
gone !!
<kristianpaul>
(llhdl)
<kristianpaul>
lets see if i still have local copy..
<wolfspraul>
if it's possible, it will most likely outperform m1 in a number of areas
<kristianpaul>
projectm is in debian yes wolfspraul
<wolfspraul>
that needs to be said openly and honestly, not in any vague way
<wpwrak>
ironically, i couldn't find it via broadcom.com
<lekernel>
wolfspraul: it's certainly possible. you'd have more latency, though.
<kristianpaul>
Fallenou: yes hw development, custom cores and video acelaration, but we cant forget software as well
<wolfspraul>
I would compare that when it's working
<wolfspraul>
element14 is a large chinese distributor
<wolfspraul>
maybe they just upload docs? :-)
<wolfspraul>
and broadcom is pulling their hair out over the uncontrollable chinese :-)
<kristianpaul>
he
<wolfspraul>
any FAE in china will just copy/paste entire trees full of nda/confidential documents anyway
<wolfspraul>
to anybody who buys even 3 chips for 10 USD
<wolfspraul>
fae or salesman
<wpwrak>
wolfspraul: that may just be a cache. i think the release was more official. but my quick search didn't turn up the original posting / article
<wolfspraul>
I think I read something from the rpi project that they managed to get some datasheet out of broadcom for release
<lekernel>
wolfspraul: still don't like the mirteo? another area where it helps. :)
<wolfspraul>
where you need to know that rpi *is* broadcom marketing
<kristianpaul>
Fallenou: so wen need to choose our targets very well, so still a gap to innovate in hw as well
<kristianpaul>
i think..
<wolfspraul>
you can't expect to fool people multiple times
<wolfspraul>
maybe try a new name first :-)
<wolfspraul>
I think m1 is on good track and with the things we have learnt and are learning we will figure out how to sell it successfully
<wolfspraul>
I have no problem at all understanding the excitement behind rpi though
<wolfspraul>
m1 is pretty lousy on almost all tech specs I can think of
<wolfspraul>
compared to other 'modern' tech
<lekernel>
but the mirteo won't.
<wolfspraul>
so? the people we have found need to see other values
<kristianpaul>
have you qoute a dmx controller recently? :)
<wolfspraul>
I don't believe the (many) shortcomings we have started to understand on m1 wouldn't reappear in later products again
<wolfspraul>
ah god, of course
<wolfspraul>
m1 is full of features that are started, full of bugs, never seriously fixed or marketed or tested or anything
<wpwrak>
lekernel: i think a monitor+touch combined with the existing M1 would be a much quicker way to a new user experience
<Fallenou>
+1
<Fallenou>
step by step :)
<wpwrak>
the blocks you put on the reactable seem more an obstacle than a feature to me. sure, they're a novelty effect, but you should be able to just do the same with only a touch screen
<wpwrak>
you can still aim for star trek aesthetics. they look good, even today :)
<Fallenou>
but the novelty effect could affect sells :)
<Fallenou>
there is little difference sometimes between a product that sells and a product that does not sell
<wpwrak>
Fallenou: yes, until VJs start complaining that they lost blocks and such
<Fallenou>
sometime it's just some design stuff
<Fallenou>
colour, texture
<Fallenou>
or just the brand =)
<Fallenou>
if you do a tablet, you get compared to Apple ipad etc
<Fallenou>
and you will never win
<wpwrak>
consider the mobile VJ who bring the equipment to the club. i don't thing the idea of carrying a bag of essential expensive little blocks is very appealing to them.
<Fallenou>
if you do a table with objects, you get compared to what ? :)
<Fallenou>
to nothing
<wolfspraul>
I believe milkymist as a platform has legs. if we fix some of the many many bugs, it will find its way to more happy users.
<Fallenou>
you're just cool
<wpwrak>
each morning, they get to count now many they have lost. crawl on the floor, etc.
<wpwrak>
and every once in a while, the one they would need just now (during the show) can't be located.
<Fallenou>
indeed it's a problem
<wpwrak>
none of these issues happen if it's just a screen
<Fallenou>
you could think of a rf signal that makes them blink and play a loud sound
<Fallenou>
like some gadget not to lose your keys
<wpwrak>
plus, you can get industrially made rugged screens.
<Fallenou>
(rf signal, to please wolfspraul :D)
<wpwrak>
as if you would hear them beep for their mother while the music is on. you must visit very quiet clubs ;-)
<Fallenou>
ahah
<Fallenou>
search for them after the club is closed
<Fallenou>
while packing
* kristianpaul
wonder how famous a reactable is now that the tables is on its rush
<wpwrak>
and you've just made them quite a bit more expensive. now they need to store offline power, too.
<kristianpaul>
whne i met the reactable 4 years ago was intersting, but now will call same atention?
<Fallenou>
indeed, it was just a random thought, maybe not a good idea :/
<kristianpaul>
but definetelly we need a touch interface that can be compated with ipads..
<wpwrak>
(monitor+touch) i find the idea of having a separate control surface very appealing. we've discussed that before. and the reduction from a tablet to a monitor is a welcome simplification. so i like the mirteo idea that far.
<wpwrak>
but mirteo adds a lot more complications. things that most likely work against it.
<kristianpaul>
i agree with separate
<lekernel>
right now the only sensible argument against it is the lost objects
<lekernel>
any more?
<wpwrak>
and since you need some sort of mounting frame anyway, you can hide any features of m1 you don't like inside. don't want users to plug in usb ? just add a little wall. done :)
<wpwrak>
amount of work to get it to function reliably
<wpwrak>
also, you want to redo m1 in the process. this increases the amount of work even more.
<lekernel>
if we drop all the pesky stuff (USB, ...) it's not that much work
<wpwrak>
i don't think you believe that yourself ;-)
<lekernel>
I find the general M1 development could have been even more efficient
<wpwrak>
besides, as i mentioned, you don't have to worry about things like usb
<wpwrak>
the M1 would just be inside the frame
<wpwrak>
you can hide or reveal whatever you feel comfortable with at that time
<wpwrak>
and if you change your mind. that's just a matter of cutting a new frame. half a day of carpentry.
<kristianpaul>
lekernel: we do really need ddr3 and next xilinx chips _now_ to improve video out specs?
<kristianpaul>
lekernel: anymore, yes, start over again :)
<wpwrak>
we need better memory for 32 bpp AND higher resolution. it seems that m1rc3/m1r4 will be more than adequate for driving a secondary screen for control functions
<kristianpaul>
good
<kristianpaul>
so the wall interface as an accesory to current m1 is what you propose right?
<wpwrak>
worst case, you'll need to make a little expansion board that adds another VGA out (for m1rc3). been there, done that (ubb-vga) :)
<kristianpaul>
lol
<kristianpaul>
:)
<kristianpaul>
and yes,
voidcoder has quit [Quit: See you next time]
<kristianpaul>
wolfspraul still want a second screen? :)
<kristianpaul>
that idea/request came from long before i remenber
<kristianpaul>
now is the time it seems
<wolfspraul>
of course
<wolfspraul>
digital
<wolfspraul>
maybe with r4 we can drive both the vga & digital separately?
<wolfspraul>
but it depends on how much sebastien focuses on m1 at this point and gets the whole migen power to i1
<wolfspraul>
otherwise we have to backport and that may be slow
<wolfspraul>
but we get to it, I think we have 2 screens on r4
<wpwrak>
(multi-screen with m1r4) definitely. of course, not a lot of resolution, because already one 640x480 at 32 bpp outout will tax the system
<lekernel>
what about r5 with ddr3, -7 and dual video output?
<wpwrak>
but a 1 bpp channel for the secondary display should be no problem
<wolfspraul>
sure
<wpwrak>
lekernel: that would be a sensible evolution
<lekernel>
wpwrak: I think there might still be some bw left
<wpwrak>
even better :)
<lekernel>
but then there will be the compatibility problem with r5
<wolfspraul>
r5 with -7 ddr3 etc would be great
<kristianpaul>
so, we do really need ddr3 and next xilinx chips _now_ to improve video out specs?
<kristianpaul>
lekernel: ^
<wpwrak>
m1r4 could still do the same with 1 bpp :)
<wolfspraul>
compatibility will be a big issue, and at multiple layers of the system, but that's something we can help with I think
<lekernel>
wpwrak: but then software has to handle 1bpp
<wpwrak>
well, there's no free lunch :)
<wolfspraul>
kristianpaul: those things go in parallel
<wolfspraul>
m1rc3 is not maxed out
<wolfspraul>
m1r4 not even made yet
<lekernel>
kristianpaul: no. -ng should already increase the bandwidth by 2x to 4x
<wolfspraul>
and m1r5 only in conceptional stage
<lekernel>
on the current m1 boards
<Fallenou>
2x 4x <= awesome :'
<kristianpaul>
wolfspraul: yes sure, i dont mind having a s-7 dd3 box _just_ for the full HD thing
<wolfspraul>
yeah
<kristianpaul>
Fallenou: indeed :)
<wolfspraul>
if you can bring that to m1, or if we can (reasonably, that is practically) help, many people would be happy. well. some people :-) not as many as there are rpi users...
<wpwrak>
the new gui will need quite a bit of work anyway. adding 1 bpp support should be a pretty minor item, compared to the rest
<lekernel>
wpwrak: I think the second fb could work at 16bpp
<lekernel>
maybe 32 even
<wpwrak>
that would be pretty amazing. of course, it may actually look its best with very few color. an austere style can be very appealing.
<lekernel>
we're using 3 gbps atm, switching to 32 would make that 6, and -ng has up to 10
<kristianpaul>
wolfspraul: parallel indeed, but no drop one effort and begin other from scratch :)
<wpwrak>
sends a strong message of this being a tool that gets the job done
<kristianpaul>
bbl lunch
<wolfspraul>
enjoy
<Fallenou>
a framebuffer uses ram bandwidth quite efficiently, since it's always burst access
<lekernel>
-ng reorders ram transactions anyway to make them efficient most of the time :)
<Fallenou>
is there some case where reordering adds latency ?
<lekernel>
reordering always adds latency
<lekernel>
so it will make software a bit slower (though if the L1/L2 cache hit rate are high, only by a few percent at worse)
<lekernel>
and TMU/FB/video-in will be redesigned to cope with latency better
<Fallenou>
ok
<lekernel>
there are some experiments to do, like disabling reordering for transactions that emanate from software and schedule them for minimum latency
<lekernel>
I can try that, if it turns out that some performance-critical software code becomes memory-bound
<Fallenou>
hum readchar without interrupt seems tricky
<Fallenou>
that would mean I would basically lose any character coming from the uart while I am not waiting for it doing while(UART_EVENT_REGISTER & EVENT_RX);
<Fallenou>
gn8 !
Jia has joined #milkymist
voidcoder has quit [Remote host closed the connection]