<Alarm> I want to install qemu with Milkymist using the wiki: 'http://www.milkymist.org/wiki/index.php?title=Using_QEMU';
<Alarm> I do not understand or I have to apply: 'git revert bf5547f5365c1bfeba9d5c3e87653b9803a875a5'?
<larsc> hm?
<larsc> after cloning the repo run above command
<Alarm> I do this first: 'git clone git: / / git.qemu.org / qemu.git' ?
<larsc> yes
<Alarm> s that the qemu git clone should be in the same directory as / opt/rtems-4.11?
<larsc> doesn't matter
<Alarm> ok
<Alarm> vim opens when I apply the 'git revert'?
<larsc> just safe the file and close it agaion
<larsc> :wq
<Alarm> I did the make after the '. / Configure
<Alarm> I get an error 'block / raw-posix.c: 35:28: fatal error: IOKit / IOKitLib.h: No such file or directory
<larsc> IOKit sounds like  MacOS X library
<wpwrak> wolfspraul: what kind of package do you want for the gates ? here are some choices:
<wpwrak> lekernel: (having to search the web for codecs) have you gone over to the evil side (windows) ? :)
<larsc> lekernel: what distribution are you using now? fedora?
<lekernel> I was running Linux before computers were seriously able to play video
<lekernel> yes, fedora
<wpwrak> lekernel: at least that's the only place where i know such adventures from (once had a new laptop that came with this junk preinstalled and wanted to try to play some video. i could not have imagined in my wildest dreams just how awful things were in that particular hell ...)
<lekernel> another (and more serious) annoyance on this distro is pulseaudio which has more bugs than a rainforest, and on which most of the GUI environments depend on, so you can't uninstall it cleanly
<wpwrak> tries to remember the first videos ... i don't think linux has been around back then ;-)
<larsc> i'm using debian and i never had to manually download and install codecs
<lekernel> even to play MP3, WMA, encrypted DVDs, etc.?
<wolfspraul> wpwrak: the most commond smd type? can be small and no-lead etc. but most common and cheapest is what I'd pick.
<wpwrak> wolfspraul: they're all kinda common ;-) well, let's pick one that both TI and NXP have then
<lekernel> my experience with Debian is I had to install extra stuff to play proprietary/patented/DRM'd formats
<larsc> at least mp3 works out of the box
<wolfspraul> wpwrak: the cheapest :-)
<larsc> i'm not sure if i even have an wma files
<wpwrak> mplayer on ubuntu handles pretty much everything i throw at it
<lekernel> interesting...
<Alarm> larsc: is it necessary to install MacOS X libraries?
<larsc> Alarm: do you use MacOS X?
<Alarm> no
<larsc> well, then not ;)
<larsc> check your config for some reason qemu seems to to think you have it
<wpwrak> wolfspraul: (no-lead) contacts not accessible from the side is okay ?
<wolfspraul> I can only answer based on my knowledge, so I say 'cheapest'.
<wolfspraul> yes we need to integrate, but in the end I'd still just go with the cheapest
<wolfspraul> unless we are so space constrained that even if no-lead is more expensive I'd take that
<wpwrak> is about 3.2 x 2.5 mm occupied space for one gate okay ? (you'll need two of them)
<wolfspraul> that's a lot ;-)
<wpwrak> see :)
<wolfspraul> yes but let's look at price first. I could imagine that the most common and relatively small no-lead version is also the cheapest.
<wpwrak> let's see what a search for cheapest turns up ...
<wpwrak> 6-XFDFN hmm ...
<wpwrak> SOT-5 is only about 10% more expensive than 6-XFDFN
<Alarm> larsc: ok I understand. I typed the ". / Configure 'for MacOS X
<wolfspraul> wpwrak: I think no-lead and bga are uncommon and expensive. guess only used when people are space constrained.
<wolfspraul> I don't know where you look, I look at digikey and the SOT-5 come up as cheapest
<wolfspraul> 10-13 cents (in quantity)
<wolfspraul> whereas no-lead and bga is more like 40-50 cents
<wolfspraul> ah yes, 6-XFDFN is also there, 17 cents
<wolfspraul> but 6-XFDFN is smaller, right? so maybe a good choice?
<wpwrak> wolfspraul: DSF/DRY would be suitable. they're no-lead, no lateral contacts, and are available from TI and NXP. DSF aka SOT886 aka MO-252 is the cheapest package at TI. but not stocked at digi-key from NXP. DRY aka SOT891 aka MO-287-UFAD would be.
<wpwrak> thre
<wpwrak> let's try this again ...
<wolfspraul> ok :-) I don't know all these package names.
<wpwrak> there's a hektazillion of different packages called XSON6 , so that designator doesn't help :)
<wolfspraul> I don't think manual access is important. Less space is always nice, but I have no hard number how valuable in our case. 50% more is always OK for less space.
<wpwrak> heh :)
<wolfspraul> if it's 3 times more for less space, maybe we first determine how space constrained we actually are
<wpwrak> it's about 5% from DSF to DRY
<wolfspraul> anything < 50% difference I would pick the smallest
<wolfspraul> even < 100% difference probably
<wpwrak> oh, sorry. 10.8% !
<wolfspraul> if something is not stocked at digikey, that's a bad indicator
<wolfspraul> if whatever is not stocked there is 30% or 50% cheaper than whatever is stocked there, I would take another look. otherwise let's prefer what is stocked on digikey (maybe I would extend that to mouse & farnell as well)
<wolfspraul> just my thinking...
<wpwrak> i'm lazy and try not to have to look elsewhere ;-)
<wolfspraul> sure
<wolfspraul> I think stocked at digikey is a good indicator, which I would only override if whatever is not stocked there is substantially cheaper
<wolfspraul> 30-50%
<wpwrak> seems we have a winner then. SN74AUP1G08DRY aka 74AUP1G08GM
<wolfspraul> in which case I'm sure digikey would stock it :-)
<wolfspraul> yes, perfect
<wolfspraul> that's the one I found for 17 cents, only 4 cents more than the larger package (if I understand the various packages correctly)
<wpwrak> lemme complete my chart and post it on the qi-hw list ...
<wolfspraul> fantastic!
<wpwrak> cool. TI also have some 16BGA. called YFP, just like the 6BGA. and it creeped into the data sheet. that's what happens if you pick cryptic names ;-)
<wolfspraul> but I think the BGA variants are substantially more expensive, no?
<wolfspraul> more like 50 cents vs. 10-15 cents
<wolfspraul> well, I am lacking complete overview. the one you pointed our earlier looked good to me.
<wolfspraul> pointed out
<wpwrak> grmbl. the DRY isn't stocked either.
<wpwrak> recalculating ...
<wpwrak> we have a match on DCK/GW. that's a leaded ~1.6x2.5 (occupied area) package
<wpwrak> DRY can be ordered, with MOQ = 1, but 2 months lead time
<wpwrak> the corresponding NXP part (GM) is stocked
<wpwrak> got DSF/GF, it's the opposite. and MOQ is 5000 units, lead time 3 months :)
<wpwrak> why don't they simply display "GO AWAY !" ;-)
<wolfspraul> I look at the digikey overview page, the one that comes up after search. I always check "in stock" when searching. I can then see how many they have in stock, and for most of those types that's in the thousands. So there should be no issue with lead time at all.
<wolfspraul> so for example the 1G08GM you had earlier, looks good to me, no? http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=568-2552-1-ND
<wolfspraul> I have that one at 17 cents, the GW at 13 cents
<wpwrak> yes, the GM is good. my search criteria are: parts exists from TI, compatible part exists from NXP, TI part is stocked, NXP part is stocked.
<wpwrak> (stocked) all at digi-key
<wpwrak> the next level would be statistical availability at dk/farnell/mouser/arrow
<Alarm> qemu-system-lm32 -M milkymist -kernel flickernoise
<Alarm> oss: Could not initialize ADC
<Alarm> oss: Failed to open `/dev/dsp'
<Alarm> I have no folder 'dsp' in 'dev'?
<lekernel> this error is not critical
<Alarm> Failed to create voice `mm_ac97.out'
<Alarm> > flickernoise: No such file or directory
<Alarm> > qemu: could not load kernel 'flickernoise'
<larsc> that on the other hand is critical
<GitHub123> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/d7b64286d4a1d1a170ee9c5a290a71e3bf510181
<GitHub123> [milkymist/master] TMU prefetch: true dual port RAM module - Sebastien Bourdeauducq
<kristianpaul> (codecs) well, in debian i always install vlc and i'm almost done for video playing, besides, i dont use the dvd unit too much
<GitHub61> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/926a3bd0621cb4c090d55bd7fca47551a941bf58
<GitHub61> [milkymist/master] TMU prefetch: quad port RAM module - Sebastien Bourdeauducq
<wpwrak> beer supplies refilled :) now back to those gates ...
<larsc> sounds as if you kidnapped bill gates' family
<wpwrak> now there's an idea :)
<wpwrak> lekernel: for the reset logic, what's the minimum voltage at which the gates should be fully operational ? possile choices are: 0.8 V, 1.4 V, 1.65 V, 2 V
<lekernel> mh, i'm not totally sure
<lekernel> 0.8V is the safest of those choices ;)
<wpwrak> lekernel: coward ;-))
<lekernel> he, pick your battles
<lekernel> this problem has used more than enough time already
<wpwrak> 74AUP it is then
<wpwrak> yeah, true enough
<wpwrak> how do you want the gate at INIT_B - push/pull with series resistor or pull-up with open drain ?
<lekernel> pull-up with open drain is what is closest to the xilinx reference design
<wpwrak> okay. want a series resistor too ? in case INIT_B is driven high by the FPGA and the gate pulls down ? (not sure if this is likely to happen, considering that this means that PROGRAM_B_2 is low too)
<lekernel> in theory, INIT_B is never driven high by the FPGA
<lekernel> plus FPGA IOBs are fairly resistant to short circuits
<lekernel> we can't include such safeguards everywhere, if we did, we'd have to put resistors e.g. on the video input pixel bus
<wpwrak> perfect. one component less :)
<lekernel> then the PCB layout would become a mess and signal integrity would probably suffer as well
<wpwrak> yeah. just want to tune this to your paranoia level. every engineer has different preferences :)
<wpwrak> some may add overvoltage protection, a fuse, and a bead ;-)  (well, i'm exaggerating slightly here :)
<lekernel> beads turned out to be a bad idea, i'll 0-ohm them by default in my next design
<wpwrak> wasn't that just because you got a bad batch ?
<lekernel> we had a) voltage drop issues because of improper sourcing b) time wasted to tracking down video input instability problems
<lekernel> all attributed to beads
<lekernel> so, all beads 0 ohm, then go to the EMC lab with a bag of beads to install them after a problem is actually detected
<wpwrak> (video instability) you mean the ground issue ?
<lekernel> yes
<wpwrak> well, that bead had no reason to be there. it actually did its work perfectly - kept all the transients from crossing via the ground plane. so instead they went through the chip ;-)
<wpwrak> oh nice. there's a circuit symbol for open drain. very handy :) even better, both TI and NXP use it. toshiba apparently too. ST only reluctantly. fairchild don't seem to like it
<wpwrak> that's an almost suspiciously high level of agreement :)
<wpwrak> of course, it would have hurt just too much to also agree on which input of an AND gate they call A and which B ...
<lekernel> ?
<lekernel> it doesn't matter
<wpwrak> yes and no. it doesn't matter for the function of the AND gate, but if you want to use the name to refer to the net or the pin, you may get some confusion
<Alarm> ow to reflash the card with flterm?
<kristianpaul> flterm is not for reflash
<kristianpaul> urjtag it is
<kristianpaul> with help from fjmem of course
<lekernel_> Alarm, what do you want to reflash?
<Alarm> When I got the card I was told that the apps were not up to date. I guess it flickernoise?
<lekernel_> what version are you running atm?
<lekernel_> 0.1?
<lekernel_> or, if you have the jtag adapter, use urjtag and the same images
<Alarm> yes 0.1
<lekernel_> rhaa...
<lekernel_> I see. then yes, upgrade. it should fix many bugs too :)
<kristianpaul> you got jtag/serial adapter with your board?
<Alarm> yes
<kristianpaul> good
<kristianpaul> there is a script that make all process automatically
<Alarm> :)
<lekernel_> iirc that script uses the snapshots, no?
<kristianpaul> ah...
<lekernel_> better download the files from http://www.milkymist.org/updates/current/
<lekernel_> and run jtag -n reflash_all.batch
<kristianpaul> and be aware in fedora of issues with libusb..
<lekernel_> you'll also need fjmem.bit from http://www.milkymist.org/msd/
<lekernel_> phew. hopefully there will be no more 0.1 boards soon...
<kristianpaul> haha ;)
<kristianpaul> the'll pop up.. one by one
<wpwrak> could it be more straightforward to make upgrade via uSD the default process ? that should have a lot fewer "unusual" dependencies
<lekernel_> *SD is pesky, and the latest version supports automatic updates from the web
<wpwrak> lekernel_: "automatic" if you've set up all the things needed for it :) think of computer illiterate users
<kristianpaul> *SD is also no the best place to reach by hjand
<lekernel_> connect ethernet cable, then it does dhcp, and press a button?
<wpwrak> kristianpaul: i've heard that at least the mid-air collision between jtag board and uSD is gone now :)
<lekernel_> doesn't look too hard
<wpwrak> kristianpaul: i had a good laugh when i saw that conflict in rejon's M1 ;-)
<kristianpaul> wpwrak: (collition) yeah, i forgot
<wpwrak> lekernel_: hmm. i wonder whether those wifi cable modems still have ether ports or if they've saved that dollar
<lekernel_> adding wifi is out of the question anyway
<wpwrak> kristianpaul: the uSD holder in rejon's M1 was also a bit on the shitty side in terms of mechanical properties. but maybe the current ones are different
<kristianpaul> shitty all the way...
<wpwrak> lekernel_: that's what i mean - what do people do whose internet access is via wifi ?
<lekernel_> proprietary modules + USB peskiness + driver issues + regulatory problems = major time wastage
<wpwrak> lekernel_: again, i'm not suggesting you should add wifi support. just think of users who only have wifi. how common are they ?
<wpwrak> (only wifi) that is, without extra non-trivial setup
<lekernel_> I wrote a wifi stack and driver as a consultant years ago. months later, my apartment was filled with routers with which this or that WPA/WEP/whatever feature did not work. this will not happen again.
<kristianpaul> i guess very common, also look how apple aded non-pc required feature for coming ios5,
<wpwrak> lekernel_: ah, you had the inside view of wifi hell too. good ;-)
<kristianpaul> opencores.org is down?
<kristianpaul> bah... just the day i need to found a forum/ML to ask for wishbone support..
<kristianpaul> lekernel_: but after all p54 solved all wifi issues, or prism54 project was not related to what you just said?
<lekernel_> that's a different project
<lekernel_> also prism54 used the freebsd/linux wifi stack
<kristianpaul> ah, "Lightweight Wifi" :-)
<wpwrak> lekernel_: hmm. the gates in small packages are somewhat difficult to source (you can get them, but not as easily as i'd like to). you don't happen to by any chance to have a good amount of space there, say, for a pair of SOT-23 ? :)
<wpwrak> stock at farnell is amazing. 5 whole units of one of these chips. why do they even bother ? ;-)
<mwalle> larsc: lekernel_: is there a milkymist-uclibc repository?
<mwalle> larsc: where are you setting _dtb_start?
<kristianpaul> mwalle: i tought it was you having the uclibc repo?
<mwalle> kristianpaul: yeah, maybe theres some offical one :)
<mwalle> lekernel_: could you add a uclibc-lm32 and a elf2flt-lm32 repo to the mm github?
<kristianpaul> mwalle:  yes it should be on the organization page in github
<lekernel_> mwalle, done
<mwalle> lekernel_: thx
<lekernel_> wpwrak, sot23 should be fine imo
<lekernel_> the m1 pcb isn't that dense
<mwalle> larsc: ah ok generic stuff
<lekernel> Alarm, have you managed to upgrade your board?
<wpwrak> lekernel: oh, great. that will make things easier.
<Alarm> ot yet I have not finished loading the update.
<kristianpaul> lekernel: therically what will happen to milkymist conbus/lm32 if in a read cycle after a asserted cyc a slave reply with an extra ack?
<wpwrak> lekernel: which approach do you like better - left or right ? http://downloads.qi-hardware.com/people/werner/m1/rst/rst.ps
<wpwrak> lekernel: (and please ignore the twisted arc in the AND gate. thought that bug was dead already :-( )
<lekernel> i'm not sure the reset ic should drive program_b
<lekernel> r60 on the left is unnecessary
<lekernel> otherwise, I prefer the left one
<lekernel> but I hope those gates really would work for this purpose ...
<lekernel> connecting program_b makes some sense though - pulsing it low to clear the FPGA would also reset the flash
<wpwrak> hmm, you want a gate between reset and PROGRAM_B_2 pull-up as well ?
<lekernel> no, but for delaying configuration program_b has no effect
<wpwrak> ah, but you still need to reset, don't you ?
<lekernel> from my understanding it's a falling edge sensitive signal that clears an already configured fpga
<wpwrak> so the real reset happens elsewhere ?
<lekernel> the fpga configuration is delayed by holding init_b low when it's still unconfigured
<wpwrak> yes, but what initiates the configuration ?
<lekernel> I don't know why they have not combined those two signals into one ...
<lekernel> the FPGA, as soon as init_b goes high
<wpwrak> why make it simple if you can make it mysterious ? ;-)
<wpwrak> oh, so INIT_B is reset and delay ?
<lekernel> init_b is delay, program_b is reset
<lekernel> but the fpga does not need a reset pulse to start - applying voltage is sufficient
<lekernel> according to the xilinx datasheet, it begins configuration after all 3 supply voltages have reached minimum levels for 5 ms
<wpwrak> i see. and there's no other reset source around there either. so shall i disconnect PROGRAM_B_2 ?
<lekernel> as I said above - PROGRAM_B could be useful for manually clearing the fpga. in that case, resetting the flash at the same time makes sense.
<wpwrak> so that would be via TP36 ?
<lekernel> yes
<lekernel> also, it currently works with PROGRAM_B connected and I do not want to spend more time experimenting with this stuff
<wpwrak> ok. so i just remove R60 ? does C238 stay ?
<wpwrak> hehe ;-)
<kristianpaul> lekernel: no need to anwer, it crashes :-)
<lekernel> C238? no, it shouldn't stay
<wpwrak> perfect :)
<wpwrak> L48N is always defined then, after reset Z plus pull-up, later either that, or push or pull ?
<lekernel> what's L48N?
<wpwrak> btw, the one on the right side would have the advantage of needing only one type of gate
<lekernel> how much are those gates btw?
<wpwrak> 25-29 US-cents each if you buy 100
<GitHub9> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/70d9ba910c0637466a77050c4f90da77222ecb95
<GitHub9> [milkymist/master] TMU prefetch: cache data memory. Prefetch complete but untested. - Sebastien Bourdeauducq
<GitHub107> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/44b92e56a920987e5db594cf05d6ff05ac363c01
<GitHub107> [milkymist/master] TMU prefetch: fixed compilation errors - Sebastien Bourdeauducq
<GitHub77> [milkymist] sbourdeauducq pushed 3 new commits to master: https://github.com/milkymist/milkymist/compare/44b92e5...3ad5eb9
<GitHub77> [milkymist/master] TMU: check fdest cache valid bit - Sebastien Bourdeauducq
<GitHub77> [milkymist/master] TMU: check for address generator busy - Sebastien Bourdeauducq
<GitHub77> [milkymist/master] TMU prefetch: fix Xst warnings - Sebastien Bourdeauducq
<wpwrak> (l48n) that's the fpga pin that drives FLASH_RESET_N. full name is IO_L48N_M1DQ9_1. i abbreviated it to IO_L48N, because i've seen similar names in the neighbourhood
<GitHub120> [linux-milkymist] mwalle pushed 5 new commits to master: https://github.com/milkymist/linux-milkymist/compare/5b92aa2...aaa25ab
<GitHub120> [linux-milkymist/master] lm32: lm32 has no dma capabilities - Michael Walle
<GitHub120> [linux-milkymist/master] lm32: support for simpleImage - Michael Walle
<GitHub120> [linux-milkymist/master] lm32: move dtb section definition - Michael Walle