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
<Fallenou> ok !
Gurty` has joined #milkymist
Guest53508 has quit [Ping timeout: 265 seconds]
cladamw has quit [Quit: Ex-Chat]
kilae has joined #milkymist
<Fallenou> a few CPUs I just unplugged from their old socket : http://sionneau.net/old_computers/cpu/DSC01897.JPG :' RIP my old computers
<Fallenou> lekernel: on my 486 motherboard there was 5 SRAM DIP chips , what do you think they were there for ? ( http://www.datasheetcatalog.com/datasheets_pdf/W/2/4/5/W24512AK-15.shtml )
* Fallenou is just curious
<lekernel> cache memory
<Fallenou> external cache memory for the 486 cpu ?
<lekernel> I remember those from syster hack :) with a mach130 cpld and a 68hc11
<lekernel> old times
<lekernel> yes
<Fallenou> hehe ok
<Fallenou> it seems to be still valid chips
<Fallenou> contains 64 Ko which is not ridiculous
<Fallenou> and 1 cycle access, and quite fast :)
<lekernel> 15ns is pretty slow
<Fallenou> for an external memory ?
<lekernel> by today's standards
<Fallenou> ah yes
<lekernel> well, yeah, modern SRAM can be 7ns or less
<Fallenou> compared to DDR1/2/3 and such
<Fallenou> ok =)
<lekernel> it's a pity the syster hack schematics aren't online... those were really nice, especially for their time
<lekernel> you had to download them from a BBS at 9600bps :)
<Fallenou> open source computer ?
<lekernel> pirate TV decoder
<Fallenou> oh ok
<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
<Fallenou> for the i486
<lekernel> aha! found it
wolfspraul has joined #milkymist
<GitHub15> [milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/QmDDNQ
<GitHub15> [milkymist-ng/master] software/libbase: malloc family decl in stdlib - Sebastien Bourdeauducq
<GitHub15> [milkymist-ng/master] software/libbase: more file decls in stdio - Sebastien Bourdeauducq
<wolfspraul> are those links still up-to-date? http://www.milkymist.org/fpgatools/
<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..
<kristianpaul> phew
<wpwrak> here's a copy. not sure how up to date, though: https://github.com/errordeveloper/llhdl
<kristianpaul> i dont find mine..
* kristianpaul sigh
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
<wolfspraul> let's get word from lekernel first
<kristianpaul> please :)
<lekernel> yes, the errordeveloper copy looks up to date
<wolfspraul> the links on milkymist.org point to a 404 page?
<wolfspraul> is that on purpose?
<lekernel> no
<wolfspraul> how about antares?
<lekernel> just an oversight
<wpwrak> did you rename it ?
<wpwrak> (on github)
<lekernel> no, deleted. if I were to continue working on it, I'd write it in a different way anyway.
<wolfspraul> ah? are you serious? and you mean until then you better don't want anybody else read the sources that were published so far?
<wpwrak> would have been more polite to announce that deletion a bit in advance
<wolfspraul> should we link milkymist.org to the errordeveloper copy?
<wolfspraul> how about antares?
<wpwrak> it's not as if the secret police would descend on you if it sat there for a few weeks longer
<lekernel> (annoucing) sorry about that. didn't think too many people cared anyway.
<kristianpaul> can yo re-publish it? at least for achiving porpuses a tar would be ok..
<kristianpaul> s/yo/you
<lekernel> ok. but then you take care of it :)
<kristianpaul> well, for now i care about read the sources
<wolfspraul> yes cool, bring it back please that would be great. and the links on milkymist.org will work again too :-)
<lekernel> kristianpaul: are you really reading that much source code?
<kristianpaul> i was once i wanted to know how to make the LUT6 work for spartan3
<wpwrak> it can be useful reference material for someone else who wants to work in that direction. every bit helps :)
<kristianpaul> yup
<lekernel> in the open source community, no one wants to work in that direction. even open-CPUs are obscure things.
<wpwrak> nobody does it and all agree it would be pointless. until someone does ;-)
<lekernel> otherwise that linux port would be long done, among other things
<lekernel> instead, people rush to port their software to the rpi
<wolfspraul> well, I just thought about it today
<wpwrak> you mistake priorities for lack of interest
<wolfspraul> say you have an rpi + usb webcam
<wolfspraul> how hard is it to port milkdrop to it, and get it to do m1-like effects?
<wolfspraul> the hardware costs 30 USD rpi + 20 USD webcam
<wolfspraul> I think it could beat m1 on many angles?
<lekernel> you're just making my point
<lekernel> and this is why I want distinctive hw features, and no generic features like USB that people take for granted
<wolfspraul> well, seriously? I think maybe that would be easy to get to work and performance-wise should not be too bad either
<wolfspraul> and it would most likely exceed the m1 in many many tech specs, resolution, bit depth, extremely better usb, etc. etc.
<lekernel> give me broadcom's budget ...
<wolfspraul> I don't know, won't try. but somehow thinking about it I do believe it could just work. apt-get install milkdrop? is that in debian?
<wolfspraul> maybe even multiple webcams?
<Fallenou> rpi is not for developping
<Fallenou> it's just a portable desktop
<Fallenou> mini desktop
<Fallenou> you don't have access to the SoC datasheet, therefore you can do nothing with it in term of development
<wolfspraul> sure, but maybe one could run m1-like effects on it, and even beat m1 on a lot of aspects?
<Fallenou> you can just boot it up and run your debian
<wpwrak> i think there's something a bit more pc-like from via, for about USD 50
<wpwrak> Fallenou: broadcom released the data sheet for the soc, with information on most of the subsystems
<Fallenou> in term of jitter/latency I'm not that sure about what the soc would do
<Fallenou> wpwrak: oh really ? OK I didn't know
<Fallenou> I'm wondering, why are FPGA so slow ? I don't see any softcore operating at more than 150 MHz :/
<Fallenou> for instance Leon3 : 125 MHz as a softcore | 400 MHz as a 0.13 um ASIC
wolfspraul has quit [Ping timeout: 240 seconds]
<Fallenou> Leon4 : 150 MHz as a softcore | 1.5 GHz on 32 nm ASIC
kilae has quit [Read error: Connection reset by peer]
wolfspraul has joined #milkymist
elldekaa has quit [Remote host closed the connection]
<kristianpaul> distinctive hw features, but what about software?
<kristianpaul> not all is about hw :)
<wolfspraul> ok so for the time being we can just assume that it 'may' well be possible to implement m1-like features with rpi+webcam
<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
<wpwrak> it's "official", though
<wolfspraul> I rather fix m1 bugs
<kristianpaul> m1 either, still have dmx
<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
wolfspraul has quit [Quit: leaving]
<Fallenou> lekernel: http://pastebin.com/767KifbS why don't I see my uart_write() ?
<Fallenou> it seem to hand the SoC
<Fallenou> hang*
<Fallenou> I guess it's blocked waiting for some ack/irq from uart core
<Fallenou> but can't figure out why
<Fallenou> am I not setting it up to polling mode ?
<Fallenou> (just look at the main() )
<lekernel> hmm iirc there's no polling mode
<lekernel> it always needs irqs
<Fallenou> err my pastebin is wrong
<Fallenou> it's not what I wanted to paste
<lekernel> nevertheless I think I remember removing the polling uart code
<Fallenou> here is the content of my main() : http://pastebin.com/rAd43s04
<Fallenou> oh
<Fallenou> because now mmu activates itself upon interrupt/exception
<Fallenou> but for debug purposes it was usefull to be able to do printf(); without activating mmu
<lekernel> let me check...
<Fallenou> to ensure that MMU does not activates itself when I don't want to, I disabled IRQ in the bios C code
<Fallenou> but then indeed uart does not work anymore
<Fallenou> ok thanks
<lekernel> nah, print should still work
<lekernel> it's polling there
<lekernel> does uart_force_sync() return?
<Fallenou> ok that's what I thought
<Fallenou> I could try to make a LED blink after uart_force_sync() to check
<lekernel> I removed it in -ng but not in legacy
<lekernel> (the polling)
<lekernel> Fallenou: why not try printing something immediately before and after force_sync?
<Fallenou> using uart_write() ?
<lekernel> your uart doesn't work at all? even while the mmu is still disabled?
<Fallenou> or directly writting to uart register ?
<lekernel> uart_write
<Fallenou> I think I tried and it did not write anything
<Fallenou> let me recheck
<Fallenou> it does not write anything
<Fallenou> btw I am using regular bitstream, official milkymist one, without any MMU stuff
<lekernel> is the uart cable correctly connected?
<Fallenou> when I say "nothing", means nothing after SDRAM initialization text
<Fallenou> All SDRAM initialization completed, boot continuing.
<Fallenou> this is the last thing I can see
<lekernel> even with milkymist.org/updates ?
<Fallenou> what do you mean ?
<lekernel> try the known-good images
<Fallenou> the bitstream is the official one
<Fallenou> the bios is modified
voidcoder has joined #milkymist
<Fallenou> http://pastebin.com/u4c62y2q <= this is working (writting F in uart)
<Fallenou> http://pastebin.com/q50HPnS0 <= this is not
<lekernel> calling uart_init(); again will put you back into irq-driven mode
<lekernel> you should call it only once
<lekernel> at the beginning of main
<lekernel> before force_sync or anything else
<Fallenou> oh right !
<Fallenou> ok working now :)
<Fallenou> thanks !
<Fallenou> I can see "EF"
<Fallenou> I just moved uart_init() up
<GitHub13> [milkymist-ng] sbourdeauducq pushed 4 new commits to master: http://git.io/xjY4Gw
<GitHub13> [milkymist-ng/master] software/libbase: fix stupid mistake in limits.h - Sebastien Bourdeauducq
<GitHub13> [milkymist-ng/master] software/libbase: use compiler-rt - Sebastien Bourdeauducq
<GitHub13> [milkymist-ng/master] software/libbase: add strerror - Sebastien Bourdeauducq
<Fallenou> test_user_abort() seems not to work in polling mode
<Fallenou> it's using readchar_nonblock()
<Fallenou> even if I enter ESC or Q it's booting from flash
<Fallenou> I will just remove the test I guess
<wpwrak> writing with polling still works ? that would be pretty essential for a lot of low-level work
km2 has quit [Ping timeout: 276 seconds]
<lekernel> yes
<lekernel> though not implemented in -ng, but that wouldn't be the hardest thing to do when needed
km2 has joined #milkymist
<GitHub196> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/uUSx6w
<GitHub196> [milkymist-ng/master] software/libbase/vsnprintf: treat %g as %f (temporary hack) - Sebastien Bourdeauducq
methril has joined #milkymist
<GitHub52> [misp] sbourdeauducq created master (+9 new commits): http://git.io/8vIyTg
<GitHub52> [misp/master] Initial commit. fdlibm. - Sebastien Bourdeauducq
<GitHub52> [misp/master] libm: rename fdlibm.h -> math.h - Sebastien Bourdeauducq
<GitHub52> [misp/master] gitignore - Sebastien Bourdeauducq
<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]
voidcoder has joined #milkymist
lekernel has quit [Ping timeout: 246 seconds]
lekernel has joined #milkymist