Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
aw_ joined #milkymist
aw joined #milkymist
DJTachyon joined #milkymist
xiangfu joined #milkymist
<aw_>
wpwrak, the IO_L48N_1 pin of fgpa doesn't wire out, so I'll use one pin of J21 expansion header for instead. (i.e.: pin 13 of J21, IO_L9P_1)
xiangfu joined #milkymist
DJTachyon joined #milkymist
<wpwrak>
aw_: ah, why not. J21 has so many uses :)
<aw_>
wpwrak, yup...i measured those io pins are normal low only unless i press 'reboot'(i.e. reset transition within the act) btn in gui again. :)
<aw_>
one of AND gate inputs is J21.pin13 (even no s/w to activate). next to rework circuit of usb switch.
<wpwrak>
(reset circuit with AND gate) nice :) do you see the reset propagate (with the scope) ?
<wpwrak>
lekernel: hmm, where do you reserve the communication memory block on the navre ?
<kristianpaul>
initprog ,,,}
<kristianpaul>
oops
xiangfu joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
<wpwrak>
hmm, the LV3's reluctance to talk to M1 seems to be an AVRism. it uses an AVR. lo and behold, atusb just acts in the same way.
<wpwrak>
and of course, any of my silabs-based boards enumerate just fine. so my stack can't be all wrong ...
<wpwrak>
stekern: you mentioned you had a fancy usb protocol analyzer at work. maybe that could be handy :) would you also happen to have any USB device that uses an USB-capable AVR ? if yes, that may exhibit the same issue and thus be useful for testing
<wpwrak>
interesting ... i removed the wait until TX is idle. this reduces the time between SETUP and DATA0 to ~2 cycles. now the avr does ACK.
<wpwrak>
nice. faderfox lv3 enumerates :)
<wpwrak>
let's see if anything else still works ...
<wpwrak>
apparently yes
mumptai joined #milkymist
<wpwrak>
stekern: so, problem already solved :)
lekernel_ joined #milkymist
nightlybuild joined #milkymist
<wpwrak>
lekernel_: a quick question: where in softusb do you allocate the COMLOC buffer ?
Martoni joined #milkymist
wolfspraul joined #milkymist
azonenberg joined #milkymist
lekernel__ joined #milkymist
<wpwrak>
lekernel__: Q: where in softusb do you allocate the COMLOC buffer ?
<lekernel__>
in its data memory
<lekernel__>
see comloc.h
<lekernel__>
0x1000-ish
<wpwrak>
yes, those are the addresses. but how does gcc know what it can't put variables there ? or how do you know that gcc didn't put anything there ?
<wpwrak>
(well, ld)
<lekernel__>
gcc allocates variables from the beginning of the memory
<lekernel__>
if you have less than 4K data, which is quite a bit, it should be ok
r33p joined #milkymist
<wpwrak>
ah, manual allocation then :)
<lekernel>
yes
<wpwrak>
sigh. the names with commas in the FPGA do seem to have some significance. at least things failed when i tried to build the whole SoC with my taps. yet another run then ...
lekernel joined #milkymist
<wpwrak>
time for a nap :)
xiangfu joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
Alarm joined #milkymist
<GitHub191>
[milkymist] sbourdeauducq pushed 2 new commits to master: http://git.io/6C7qag
<GitHub191>
[milkymist/master] Bump version number - Sebastien Bourdeauducq
<GitHub191>
[milkymist/master] softusb: move implementation of trigger into macros - Werner Almesberger
xiangfu joined #milkymist
wolfspraul joined #milkymist
<GitHub36>
[milkymist] sbourdeauducq pushed 9 new commits to master: http://git.io/Se5f1Q
<GitHub36>
[milkymist/master] softusb: use symbolic names for various USB constants - Werner Almesberger
<GitHub36>
[milkymist/master] softusb: move protocol identification (interface descriptor) to separate function - Werner Almesberger
<GitHub36>
[milkymist/master] softusb: remove trailing whitespace - Werner Almesberger
<wpwrak>
hmm, github doesn't say anything about the set of 7 patches ... let's see if they're there (they kinda have to or the rest wouldn't apply)
<wpwrak>
yeah. all is good :) thanks !
<lekernel>
"interesting" ...I got the "gradient bug" with a fresh bitstream synthesis that only included your softusb_sie minor change
<lekernel>
I guess this is some timing or crosstalk xilinx bug... i'll get myself a freeze spray and see if it improves things
<lekernel>
and the lv3 works! great!
* lekernel
applauses wpwrak
<wpwrak>
whee ! :)
<wpwrak>
if you go to the bios, does USB spit out a lot of complaints ? (mainly RX timeout error)
<wpwrak>
(crosstalk) that sounds ugly ... :-(
<lekernel>
yes, but I have not upgraded the BIOS, so it still tries to talk to the old SIE
<wpwrak>
oh, that would be confusing :)
<lekernel>
crosstalk in FPGA happens... I've seen a talk from people using it to build RNGs
<lekernel>
but here it could simply be that the timing on the VGA DAC is a bit tight
<lekernel>
that should be easy to fix...
<lekernel>
if we had TMU crosstalk issues, they would accumulate from frame to frame
<lekernel>
(that being said, early versions of ISE had lots of timing model bugs for Spartan-6 that took me days of debugging with a freeze spray...)
<lekernel>
yeah the gradient bug is reproducible on GUI elements too. most probably I/O timing issues.
<wpwrak>
heh, that experience will be handy now :)
<lekernel>
with the comet wallpaper it's obvious
<lekernel>
yeah, definitely sounds like an I/O problem. the bug is not present on screenshots taken with the M1 itself.
<lekernel>
and I didn't put setup/hold constraints on the pins driving the VGA DAC, so I only get what I deserve ...
<wpwrak>
;-)
<lekernel>
anyway - very cool! thanks for the lv3 support!
<lekernel>
btw, my MIDI keyboard also works on USB now
<lekernel>
or well - the controls (joystick + fader) do, but the keys don't
<lekernel>
ha, but you're filtering control messages only from navre :) that'd probably the problem...
<wpwrak>
the LV3 has very weird mappings. things are scattered over various channels and so on. and you can even make it more confusing with the setups :)
<lekernel>
yes, i see
<lekernel>
I'll probaby replace the "note" or "controller number" values by "channel/note" "channel/controller number" pairs
<lekernel>
what do you think?
<kristianpaul>
oh, can i buy a MIDI keyboard now then? :D
<wpwrak>
i think at the end of they day, we'll simply want "input event" :) MIDI, DMX, keybaord, IR, ...
aw_ joined #milkymist
aw joined #milkymist
<aw_>
(pre-rc4 usb switch h/w patch): now works('reboot' on gui and power-cycle), the suggested 120uF for USB2.0 I used 100uF for mostly popular capacitance in both A & B port.
<aw_>
the patch on my board now is super monster, well..will upload pictures later. Next step is to replace 7181C.
togi joined #milkymist
<stekern>
wpwrak: nice that you got it sorted out, I wouldn't have been of much help, I'm on vacation so out of office
<stekern>
otherwise I would have gladly tried to help
<wpwrak>
stekern: oh, you took vacations to play with M1 ? excellent ;-)
<stekern>
hehe, something like that ;)
<wpwrak>
kristianpaul: a controller with knobs and faders may be more useful than a keyboard
<kristianpaul>
wpwrak: any cheap recomendation?
<kristianpaul>
cheap i mean less than 20usd
<wpwrak>
not even in china ;-)
<wpwrak>
for the sub-USD 100 segment, consider Korg and iCON
<kristianpaul>
ok, not for now :)
<kristianpaul>
for me*
<wpwrak>
the nano* series from Korg is quite cheap. alas, it also feels very cheap
<wpwrak>
iCON have a series of small controllers that feel a lot more solid than korg's. for the feature set, the most likely models are similar.
<wpwrak>
e.g., the Korg nanoKONTROL2 and the iCON i-Controls are quite similar and give you the basics
<wpwrak>
maybe the ultimate objective is that synthesizing any project larger than a "hello world" (i.e., one blinking led) becomes an endeavour that spans multiple generations. like in the good old days, when the master artisan taught his kids, so they could finish the project of his lifetime
<lekernel>
even syntax highlighting for their language crashes Java
<mwalle>
lekernel: is there any reason you choose to have a prescaler that divides the system clock by 16?
<mwalle>
in the uart core
<mwalle>
i guess other uart implementations uses 16bit oversampling
<mwalle>
what i want to achive is to have a baudrate of 1, 2 or 3 mbps
<lekernel>
16x oversampling can be a bit too much... it's actually inherited from the das-labor design
<lekernel>
since it worked, i didn't change it
azonenberg joined #milkymist
<mwalle>
ok, thats what i thought ;)
<mwalle>
i would change the hard prescaler to 8 bit so i could get 2mbps working
<lekernel>
if you want to acheive high baudrates, you may run into the more serious problem that the baudrate and the system clock are not necessarily multiples
<mwalle>
i know, but with 80mhz system clock 1 and 2 would work
<lekernel>
why not 10 or 20?
<lekernel>
4x oversampling (finally) works at 12.5Mbps for USB ...
<lekernel>
s/.5//
<mwalle>
lekernel: ft2232 max baud is 3mbps
<lekernel>
don't we have the 2232h which supports up to 30?
<mwalle>
ahh youre right
<mwalle>
i looked at the d variant
<kristianpaul>
2mbps my hero : ) !!
<mwalle>
lekernel: 12mbps seems to be the maximum for the ft2232h
<mwalle>
hopefully the linux driver supports setting own prescaler values for the ft2232h chip
<mwalle>
lets target 10mpbs then :)
<kristianpaul>
:D
elldekaa joined #milkymist
elldekaa joined #milkymist
jpbonn joined #milkymist
elldekaa joined #milkymist
<jpbonn>
Hello - I'm trying to run the demo software (milkymist/software/demo) on qemu (latest git head) and I'm running into a problem:
<jpbonn>
BRD: Running on unknown board (ID=0x00000000), startup aborted.
<jpbonn>
It appears that reading CSR_SYSTEM_ID is returning 0 in get_board_desc() (milkymist/software/libbase/board.c)
<jpbonn>
Any ideas what might be wrong?
<mwalle>
jpbonn: the sysctl module is not updated yet
<jpbonn>
ok
<mwalle>
jpbonn: as a quick workaround, try setting R_SYSTEM_ID in hw/milkymist-sysctl.c to the proper value
<mwalle>
thats an old patch, but it should work for you ;)
<wpwrak>
hmm. some usb-midi devices seem to have an interesting sense of humor. the nanoKONTROL2 happily sends data packets of all zeroes of 64 bytes. as if we didn't have anything better to do than to discard such junk ....
<jpbonn>
mwalle: it worked - thanks
<mwalle>
jpbonn: i'll update the patch soon and push it to my qemu repo
<jpbonn>
mwalle: do you have a qemu fork? I've been using the main one.
<mwalle>
jpbonn: the old one is at git.serverraum.org but that one haven't been updated for ages, the new one will be at my github page github.com/mwalle (or sth like that)
<jpbonn>
mwalle: Ok I'll watch for it
<mwalle>
jpbonn: there was little qemu development in lately, so all patches were upstrema
<jpbonn>
mwalle: thanks for the help. I'm off to get my kid from school.
<mwalle>
np ;)
errordeveloper joined #milkymist
<wpwrak>
now that's funny. i sometimes get a SOF while waiting for a reply to IN. i'm not sure i really believe this ;-)
<wpwrak>
maybe the receiver is still running for some reason. ah well, at least it's not a "real" data corruption.