<manuko> I'm interested on jtag for mico32
<kristianpaul> hi
<kristianpaul> xiangfu: hi !!
<kristianpaul> okay lest try something here
<kristianpaul> missi mm1 early bios fast booting..
<kristianpaul> waoahshsa
<kristianpaul> amaazinn!!
<kristianpaul> ccd + mm1
<kristianpaul> xiangfu: will be cool be able to get snanshots from the vide in
<kristianpaul> or at least from the previw that is visualized in the video input settings
<xiangfu> kristianpaul: yes.
<kristianpaul> he, just telling :-)
<kristianpaul> ha, copy and paste could be usefull in the patch editor too
<lekernel> kristianpaul: it works... ctrl c/v
<kristianpaul> ctrl?
<kristianpaul> lekernel: morning ! :-)
<Fallenou> morning
<lekernel> morning
<Fallenou> kristianpaul: I don't understand quite well what's on your screen on your video
<Fallenou> is this your keyboard that your filming and feeding into the video input ?
<kristianpaul> Fallenou: heh
<kristianpaul> was a test but seems my camera is not good fore details
<kristianpaul> Fallenou: but yes it is :-)
<Fallenou> oh ok !
<Fallenou> I recognized something looking like a keyboard but wasn't sure
<Fallenou> since it's distorted by M1 (which is normal I would say it does it's job :p)
<Fallenou> well nice we need more video !
<Fallenou> There is no video of the current version of Milkymist / Flickernoise
<lekernel> wolfspraul: do you know any good manufacturer of ac97 codecs?
<wolfspraul> no
<Fallenou> lekernel: maybe have a look on a PC sound card :o
<kristianpaul> Fallenou: more video, sure, !! but first i have some todos with you and they list
<wolfspraul> I'm not sure changing the codec is the right solution for the line-out noise anyway. don't you think we should track down the real issue first?
<Fallenou> kristianpaul: yes sure :)
<kristianpaul> Fallenou: btw i already forked lekernel milkymist repo
<Fallenou> kristianpaul: good !! :)
<kristianpaul> Fallenou: i hope upload sistensis log today..
<Fallenou> excellent
<Fallenou> thank you
<wolfspraul> kristianpaul: why is the camera not good on details? what details? it should be pretty good, especially considering that in that video, you can hardly see anything :-)
<lekernel> wolfspraul: the ml401 has the same codec and is noticeably noisy too. so...
<kristianpaul> wolfspraul: my camera not the ccd one
<kristianpaul> it have details
<kristianpaul> really nice ones i think
<lekernel> wolfspraul: also, we should be able to find a pin-compatible chip. just drop-in replacement, no pcb layout change
<lekernel> so it's an easy test and fix
<wolfspraul> sure, if that is possible let's do it
<wolfspraul> will you reply to the guy on the list?
<lekernel> i'll try it on a rc1 board...
<lekernel> yes
<Fallenou> yeah maybe just source different ac 97 pinout compatible and test them since it's not that much work
<wolfspraul> pcb layout change is no problem, unless the change starts to spread into other components etc.
<kristianpaul> ok, but why and what is problem is supposed to solve the new chip?
<wolfspraul> if it's just a little different pad size/location, it shouldn't matter because we are doing rc3 anyway
<kristianpaul> are we talking about audio-out noise?
<kristianpaul> or other no so know problem?
<lekernel> I could order samples from NS, but I'd like to try a different manufacturer :)
<lekernel> kristianpaul: yes, audio out noise
<lekernel> it's a minor issue, but everyone's complaining about that
<kristianpaul> lekernel: it was present on the ml401 as well?
<lekernel> yes
<wolfspraul> it's not minor. once the feature is there it should work.
<kristianpaul> agree :-)
<wolfspraul> and plus - connecting a headphone, even just for fun, is something a lot of people will try
<wolfspraul> then they hear a lot of noise, and they think 'what a crap'
<wolfspraul> it's that easy
<lekernel> yeah, I see
<lekernel> that's why i'll look a bit more into that
<kristianpaul> you asked xilinx with the ml401 a posible root case?
<wolfspraul> if we leave it as is on rc3 (which I can live with), then I will start saying everywhere that line-out is basically not working. "forget that it exists"
<wolfspraul> that's better than leaving it there and letting people discover the noise
<wolfspraul> it's called 'expectation management'
<wolfspraul> we can definitely do that - scratch line-out on the marketing side ("does not exist")
<lekernel> wolfspraul: any sourcing experience from VIA?
<kristianpaul> hmm via. :-)
<wolfspraul> no
<lekernel> yeah, I know, we can also simply remove the jack
<wolfspraul> then we would have a hole in the case, unless we fix that as well (and I have a few cases in stock so it's not ideal)
<wolfspraul> there is this british company, forgot the name
<lekernel> wolfson?
<lekernel> I checked them, it seems they make QFN chips only
<lekernel> i'll try to find a TQFP one, will be much easier to test
<wolfspraul> yes, wolfson
<wolfspraul> lekernel: do you think just changing the codec will fix the noise?
<wolfspraul> or is this a shot in the dark?
<kristianpaul> shoot shoot ! ;-)
<lekernel> there's a good chance i will
<lekernel> it will
<lekernel> and it's an easy test
<kristianpaul> thats true
<wolfspraul> why is there a good chance?
<wolfspraul> the chip we have now is so bad? how come it is selling at all then?
<wolfspraul> makes no sense to me
<wolfspraul> I would rather think we are doing something on the board that is very unfriendly to a line-out signal
<wolfspraul> something electrically outside the codec
<wolfspraul> that's a long shot too, but I just have no way to comprehend WHY changing the codec might help
<wolfspraul> but who knows, I'm always in favor of trying...
<wolfspraul> I would love to fix line-out, we need a product that works really well in all details. and the noise is massive.
<wolfspraul> basically we have no working line-out on m1
<wolfspraul> which I can live with if needed, and will explain it like that
<wolfspraul> it's a video machine :-) who wants line-out?
<wolfspraul> lekernel: if you have a few suggestions for codecs, Adam can get them and try as well, so we can speed up
<lekernel> wolfspraul: you can look at the schematics and PCB design around the codec, but I did that already and found nothing unusual
<lekernel> that being said, bugs are often found by someone who did not draw the schematics :)
<kristianpaul> wolfspraul: btw did you finally test vide-in on your mm1?
<wolfspraul> no time yet. every day I have work for 100 hours, pretty bad.
<wolfspraul> if you say it works for you now, I will postpone my test for now.
<wolfspraul> kristianpaul: with your video you want to say "it does work", right?
<wolfspraul> lekernel: I definitely cannot see anything in the schematics, unfortunately we pissed off Joerg who is quite good on audio issues.
<lekernel> hm, is "we" means only me, or was there other problems as well?
<wolfspraul> no need to point fingers, I will try to get him back. It's a joint failure, but that includes him as well. What can I do, we try to collaborate...
<wolfspraul> lekernel: for line-out noise, have you tried to see where the noise originates, i.e. whether it comes out of the codec already? is there anything in between the codec and the jack?
<lekernel> just passive components
<lekernel> wolfspraul: cc me if you write to Joerg. since I contributed to pissing him off... :/
<lekernel> found one eventually
<lekernel> i'll check compatibility a bit more and order samples
<lekernel> hmm... it definitely seems to be a product made for drop-in replacement of competitor's codecs :)
<lekernel> cool
<Fallenou> maybe one day they will copyright pinouts to avoid concurrency with drop-ip replacement :p
<lekernel> the whole point of the ac97 standard is to allow that replacement
<lekernel> pc market...
<lekernel> it's the same with sdram for example
<Fallenou> ok
<lekernel> though the sdram jedec standard is usually more closely respected than the ac97 one :)
<lekernel> ac97 is a bit messy
<roh> it is?
<roh> looked quite simple and sane (for some industry standard)
<roh> isnt it just a loooong shift register with a data and a command chain and named registers in command mode?
<lekernel> the control signals are usually OK
<lekernel> but sometimes there are subtleties on things like the power supply voltages, pinout, and required external components
<lekernel> that wolfson codec supports 3.3 to 5V on all supply pins and requires very little external parts
<roh> pinout is also defined by ac97 and afaik even upgrade compatible
<roh> wolfson is quite cool.
<roh> also nice people with a clue about linux
<lekernel> yup. but some manufacturers like to hook up proprietary extensions to NC pins
<roh> lekernel: check different versions of ac97. some add features and revise pinouts
<roh> e.g. there is a nc where newer versions have the spdif out
<lekernel> yeah, but sometimes they use them for things like connecting capacitors for some onchip audio improvement circuit to work
<lekernel> I don't think that's in the standard... is it?
<roh> dunno. but ac97 isnt something loosely speced or so
<lekernel> roh: ok, the wolfson codec requires decoupling of pin 32, but not the current one
<lekernel> you see, there are always problems
<lekernel> and an additional cap on pin 33
<lekernel> it's always small details, but pesky ones
<lekernel> anyway, I think we can manage them, and I'll order samples now
<roh> which ac97version is the board for?
<lekernel> the current chip is 2.1
<roh> uh. i see.. thats quite... well.. outdated..
<lekernel> and the wolfson codec too
<lekernel> ah, also that wolfson chip can have SPDIF
<roh> it is.. i see.. then they enforced physical compatibility in later versions. i mostly used the 2.3 spec for reading up
<roh> spdif is speced in 2.3
<roh> eh 2.2
<lekernel> ah, funny
<roh> http://en.wikipedia.org/wiki/AC'97 has a nice list of what feats came when
<lekernel> anyway, I think we'll route the required pins for spdif to the internal audio header, as a totally unsupported easter egg
<roh> that would be cool
<roh> its only one pin i think
<roh> the last one or so
<lekernel> there's also a "spdif enable" pin that needs to be pulled high
<roh> thats not in the spec i read.. must be vendor specific
<lekernel> i'll connect that one to the header too
<lekernel> yeah, told you
<lekernel> there are tons of vendor specific extensions to ac97
<roh> lekernel: maybe update to 2.3 standard
<roh> i think its more specific and should make you have less work
<roh> in using different chips atleast
<lekernel> so far it's just 2 more capacitors
<lekernel> are 2.3 chips compatible with 2.1 ones?
<roh> i think so. mostly
<roh> the idea is the same, i think some pins changed which were nc before (and vendors did their proprietary extensions on)
<lekernel> any chip you could recommend?
<roh> uh.. not from my head. wolfson is a good start. ask them for a recommendation
<roh> but if i read the stuff right, you should have even sw compat. with the lastest revision.
<roh> i think they only did new ones to root out all vendor special cases
<roh> the whole idea was to make it unneccessary to design a new board just to use another vendors codec
<roh> for the successor hda there isnt even a sw driver for different chips anymore. they need to be fully sw compatible
<lekernel> yeah... but there wasn't hda on fpga boards when I designed MM SoC
<roh> or? eh. no.. sorry.. its only the hw/sw interface.. still got a codec driver
<roh> no problem. ac97 seems still to be used quite widely
<roh> analog devices also makes nice sounding chips (quality)
<roh> and somewhere on the low end there is always realtek
<lekernel> it seems AD is phasing out their ac97 codecs :(
<roh> uuh?
<roh> somebody bought them?
<roh> there is still AKM for the quality segment
<lekernel> I don't know... but all the AD ac97 references I searched for were "discontinued" with no replacement information
<wolfspraul> that's interesting, would like to hear the real story from an AD guy, will keep in mind...
<roh> maybe we need to find out what all the long-term users use
<roh> there is embedded hw with a 10 year gurantee for lines of devices
<Fallenou> just ran into compiler problem for pic32
<Fallenou> I am using a packed structure, so some of the fields are unaligned
<Fallenou> am using a char * to walk through the struct
<Fallenou> and then in the middle of it i switch to long int *
<Fallenou> but unfortunately the switch is not on an aligned address
<Fallenou> the compiler does not handle that case
<lekernel> load the switch value to a temporary variable then
<lekernel> or use an AVR :)
<Fallenou> i am sending values through spi
<larsc> is the compiler supposed to handle such cases?
<Fallenou> larsc: I guess since it does not produce warning or error
<Fallenou> and since it generates code that generates an exception
<Fallenou> I am sending a struct through spi, sending first the length%4 values, in "byte width" burst, and then all the remaining part with 4-bytes-size burst
<Fallenou> I will try the other way
<Fallenou> first sending everything in 4-bytes-size burst, and the remaining 3 bytes afterward :)
<Fallenou> works \o/
<kristianpaul> wolfspraul: right
<wolfspraul> right? (lost context)
<wolfspraul> ah ok "it does work"
<wolfspraul> great
<kristianpaul> yeah, video-in context
<wolfspraul> kristianpaul: why can I not tell any 'video-in' effect in your video?
<wolfspraul> is there a way to display a static image in some part of the screen?
<wolfspraul> I think for a casual viewer of that video, they may not even understand/see where the video-in part is :-)
<kristianpaul> wolfspraul: he,sure there is a control panel for video-in
<wolfspraul> as you can tell I never tried, so far
<wolfspraul> I have the same cable problem as you now, need to get an adapter first
<kristianpaul> i got a cable
<kristianpaul> was easier
<wolfspraul> kristianpaul: how much did you pay for the cable? how long is it?
<kristianpaul> wolfspraul: i dint paid, i just borrowed, long... like 1m i think
<wolfspraul> ok got it
<kristianpaul> lekernel: the other video inputs can be enabled? _if_, is it a software/hardware(hdl) work needed to make it work?
<lekernel> it's not other video inputs, it's for component video, and I don't know - never tested
<lekernel> the adv7181 datasheet should give you some hints
<kristianpaul> ahh
<lekernel> maybe they could also be used as other video sources to select from
<lekernel> if you manage to get that to work, documentation or code would be much appreciated :)
<kristianpaul> ok, yeah, i was about to read the datasheet, just doing quick survey before :-)
<kristianpaul> lekernel: btw for the timing constrait check, is the sys_clk the only signal to care about i guess?
<lekernel> no, it's not
<lekernel> you should check all the signals in the clock report
<lekernel> s/clock/timing
<kristianpaul> ok, yeah is logic procecure
<wolfspraul> kristianpaul: maybe you can find out whether it is possible to connect 3 different composite cameras :-)
<wolfspraul> (not that I think it's important now, but good to know if it's theoretically possible or not)
<kristianpaul> like the theoretically part
<kristianpaul> lekernel: For your reply seems this guy asumed out noise as manufacture hardware problem ;-)
<mwalle> ho
<kristianpaul> hi
<mwalle> lekernel: polling a IP bit should work without enabling the corresponding bit in IM, shouldnt it?
<lekernel> mwalle: yes, it should work
<lekernel> and I did that actually and it worked
<mwalle> yeah it works, either i've used an outdated rom file or i finally trigger that RAM8 not initialized bug