<Fallenou> ok :)
<Fallenou> lekernel: why is the video echo 512x512 -> 1024x768 30fps 16bpp taking 900 Mbps ?
<Fallenou> taking transparency into account makes 24 bpp right ?
<lekernel> video echo is translucent, so you need to read-modify-write the framebuffer
<lekernel> no, everything is 16bpp
<Fallenou> I arrive at  720 Mbps
<Fallenou> oho k
<lekernel> and read the 512x512 framebuffer too
<Fallenou> ok got it
<lekernel> wolfspraul: hi
<lekernel> the video input on my mm1 (which was the one we did the ESD tests with) just broke down on me. it detects a SECAM 525 signal even when there's nothing connected, and the picture is always black no matter what you do (didn't do other investigations atm but will check tomorrow)
<lekernel> have you seen anything like that already?
<wolfspraul> hmm
<wolfspraul> I vaguely remember at one time (and only once) during rc2 testing, we had a case where something SECAM was detected.
<wolfspraul> we ran the test again and it went away, so we didn't investigate further
<wolfspraul> let me try to grep the production testing log files, if I can fine them. one sec...
<wolfspraul> lekernel: you there?
<wolfspraul> I have one AD_RESULT of 7, the others are 4.
<wolfspraul> what does AD_RESULT mean again?
<wolfspraul> aw_: good morning
<wolfspraul> Sebastien just posted a bug he ran into, let me repost...
<wolfspraul> "the video input on my mm1 (which was the one we did the ESD tests with) just broke down on me. it detects a SECAM 525 signal even when there's  nothing connected, and the picture is always black no matter what you do (didn't do other investigations atm but will check tomorrow)
<wolfspraul> "
<wolfspraul> I remember that one time during testing, there was something SECAM we ran into, right?
<aw_> wolfspraul, good morning
<wolfspraul> but only once, and then never again, if I remember correctly
<aw_> yes, it did show up one time. exactly correct.
<aw_> your mm1 broke down? and now it detects always a SECAM 525 without video-in plugged?
<wolfspraul> aw_: I grepped through the production test logs, I find one AD_RESULT of 7, the others are all 4
<aw_> yes
<wolfspraul> btw, for the next run I want to do even more extensive logging, and we should archive 100% of the logs
<wolfspraul> you never know later what you might want to search in the logs :-)
<aw_> yes. if more logs can be generated by test program, it always good info.
<aw_> yes, i remember that one.
<wolfspraul> maybe lekernel is already sleeping. not much we can do right now, let's see what he finds tomorrow.
<wolfspraul> maybe another improvement/fix we can roll into rc3 :-)
<wolfspraul> what does AD_RESULT 7 mean?
<wolfspraul> two more bits set (1 and 2), the others are all AD_RESULT 4
<aw_> p18 of video decoder 7181B has autodetect function to recognize what video format it is. 7 is the SECAM 525 format detected.
<wolfspraul> hmm
<wolfspraul> ok
<wolfspraul> we gave sebastien feedback, now we need to see what he finds on his board
<wolfspraul> aw_: watch out for more secam detections... Back then it was only once and went away, so we didn't pay more attention.
<wolfspraul> maybe we should list it on the 'rc2 known issues' list?
<wolfspraul> even if it's rare etc... ?
<aw_> wolfspraul, okay let me add. btw the PAL-B/G/H/I/D is AD_RESULT 4.
<wolfspraul> yes I see it now - thanks for ds link
<wolfspraul> do you have any idea why the chip auto-detects the wrong format?
<wolfspraul> I'm curious to see whether the problem goes away when Sebastien reboots his m1, or whether it persists.
<aw_> such problem may need to check video out format from the device he set firstly, i quite don't  know how it detected wrong.
<wolfspraul> alright. let's just add it to 'known issues' and wait until we hear more from Sebastien.
<aw_> if with a standard video pattern generation and given test more times via test program on his board probably can reproduce such wrong detection.
<aw_> wolfspraul, added.
<wolfspraul> perfect. we keep an eye on it.
<Fallenou> the slides for the OSHUG #8
<Fallenou> tomorrow (humm in a few hours)
<Fallenou> 30 minutes talk, it's gonna be quick :)
<wolfspraul> Fallenou: do you think there is anyone there who wants to buy an m1 board?
<Fallenou> I have really no idea
<wolfspraul> especially someone who seriously needs it and would start serious work with it right away? :-)
<Fallenou> maybe I will be able to tell you tomorrow after the talk
<wolfspraul> the reason I'm asking is that I only have 2 left now.
<wolfspraul> although there may be some more at Bearstech, Tuxbrain, etc.
<Fallenou> yes
<wolfspraul> we work hard on rc3, but we may be out of stock for a number of weeks, which is bad :-) (I should never run out of stock)
<Fallenou> I will try my best to make them want one ;)
<wolfspraul> yes, great!
<wolfspraul> let's make sure those 2 go to really great guys
<Fallenou> yes it would be goo to have feed backs
<wolfspraul> thanks a lot for your help btw!
<Fallenou> good*
<Fallenou> and contributions
<wolfspraul> oh you bet
<Fallenou> you're welcome :)
<wolfspraul> how many people will come to that talk?
<wolfspraul> is it broadcast in any way?
<wolfspraul> do you have milkymist stickers? (bit late too ask :-)) but maybe for next time...)
<wolfspraul> nice PDF. what is the license of the pdf?
<Fallenou> whatever you want :p
<Fallenou> it's a mix of several presentations lekernel did
<wolfspraul> ok so let's just say cc-by ?
<Fallenou> I tried to take the best of several slides he did
<Fallenou> it's OK for me :)
<wolfspraul> if possible, just add a little cc-by somewhere
<Fallenou> should I write it somewhere ?
<wolfspraul> also attribution - who are the authors
<Fallenou> hum ok will do that tomorrow
<Fallenou> I doubt lekernel will sue me for using his slides for presenting his project :p
<wolfspraul> it's enough you have a tiny "cc-by Sebastien Bourdeauducq & Yann Sionneau" somewhere
<wolfspraul> no sure, of course not
<wolfspraul> but the problem spreads
<Fallenou> ok ok
<Fallenou> Will put that
<wolfspraul> once we are sloppy on marking the license SOMEWHERE, and attributing the authors, then later we will never clear it up anymore
<wolfspraul> then we have lots of content with unclear licensing and authorship - BAD
<wolfspraul> because people will ask "who wrote it?" and we don't even know
<wolfspraul> they will use that to cast doubt over the whole project
<wolfspraul> so we need to be a little diligent along the way
<Fallenou> sure I understand your concern
<Fallenou> you're totally right
<wolfspraul> do you have notebook stickers?
<Fallenou> humm no I have no stickers
<wolfspraul> if not, and if you have another conference again one day, please email me your postal address and I'll send you a pack
<Fallenou> no flyers
<Fallenou> no board
<Fallenou> ok will do
<wolfspraul> let's start, one by one
<wolfspraul> email me your postal address, and the stickers are on the way
<wolfspraul> wolfgang@sharism.cc
<Fallenou> ok thanks I'm sending the e-mail right now
<wolfspraul> great, thank you
<wolfspraul> what software did you use to make that presentation? looks like beamer/tex?
<Fallenou> yes it is
<wolfspraul> if possible, remember to upload the original somewhere
<wolfspraul> then it's easier for others to remix later
<Fallenou> ok
<wolfspraul> you could even have a url to the original in the pdf itself
<Fallenou> sure I had big troubles remixing one of lekernel pdf
<Fallenou> since the sources were lost
<wolfspraul> I can imagine :-)
<wolfspraul> it's always the same little things, isn't it? :-)
<Fallenou> but for the others it was OK
<Fallenou> hehe yes :)
<wolfspraul> put a URL to the tex original into the pdf, that would be perfect
<Fallenou> I'm going to sleep
<Fallenou> i'm really tired
<wolfspraul> sure
<wolfspraul> n8
<wolfspraul> great presentation
<wolfspraul> good luck!
<Fallenou> it's 1:30 am in London atm :)
<Fallenou> and i'm working tomorrow :p
<wolfspraul> yeah
<wolfspraul> I'm sipping my morning coffee
<wolfspraul> actually get another one now :-)
<wolfspraul> n8
<Fallenou> thanks!
<Fallenou> gn8
<xiangfu> Hi aw_
<aw_> hi xiangfu
<xiangfu> if the "D2" and "D3" 'shine' when plug the power.  what I should do?
<aw_> at first power-up normally?
<xiangfu> aw_: no.
<aw_> but you described 'shine' when plug the power. or power on   for a while then off ...and on? or other?
<xiangfu> 1. the milkymist can power on normally. I can see the 'control panel'
<xiangfu> 2. I try to connect nanonote and milkymist by using UART. since they are both 3.3v
<xiangfu> 3. reboot milkymist
<xiangfu> 4. a lot of message output in VGA monitor. (cann't read, too fast)
<xiangfu> 5.milkymist one can not boot to 'control panel'
<xiangfu> 6. I poweroff the milkymist one. dis-connect the nanonote with milkymist
<xiangfu> 7. un-plug the milkymist power cable.
<aw_> actions between 2. ) and 3). you power cycle the M1 board or clicking 'Reboot' button on 'control panel'?
<xiangfu> 8. plug again. the D3 and D2 shine. I can not boot milkymist now
<xiangfu> between 2) and 3). clicking 'Reboot' inside Flickernoise
<aw_> hmm...good capture! That was my felt strange too.
<xiangfu> hi aw_ by un-plug the power cable for awhile . the milkymist one boot again.
<aw_> well...once you got no configuration condition. yes, exactly ...just waiting for a while ..then M1 is booted again.
<aw_> 'for a while' means that I quite don't know how long it should ...i even wait for days.
<wolfspraul> aw_: do you think with our diode+reset ic fix the problem xiangfu just described would not appear anymore?
<wolfspraul> xiangfu: don't wait for days :-) you can also try reflashing with jtag maybe?
<aw_> yes, the reset + diode should fix this problem..
<wolfspraul> Adam can try waiting for days because he has many boards, but that's a little extreme for a software guy who only has 1 board. :-)
<aw_> but I still have the thing strange thing likely I posted here two days ago.
<aw_> so I do really don't know why clicking 'Reboot' button will cause this?
<wolfspraul> aw_: yes but I think that's a software bug, didn't see Sebastien's reponse though
<aw_> this is a symbol that shows we still may ran into it again..I'll also watch out this such case!
<kristianpaul> xiangfu: you can try "detect" command in urjtag and see if works (when the mm1 board dint powerup)
<xiangfu> kristianpaul: ok. will try that when next time cann't boot.
<kristianpaul> want a can't boot state
<kristianpaul> So far i just have the reboot bug
<wolfspraul> kristianpaul: do you see the reboot bug?
<wolfspraul> how common is it? is it easy to make it go away?
<wolfspraul> I suggest you don't try extensive testing around this bug, just stay away from it. We have damaged 2 boards trying to track this down with extensive/aggressive testing.
<wolfspraul> that may be a result of our testing, but still, no need for many people to dig around there at the same time.
<wolfspraul> I'm quite confident rc3 will be much more robust in boot/reboot behavior, on the hardware side.
<aw_> kristianpaul, yes..stay way from extensive testing.
<wolfspraul> then we need to see whether we can also make some improvements on the software side somewhere, but one by one.
<kristianpaul> wolfspraul: i stay away, i just cut powercycle board and still working okay
<kristianpaul> wolfspraul: also track not my interest, anway it hapen kinda ramdon ..
<wolfspraul> perfect
<wolfspraul> I think it should all be safe and stable, no worries.
<wolfspraul> just don't play with power experiments, we are too remote to recover if several people around the world break their boards.
<wolfspraul> it may take us several weeks/months to get everybody back up and running :-)
<wolfspraul> don't want to waste time
<wolfspraul> we have a really nice improvement coming in rc3 in this area, I think
<wolfspraul> and the rc2 people know they are true pioneers :-)
<kristianpaul> just play with fpga for now
<lekernel> aw_: what is the "reboot" bug you are talking about?
<lekernel> xiangfu: the "LED shining" bug should be fixed in rc3, for now just power cycle until it's gone
<lekernel> xiangfu: what are the last messages that get displayed on the VGA monitor when you get the reboot bug?
<lekernel> btw, they get also sent to the serial port, so you can connect a computer to log everything
<aw_> lekernel, from xiangfu's asking, his posts on step1 ~ 8 , i was thought that it's just no configuration only.
<lekernel> it's only 6-8 that are related to the configuration problem
<aw_> but from his steps 3 ~ 5, it's he clicked "Reboot" button from 'control panel'.
<lekernel> if there are messages on the VGA monitor, the fpga obviously was configured
<aw_> yes, i know
<aw_> i don't know how it could happen from clicking "Reboot" only..then he can not enter control panel.
<wolfspraul> lekernel: did you see my answer regarding secam-525?
<lekernel> yes
<wolfspraul> does the secam problem persist through power cycles, or did you have it only once?
<lekernel> and the problem persists
<lekernel> it's permanently broken now
<wolfspraul> hmm.
<wolfspraul> sounds like we need to track this down and fix it before rc3 then.
<lekernel> yup, otoh permanent problems are easier to track down
<wolfspraul> ok what do you plan to do now?
<wolfspraul> (regarding secam-525)
<lekernel> check solders, clock, and video chip reset sequence
<wolfspraul> ok
<lekernel> replace the video chip
<lekernel> I hope I have spares... checking
<lekernel> hrm, no...used them for rc1 tests... i'll order some
<lekernel> correction: I have one left :)
<lekernel> good
<lekernel> damn this video input circuit is such a problem magnet...
<lekernel> wrong bits connected, reworked chips burning out, broken crystals, and now that... :/
<wolfspraul> no problem. EVERY feature is a risk, source of pain, etc.
<wolfspraul> Milkymist One is a really complex board, I think I knew beforehand what we got ourselves into :-)
<lekernel> btw, i'd be up for some directed ESD testing on that part
<wolfspraul> at least on my side I'm all patient, one by one we fix the issues we find
<lekernel> while it sample some video, zap it with the ESD gun, send radio interference, etc.
<lekernel> when are the wpan boards ready for EMC tests? perhaps I could do both at the same time
<wolfspraul> let's first focus on the particular secam-525 now, that sounds like a high-priority problem
<wolfspraul> I'm not sure changing the video chip right away is the best approach. What if it works then? what do we learn?
<lekernel> no, not right away
<wolfspraul> did you do anything noteworthy as the last step before the secam-525 problem started?
<lekernel> no, I was just using it
<lekernel> then the picture from the video input looked like random data
<lekernel> one second after everything froze (probably the video chip sent garbage data that tickled some bugs in the video input core or software)
<lekernel> and after rebooting, it's always the secam525 problem
<wolfspraul> while using, ok. how did you 'use' it? just let it run?
<lekernel> yes
<lekernel> which I did for dozens of hours before without running into this issue, btw
<wolfspraul> aw_: do you have any ideas what Sebastien should check?
<wolfspraul> seems he has a list already, so we just wait and see...
<aw_> lekernel, do you have camera with output format can be set as NTSC then we see if decoder can detect it?
<aw_> wolfspraul, before rc3, we knew that I can not place a new bigger smd xtal on bottom side, i can imagine that those parallel bits wires goes through nearby the  new place which will be re-routed surrounding.
<aw_> the bottom side now is for placing metal shield instead.
<lekernel> no, I don't have anything NTSC
<lekernel> anyway the video in doesn't detect ANYTHING now
<lekernel> it's stuck to secam525 no matter what you do
<lekernel> and whether there's a signal or not
<aw_> okay
<wolfspraul> aw_: what is your point about crystal?
<wolfspraul> yes, new (stronger mechanical) crystal must be on top side
<aw_> wolfspraul, the parallel bits wires routed is always the sources of radiated wave. So have you let video decoder worked while you did a pre-scan and test in German(llaboratory)?
<wolfspraul> probably not
<wolfspraul> at least we didn't have a video camera inserted during the tests, so unless the video decoder is always working (on) anyway, then no
<lekernel> the video decoder chip should keep transmitting a blue picture, even without input
<aw_> wolfspraul, that could be worse case if do it. Not sure, because the decoded pixel works is a pretty high frequency running unless s/w ported already.
<lekernel> that being said, I wouldn't be against some further EMC tests on it
<lekernel> aw_: the decoder chip was supposed to be running during the tests we did
<aw_> lekernel, good.
<lekernel> but we didn't check it kept performing OK
<wolfspraul> aw_: do you think this could be related to the secam detection problem? are you saying we should change/improve the wire routing in rc3?
<aw_> yeah.
<lekernel> the pixel port is unrelated to the secam thing
<lekernel> the secam detection comes from the i2c bus, not the pixel port
<wolfspraul> I'm a little surprised that lekernel's secam problem persists now.
<aw_> so wolfspraul , so you think that I also need to check or find laboratory to test.
<wolfspraul> roughly guessing if we are lucky it's just the crystal, which we plan to make stronger (hopefully) anyway
<lekernel> the only possibility is involving EM radiation from the pixel port messing up the video chip - but that would be surprising imo
<wolfspraul> aw_: no lab, for what purpose?
<wolfspraul> let's first see what lekernel finds. maybe he replaces the crystal and it's back to normal.
<aw_> lekernel, no, i was not saying things related to secam problem, i just thought that if we enabled that pixels worked when we did EMC test. ;-)
<wolfspraul> in which case we can probably just proceed with rc3 as planned.
<lekernel> I already replaced the crystal once on this board, but left it upwards
<wolfspraul> aw_: let's not throw unconnected things together now.
<wolfspraul> I want to focus on the secam problem now.
<lekernel> I did not handle it roughly, though, and the board was put in a case soon enough
<aw_> wolfspraul, ot's okay on focusing on secam.
<wolfspraul> lekernel: sure, I am just speculating. I'm just saying if replacing the crystal fixes your secam problem, then we will probably continue with rc3 exactly as planned.
<aw_> i just had have many fixes on video pixels work layouts while EMC test failed
<wolfspraul> but if not, then maybe we have another root cause to track down. or if we are worried that we don't understand the crystal failures, maybe we need to investigate the cause of that?
<wolfspraul> aw_: please explain that more clearly.
<lekernel> usually, crystals heat before breaking down electrically
<wolfspraul> you say you worked on products before, and they showed certain bugs, under EMC testing?
<lekernel> and this one doesn't (I don't even think the video chip oscillator as enough power to break down a crystal)
<wolfspraul> lekernel did not do any EMC testing, he just ran his board, when after hours suddenly he video-in started failing.
<aw_> wolfspraul, yes, i ran into EMC test failed on those bits wiring routes. Unfortunately current wires on the top side now. So if having a pre-teset for EMC is good. I know this is irrelevant to secam.
<Fallenou> that's fucking insane
<Fallenou> just because the newlib maintainer has the honesty to say "i'm not sure if I have all the licenses listed for my code"
<Fallenou> fedora says "I can't be sure newlib is free software"
<Fallenou> ?!
<Fallenou> I guess for big projects with a lot of contributors it's the same
<roh> yes and no. there is a reason most projects only let you commit code with trace.
<roh> as linux does.
<wolfspraul> Fallenou: I can understand Fedora's position.
<wolfspraul> the problem with the answer of the newlib maintainer is that it will be torn apart in a legal conflict.
<wolfspraul> it's just unacceptable, the system doesn't work like this.
<wolfspraul> then he can also be super-honest and say "I don't give a damn about licenses, I'm a pirate"
<wolfspraul> he may still get some sympathy points, but his legal standing is in the bin
<wolfspraul> so what he needs to do, if he cares about legal strength, is to work on those license unclarities. try to track down authors for code chunks that are copyrightable, remove code with unclear origins, etc.
<wolfspraul> or give up on the legal stuff, and become a happy pirate. but stay out of courtrooms then :-)
<kristianpaul> lekernel: (video decoder chip should keep transmitting a blue picture) oh what? hmm in my control panel i just remenber black screen.. oh dear i need confirm that..
<Fallenou> ok :)
<Fallenou> wolfspraul: cc-by-sa forbids commercial use of the work
<Fallenou> it's restrictive isn't it ?
<Fallenou> isn't it better to put the sides under BSD or GPL ?
<Fallenou> slides*
<wolfspraul> Fallenou: absolutely not. Unfortunately the CC people have created a lot of damage in their lust of world domination, so many people associate anything cc with non-commercial.
<wolfspraul> we cannot fix that unless a completely new alternative to cc emerges
<wolfspraul> but unless there is a -nc (non-commercial) in the line somewhere, commercial use is definitely allowed.
<wolfspraul> so cc-by, cc-by-sa - both fine
<Fallenou> oh
<wolfspraul> allows commercial use, allows modified derivatives
<Fallenou> I ve read otherwise on their own web site
<wolfspraul> yes but I understand your feedback, I think it's horrible too
<wolfspraul> no, that must be a misunderstanding
<wolfspraul> they are good politicians, they try to make everybody feel at home :-)
<wolfspraul> at times that makes their message a bit confusing
<Fallenou> o sorry
<Fallenou> as you said
<wolfspraul> cc-by-sa allows commercial use, definitely
<Fallenou> ive read by-nc-sa
<wolfspraul> and it allows derivatives
<Fallenou> my bad
<wolfspraul> yes correct
<wolfspraul> stay away from -nc, -nd
<wolfspraul> the slides under cc-by should be just fine
<wolfspraul> or public domain :-)
<wolfspraul> if you want copyleft add a -sa
<Fallenou> is it OK for you ?
<Fallenou> oops a typo in sebastien s name
<Fallenou> last slide
<wolfspraul> wow perfect
<wolfspraul> license, attribution, source url
<wolfspraul> :-)
<Fallenou> :)
<wolfspraul> can't be any better, I think
<Fallenou> ok great
<Fallenou> thanks for your help
<Fallenou> typo fixed
<wolfspraul> thanks for your attention to detail
<wolfspraul> now we hope you have a large and open minded audience :-)
<Fallenou> yes I hope :)
<wolfspraul> or you had already?
<Fallenou> nop
<Fallenou> it's in 2h30
<wolfspraul> nice
<wolfspraul> I will be sleeping soundly then :-)
<wolfspraul> good luck!
<Fallenou> hehe gn8
<Fallenou> thanks
<wolfspraul> one thing milkymist needs a lot are good story tellers
<wolfspraul> because there are many ways to tell this story, but it still needs to be done
<Fallenou> i'll try to make them dream
<Fallenou> should be easy, they like ardware and open source  hardware
<Fallenou> and this is a good project
<Fallenou> I hope some of them will come on IRC and ask questions
<wolfspraul> good point, maybe the last slide should have a URL to the webchat of this channel
<Fallenou> humm I will put #milkymist on Freenode
<Fallenou> they should be able to come
<wolfspraul> sure, that's good too
<wolfspraul> maybe also the mailing list? but if someone just has a quick question, #milkymist on Freenode should be listed as a way to get it answered
<wolfspraul> the webchat url is a bit long http://webchat.freenode.net/?randomnick=1&channels=milkymist
<Fallenou> I think a web url is not necessary
<Fallenou> hackers are used to come on Freenode
<wolfspraul> you could leave out the randomnick
<wolfspraul> you never know who is there (well I don't know)
<wolfspraul> so as a rule of thumb, it's not a bad idea to dumb down ways to communicate
<wolfspraul> because otherwise you will never even find out whether there were others that couldn't reach you, for whatever reason
<Fallenou> a big fat url is really ugly for te slides
<Fallenou> the*
<wolfspraul> remember that someone who just sees this passing by will only give the project a very short time maybe
<wolfspraul> at least that's how I am, if I'm honest
<wolfspraul> imagine you read an article somewhere, about something interesting, but you hear it for the first time
<roh> cosmetic foobar. hide it behind some shortener if you like.. i dont care
<wolfspraul> you click on some lick, quickly want to find an FAQ or About page, right?
<wolfspraul> if you cannot find it - forget it :-)
<Fallenou> yes sure
<wolfspraul> that's because you cannot know in advance whether something later turns out to capture your interest for years or not
<wolfspraul> so everybody has a rather short cut-off time for unknown/new things, otherwise you are too slow looking at new things
<wolfspraul> when I see the same new thing popping up a second time in another place, then I typically give it some more time to study
<wolfspraul> anyway, good idea about irc channel, just list it there...
<wolfspraul> in whatever way you think works :-)
<Fallenou> I will cut the apple in two
<Fallenou> I will put a shortened link
<testnick_> test
<kristianpaul> lekernel: (video decoder chip should keep transmitting a blue picture) oh what? hmm in my control panel i just remenber black screen for video.. oh dear i need confirm that..
<lekernel> well, that's what the adv7181 datasheet says
<lekernel> but tbh I have not tested that a lot
<kristianpaul> ah ok
<kristianpaul> will do some tests son with ccd/cmos video cameras
<kristianpaul> s/son/soon
<rejon> lekernel gsoc app completely sent btw
<lekernel> cool, thanks
<kristianpaul> lekernel: what's the max data trasnfer rate for the usb core considering that is a slave?
<lekernel> I guess you mean by reading from lm32... I have no idea, benchmark it
<lekernel> it's certainly higher than the 12MBps
<lekernel> USB limit
<kristianpaul> oh nice
<mwalle> omg gdb sources are such a mess
<lekernel> is not surprised
<mwalle> has just found out that gdb supports some kind of monitor roms
<mwalle> some cli based ones ;)
<mwalle> unfortunately gdb supports only predefined break in characters
<mwalle> ctrl+c, break and break+g
<lekernel> having only one or two characters for break is probably a bad idea
<lekernel> we may transfer binary data through the UART for booting
<mwalle> exactly
<lekernel> so we'd need at least 4 characters i'd say, to be safe
<lekernel> maybe even 8
<mwalle> but that means we need to patch gdb
<lekernel> yeah, but we can certainly get that patch merged... shouldn't be much of an issue, unless the code is so messy that adding a break sequence is hell
<mwalle> should be a small patch
<mwalle> but what happens with the received characters?
<mwalle> everytime you break in the application will receive some garbage
<wolfspraul> lekernel: any news on the secam problem?
<lekernel> no, had no time to look at it today
<mwalle> what do you think about disabling the breakin for serialboot?
<mwalle> thats the only time you transfer binary data isnt it?
<lekernel> hmm
<lekernel> yes
<lekernel> that's one solution
<lekernel> the other is to make the UART hold the data until the break sequence is complete or it receives a character that is not part of it (in this case it releases everything to lm32)
<mwalle> at uart speed?
<wolfspraul> ok, I suggest you look at it soon, because depending on the outcome, it could be on the critical path for rc3.
<lekernel> or, we can modify the boot protocol so that the break characters are escaped
<wolfspraul> I will think what I can do on my side in parallel.
<lekernel> wolfspraul: sure don't worry
<lekernel> i'm on it
<wolfspraul> sure. I think about what I can do too, but keep me posted.
<mwalle> i like (1) and (3) :)
<mwalle> (3) more than (1)
<mwalle> so gn8, tomorrow is graduation ceremony
<lekernel> same here, let's go for (3)
<lekernel> gn8
<kristianpaul> n8
<kristianpaul> hates GMT -5
<wolfspraul> Fallenou: how was the talk?
<lekernel> wolfspraul: actually, the video chip seems totally destroyed and no longer responds to anything
<lekernel> maybe it's just the crystal
<lekernel> with the test program I get
<lekernel> Decoder probe:
<lekernel> VIN: I2C bus initialized
<lekernel> Unexpected register value: 0xff                                          [  FAILED  ]
<lekernel> I try replacing the crystal now
<lekernel> hmm, no still doesn't work with new crystal
<lekernel> btw we'll need a ground point to connect scope probes to on rc3
<lekernel> or maybe even several (better for high frequency signals)
<kristianpaul> I think adam comment about some tests point for rc3somwhere..
<lekernel> funny, I get higher amplitude oscillations of the crystal on the non working board
<Fallenou> hi