#milkymist IRC log for Tuesday, 2011-04-05

rohTI to acquire National Semiconductor02:22
rohhttp://www.ti.com/ww/en/acquire/index.shtml02:22
roh*sigh*02:22
larscinteresting02:22
rohgiven my titanic experience with ti.. i'd hope they dont change anything on the natsemi portfolio side02:23
rohespecially on the smps front.. simple switcher and such02:24
larscwell, they'll probably not continue to have the same chip in two versions02:25
rohthats something which sucks on ti. there are chips which have dozends of sub-versions which are annoyingly different in detail02:27
rohand the documentation is always complete, but badly organized.. well.. often the socs just suck in useage02:27
rohif you want to hear real horror stories.. ask people who designed omap boards ;)02:28
larsclike the gta04 guys?02:28
rohdunno. havent talked to them. but others ;)02:29
rohanyhow. i dont like monster companies. bad for innovation and access to information and cooperation02:30
rohatleast for foss and small money developers02:31
larscyes02:32
larscalthough TI has actually been a good company and opened up over the last view years02:33
rohalso versatility is bad. try using another pmu with a omap or vice versa02:33
rohits basically a 'buy the whole solution and let our fae help you design the schematics and board layout' thing02:33
rohlarsc: true. there is still hope.02:34
rohyet i believe it would go much faster if ti would be 'lots of small companies'02:34
rohevery hierarchy adds atleast 2 month on every not completely minor decision. ti has atleast 2 layers more than national02:35
roheven openmoko had to many ;)02:35
larscmost companies have02:46
kristianpaulhmmif TI provide samples from nationals components will be nice too03:41
larscwell, before you could get samples from two companies now it's only one03:42
kristianpaulyup03:43
terpstra_mwalle, you are also working on a gdb over jtag?06:53
terpstra_mwalle, i think i mentioned i've gone for a 'clean room' design for mine06:53
terpstra_the project is hosted at: http://www.ohwr.org/projects/phase06:54
terpstra_so far i have reliable access to the lm32's registers, start/stop/step, and break+watch points06:54
terpstra_however, i've not attached it to a gdb socket yet06:55
terpstra_i have not yet looked into supporting the xilinx jtag cable, but don't expect it would be too hard in my framework06:56
terpstra_as for the patches i made to the jtag connection in the lm32, i'm not 100% certain they will be necessary06:59
terpstra_they were at least partly needed to work around what turned out to be bugs in the altera jtag cable's software07:00
terpstra_since i no longer use their software, their bugs don't matter to me ;)07:00
xiangfukristianpaul: hi. I bought one 1GB memcard. works fine in my m1.08:12
lekernelomap is just one more proprietary SoC. you could compare it to the apple a4, for example. if it makes a bit of noise in the FOSS world, it's only because of TI's marketing of the beagleboard.08:23
lekernelIf a device is not yet described, the user may assemble a driver out of the reusable software components. For example, an Altera USB-Blaster09:33
lekerneldriver is just a FTDI device chained with a byte packeter and a JTAG bit banger. Once the design has been graphically assembled, it is automatically scanned for attached JTAG devices and the USB cable design is shared online with any future users of the same cable.09:33
lekernelinteresting09:33
lekernelthe xilinx jtag cables use a custom protocol... how will you implement that? new component?09:38
lekernelbasically, you're sending packets TMS/TDO samples on a bulk endpoint, and you get TDI packets back09:39
xiangfulekernel: why I flash 19M(0x12E0000 the length of flash5) 0xFF file to /dev/flash5. make all file lose. but not 5M?09:44
lekernelit depends where YAFFS2 places the lists of filenames09:44
lekernelnothing tells you this should be at the beginning of the flash, no?09:44
lekernelespecially if you have made several operations before09:45
lekernelYAFFS2 tries to minimize the number of sector erases, so it would rather write new data to an erased sector at the end instead of erasing a previously used sector at the beginning09:45
xiangfuthanks. so when I make the yaffs image. I have to make it 19M. right?09:48
lekernelyes09:49
lekernelbut I'd guess the end would be filled with 0xFF09:49
terpstra_lekernel, hey11:21
terpstra_what is the protocol?11:21
lekernelhi11:21
terpstra_is the cable a usb device?11:22
lekernelwell I don't remember all the details11:22
lekernelyou could have a look at my (ad hoc) code http://www.milkymist.org/misc/ml401_flasher-1.0.tar.bz211:22
lekernelwhich in turn comes from UrJTAG11:22
lekernelyes, it's USB11:22
terpstra_ftdi ?11:22
lekernelno, custom11:23
terpstra_hmm11:23
lekernelxilinx jtag cables are a big mess actually11:23
lekernelthey have a fx-usb and a cpld (even a spartan 3a fpga in the latest version)11:23
lekernelI think the latest version could run linux with a bit more RAM :o)11:23
lekerneljust for doing some stupid bit banging11:23
methril_workterpstra_, this could be extended to some BDM devices?11:24
methril_workor it`s not so abstract?11:24
terpstra_methril, i'm not sure what you mean? a background gdb ?11:24
methril_workBDM is like JTAG but for ColdFire & other Freescale devices11:25
terpstra_ahh11:25
methril_workso, no11:25
terpstra_my component architecture should be able to do that11:25
terpstra_you would need probably a custom bdm component tho11:25
methril_workoh, interesting11:25
terpstra_http://www.ohwr.org/projects/phase/repository/entry/src/main.cpp11:26
terpstra_no GUI yet11:26
terpstra_but jump down to the 'ic.configure()'11:26
terpstra_that's where i connect all the components to talk to the jtag on altera11:26
terpstra_you can basically hook up a directed acyclic graph of components where each speaks a protocol from inputs to outputs11:27
terpstra_then you 'wire them up' and it makes a driver11:27
methril_workinteresting11:27
terpstra_i'm in the middle of restructuring the codebase so you don't have the lm32 component code visible in there yet11:28
methril_worki like more than OpenOCD tcl scripts :)11:28
terpstra_well, i want it to be done with a GUI11:28
terpstra_and autoconnect components depending on what it detects11:28
methril_workbut is the gui being mandatory? sometimes i prefer console sw11:29
terpstra_i think for connecting components a gui is best... but if i get so far, i surely will have passed through some xml format that you can launch it with11:29
terpstra_so if you have configured the device already in the gui, you could save your chain and drive it from the command-line11:30
terpstra_but that's vaporware11:30
terpstra_no gui, only manual c++ atm11:30
terpstra_lekernel, so your ml401-flasher.c should be easy to integrate11:31
lekernelif you want... but it's quite a hack11:32
terpstra_you could probably just write it like the 'ftdi-byte-mode.cpp' code11:32
terpstra_and then re-use my jtag bitbanger11:32
lekernelwell I don't have a xilinx cable anymore :)11:32
terpstra_we do, actualyl11:32
terpstra_but i want/eed to get gdb running perfectly before next wednesday11:33
lekernelI use the milkymist pods now11:33
terpstra_so that's my priority11:33
lekernelbtw, if you want some of our jtag pods, they're cheaper and faster than the xilinx cables11:34
methril_workthey work with all xillinx FPGAs?11:34
lekernelyeah, they should11:34
lekernelit's the same pinout as the xilinx cable11:35
terpstra_lekernel, the altera jtag cables are nice too11:35
methril_worknice, i`ve a cheap xiinx cable :)11:35
terpstra_how fast is fast?11:35
lekernelwe don't have the ribbon cable though, so I don't know how easily they could plug to other boards11:35
lekernel30Mbps11:35
terpstra_oh11:36
terpstra_that's better than the altera one!11:36
lekernelit's merely a ft2232h breakout board11:36
terpstra_although i'm not sure if the ftdi driver is what makes it slow11:36
wolfspra1lxiangfu: wow12:53
wolfspra1lI bought my 3rd keyboard today12:53
wolfspra1lanother cheap china keyboard12:53
wolfspra1land now I have new weird bugs12:53
xiangfu:)12:54
wolfspra1lthe keypresses kind of work in the Flickernoise GUI (I'm using your build)12:54
wolfspra1lbut as soon as I connect the keyboard, I cannot click buttons with the mouse anymore12:54
wolfspra1lI can move the cursor around, but clicking won't work12:54
wolfspra1l<tab> with the keyboard also doesn't really move me to the next control12:54
wolfspra1lI almost feel it's some software problem where the focus remains in the edit control12:55
wolfspra1lmaybe I'm just too dumb to use the software?12:55
wolfspra1lif I have both keyboard and mouse attached at boot time, I cannot boot12:57
wolfspra1lthat may be another (separate) bug12:57
wolfspra1lyes so when I start typing, the mouse focus gets stuck in the text12:58
wolfspra1lI can move the mouse, but that will only move the text selection12:59
wolfspra1lI cannot press buttons anymore12:59
wolfspra1lthat seems to be bug #112:59
wolfspra1lbug #2 - if I have this latest kbd connected when plugging in the m1 dc jack, the m1 will immediately go to an unbootable state (2 leds dimly lit)13:00
wolfspra1lI need to first plug dc jack in, then connect the keyboard, then bootup13:00
xiangfu(bug 1) did your 'enter' key have problem. like always pressed?13:01
wolfspra1lno <enter> works normally13:03
wolfspra1lI'm in the patch editor now13:03
wolfspra1lthe problem is that the mouse focus is stuck in the text13:03
wolfspra1las if the mouse is always pressed down13:03
terpstra_lekernel, what is it you dislike about the xilinx cable besides the speed? afaict, i can support it for my debug chain with like 30 lines of code.13:03
terpstra_that makes me quite happy.13:04
lekerneluh. price13:04
terpstra_ahh13:04
terpstra_you called it a "mess" i thought13:04
lekerneland yeah, technically it's a mess (but it works)13:04
terpstra_but all i need is two commands to read/write the jtag pins13:04
terpstra_that's quite simple13:04
lekernelwhich partly explains the price I think13:04
wolfspra1lxiangfu: it's an apple mouse, maybe there is a mouse problem that is separate from the keyboard?13:04
terpstra_what would you consider not a mess?13:05
lekernelone small FTDI chip13:05
wolfspra1lterpstra_: we've made a little board13:05
lekernelor similar13:05
wolfspra1lI can sell it to you :-)13:05
terpstra_wolfspra1l,  ;P13:05
xiangfuwolfspra1l: maybe13:05
wolfspra1l29 USD or so (never thought about it)13:05
wolfspra1lterpstra_: actually you should buy a complete Milkymist One, of course13:05
wolfspra1lmake it to the next level :-)13:06
terpstra_well, i am working with our own fpgas here13:06
lekernelwith that Xilinx cable, you have a 8051, that the host computer has to program at every connection (with the xilinx software this is a major source of cable problems btw), then you have a fat FPGA or CPLD and everything to do....? JTAG bit banging.13:06
terpstra_don't want a music dj thing :)13:06
lekernelthat's a bit ridiculous13:06
wolfspra1lterpstra_: what is your thing doing?13:06
terpstra_lekernel, you obviously haven't seen the altera cable then... that's far more complicated.13:07
wolfspra1lxiangfu: should I buy another keyboard? :-)13:07
terpstra_wolfspra1l, controlling the particle accelerator at GSI13:07
wolfspra1lget an m1, rock the place13:07
terpstra_(but we will possibly be using the lm32 in our fpgas)13:07
wolfspra1lwill lift morale13:07
xiangfuwolfspra1l: you really meet a lot of bugs :D,13:08
wolfspra1lyes a lot13:08
wolfspra1lI will demo you13:08
wolfspra1lgood that I like bugs13:08
wolfspra1lmaybe I should get another mouse13:08
lekernelwolfspra1l: keyboard (usb) bugs?13:08
wolfspra1llekernel: don't know, it's my 3rd kbd now13:08
wolfspra1lfirst one had usb hub13:08
wolfspra1lsecond one greenasia ic, who knows13:08
wolfspra1lthird one kinda works, but the 2 problems as described above13:09
wolfspra1lfirst one is easy to workaround - plug it in only after applying dc power to m113:09
wolfspra1lsecond one not so easy, the mouse focus gets stuck in the text when I start typing13:09
wolfspra1lso when I move the mouse, i move the selection13:09
lekernelhuh, I have never seen that one13:09
wolfspra1lclicking will only remove the selection, but immediately start another selection13:09
wolfspra1lso I cannot click buttons anymore13:10
lekernelthe keyboard detection issue with the greenasia issue was more common13:10
wolfspra1lwhich means - as soon as I start typing the gui is completely unusable13:10
lekernelI've never seen a bug like that13:10
wolfspra1lit could be my mouse of course, not the kbd13:10
wolfspra1lit's an Apple mouse13:10
lekernelwhich one?13:10
lekernelI have tested that one http://www.geek.com/wp-content/uploads/2009/10/apple_mighty_mouse.jpg and it worked13:11
wolfspra1lmodel says A115213:11
wolfspra1lold one13:11
wolfspra1lwell, the mouse itself works without the kbd13:11
wolfspra1lproblems start once I type the first character13:11
wolfspra1lthen mouse focus (click) gets stuck to the text I typed13:12
lekernelthat? http://www.cnet.co.uk/i/c/blg/cat/blog/terrible_tech/top-10-terrible-technologies-6.jpg13:12
lekernel:)13:12
wolfspra1lit could even be xiangfu's build13:12
lekernelyou can try the keyboard in the BIOS13:12
wolfspra1llekernel: yes, almost looks like that pic13:12
lekernelif you press ESC at boot it should give you the console13:12
wolfspra1ljust the side button is white, not grey. maybe a bit older still.13:12
wolfspra1lit's also strange that I cannot power the m1 with this kbd attached13:13
wolfspra1lit will immediately go to unbootable state (dimly lit leds)13:13
wolfspra1lbut let's put that aside now13:13
lekerneleven with the reset IC?13:13
lekernelthe reset IC should definitely fix that one bug13:13
wolfspra1lI don't have such a board13:14
wolfspra1lnow my m1 won't boot right now - waiting time13:14
wolfspra1lleds dimly lit... (even without kbd)13:14
lekerneljust use the JTAG cable to load the bitstream... and don't wait13:14
wolfspra1lwell. I like to experience our users pain :-)13:15
wolfspra1lI'm asking for money for this thing...13:15
lekernelthey have a JTAG cable too. that's why it says "developer kit"13:15
wolfspra1lwow yes, looks like cannot boot now13:16
wolfspra1lthat's definitely not end user ready...13:16
wolfspra1limagine this would happen at a party/event13:16
lekerneltry with that damn reset IC...13:17
wolfspra1lone by one13:17
wolfspra1lI don't have such a board here, but I try jtag now13:17
wolfspra1lI know we already fixed/improved this13:17
wolfspra1lit's good to see that the fix is valuable :-)13:17
wolfspra1lI'm just reflashing the whole thing now13:19
lekernelyou shouldn't need to (unless the reset bug damaged the contents of your flash, but this was extremely rare)13:20
wolfspra1lnow it boots :-)13:20
lekernelmaybe you could also just do 'pld reconfigure' when the bug manifests itself13:21
wolfspra1llekernel: am I supposed to press <esc> on the usb keyboard?13:21
lekernelyes13:21
wolfspra1lI did and nothing happened13:22
lekernelor the serial console. both are connected13:22
wolfspra1lI'm sure it's another problem with my keyboard13:22
lekernelworksforme13:22
wolfspra1ldon't worry13:22
wolfspra1lyes sure13:22
wolfspra1lmy feeling is this kbd has more weirdness13:22
lekerneldid you do it repeatedly?13:22
wolfspra1loh sure13:22
wolfspra1lall the time13:22
lekernelhm, ok13:22
lekernelmaybe have a look at the serial output13:22
lekerneland/or abort boot from serial, then try to use the USB keyboard13:23
wolfspra1las soon as the keyboard is connected, mouse clicks don13:23
wolfspra1ldon't work anymore13:23
wolfspra1lanyway13:23
lekernelthe BIOS prints more USB debug messages on serial than flickernoise13:23
wolfspra1lit's either a problem in xiangfu's binaries, or with that specific kbd I bought13:23
lekerneldo you have a USB bus analyzer?13:30
wolfspra1llekernel: is it possible that kbd & mouse attached at dc-jack insertion time makes the 'unbootable state' problem more likely? is there a possible connection?13:30
wolfspra1lno, unfortunately not [usb bus analyzer]13:30
lekernelyeah, absolutely, it could change the power ramp speed and affect reset timing (and trigger the bug)13:30
lekernelbut that should be sorted out with the addition of the reset IC as well13:31
wolfspra1lI would not worry about those bugs right now, I really buy cheap crap keyboards on the street.13:31
wolfspra1lthose keyboards will go to xiangfu, then him or you can decide whether it's worth to fix those bugs13:31
wolfspra1lif we can source a rubber kbd for a few usd, we may well include on in rc3, as proposed by xiangfu13:31
lekerneldoes xiangfu have a usb analyzer?13:32
lekernelI have a totalphase analyzer, but it's quite a piece of junk13:32
lekerneldefinitely not worth its price13:32
wolfspra1lwhat about the Beagle USB 480 / USB 12 thingies?13:32
lekernelthat's what i'm talking about13:32
wolfspra1lwhich one of the two do you have?13:33
lekernelusb 1213:33
lekernelthe software works great when your devices talk USB correctly13:33
lekernelbut it breaks easily when you have some garbage13:34
lekernelwhich is rather cretinous for a debug tool13:34
lekernelbtw the usb 480 uses the same crap software13:34
xiangfulekernel: I don't have :(13:34
lekernelalso both these devices lack the ability to observe waveforms of failed USB transmissions13:35
lekernelthe software will just tell you "this packet has a problem" but you won't know more13:35
lekerneliirc wpwrak has made some USB decoding stuff13:38
lekernelit could be better and cheaper than totalphase's proprietary crap13:38
lekernelthe saelae logic analyzer also does a decent job at capturing the USB waveforms but you won't get high level protocol decoding13:40
wolfspra1lI don't think these keyboard problems should be our #1 priority right now13:43
wolfspra1lI will eventually find one that just works13:43
wolfspra1land we see whether we can include a cheap rubber one in rc313:44
wolfspra1lthat will give us time to fix usb bugs one by one13:44
kristianpaulxiangfu: :/... wich brand? (memcard)13:44
wolfspra1lkristianpaul: you still don't have any memory card that works, right?13:45
Action: xiangfu already order 4 rubber keyboards in tobao today. will get them in 2~3days13:45
wolfspra1lmaybe xiangfu can mail you one with an airmail letter, just so we get another option on the way13:45
kristianpaullekernel: please can you please pusblish a bitstream for last flickernoise ?13:45
lekernelfor the memory card I think the way to go is to copy linux/bsd code13:45
lekernelmemory cards are messy, let's use proven code13:45
kristianpaul(copy linux/bsd code) agree13:45
lekernelkristianpaul: coming13:46
kristianpauli dont have time to compile it know at lasbsurlab, have workshop tomorrow13:46
kristianpauls/know/now13:46
kristianpaulthanks !13:46
kristianpaulwolfspra1l: hi, yes13:46
lekerneli'll try to fix some ethernet bugs before13:46
wolfspra1lxiangfu: can you airmail a memory card that works for you to kristianpaul?13:46
lekernelwhat time is your workshop?13:46
wolfspra1ljust into a regular letter (attach with tape to normal paper, should be fine)13:46
xiangfuwolfspra1l: sure.13:47
kristianpaultomorrow13:47
wolfspra1lit may still not work for kristianpaul, but it's another attempt we try in parallel to the other attempts13:47
xiangfukristianpaul: no brand in the memcard. bought at street small shop.13:47
wolfspra1lit doesn't even matter how fast the letter arrives, or whether it arrives at all13:47
kristianpaulxiangfu: :-)13:47
lekernelwolfspra1l: otoh it would be rather interesting to fix the problems that prevent kristianpaul's card from working instead13:47
wolfspra1lbut considering the cost and all, maybe it can unfreeze kristianpaul from this stuckness13:47
wolfspra1llekernel: oh sure, absolutely. I say _parallel_13:48
wolfspra1lI try to remove some stuckness.13:48
lekernelkristianpaul: can't you use the flash disk instead?13:48
kristianpaullekernel: yes sure13:48
kristianpauli do13:48
wolfspra1lthat way we could also rule out an issue with kristianpaul's board13:48
kristianpauljust ethernet stuck at ramdon.. :/13:48
wolfspra1lit's just more hard data, if xiangfu sends a card that worked for him to kpaul13:48
kristianpauli agree, will be a nice test13:49
lekernelyeah, ethernet bugs are the #1 pain for me atm13:49
wolfspra1lthose cards are so cheap, plus a cheap airmail letter, let's just get it on the way...13:49
lekerneli'll fix them13:49
wolfspra1llekernel: I have a question about the patch 'language'13:50
wolfspra1lare you following a standard?13:50
kristianpaulworkshipt is tomorrow afaik is not about milkymsit, but i have dorkbot presentation same days (april 6)13:50
lekernelwolfspra1l: it's the milkdrop language13:50
wolfspra1ldo you want to talk about this as being some sort of 'api'?13:50
kristianpauland saturday i have a meeting with some local VJing people13:50
wolfspra1ldoes it have a version number?13:50
lekernelno13:50
wolfspra1lis it 100% milkdrop?13:50
wolfspra1lor with m1 specific extensions, or incomplete milkdrop?13:51
lekernelit's milkdrop with extensions13:51
lekerneland otoh some details from milkdrop are missing too13:51
lekernelwe can say it's a milkdrop 'derivative'13:52
wolfspra1lmaybe we should give it a new name, and version number, and declare 'stable' at some point?13:52
wolfspra1limportant to get the message out that that's a stable 'API' that will stay stable for years. I think.13:52
lekernelabout one third of the original milkdrop patches work in flickernoise13:52
lekernelthe main reason for non-working milkdrop patches is custom waves and shapes which aren't supported atm13:53
wolfspra1lthe milkdrop things are called 'presets'?13:53
wolfspra1lwhere does 'patches' come from?13:53
wolfspra1lmaybe you want to call this 'Milkymist Patches 1.0' at some point? (the API)13:54
kristianpauli gotta go, have a semnira to assist in 30 minutes..13:54
wolfspra1lor 0.1, or whatever13:54
lekernelyeah, patch == milkdrop preset13:54
xiangfukristianpaul: please send me your address and phone number. I will send you two. 512MB and 1GB memcard13:54
wolfspra1lwhy 'patch'?13:54
wolfspra1lyou created that name?13:54
lekernelno, it's used in other AV software too13:55
lekernelpuredata and maxmsp for example13:55
lekernelas a matter of fact, it doesn't come from me. someone who's into music (and little into tech) called that a "patch" when I showed it to her13:56
lekerneland I thought that was a good name13:56
wolfspra1loh sure, I'm just curious so if I talk about it it's not total nonsense13:56
wolfspra1lmaybe we should call that 'Milkymist Patches API'?13:56
lekernelscratch API13:56
wolfspra1lyes, agreed13:57
wolfspra1ljust to get my point across13:57
wolfspra1lbut then 'P'atches with capital 'P' has a verison number, and is stable or not, and backward compatibility is guaranteed or not13:57
wolfspra1lat least if someone asks "why should I get into this Milkymist Patches stuff - will it be around in a few years?"13:57
wolfspra1lwe need a straight answer13:57
wolfspra1lI will start to capitalize patches, and talk about it as some form of stable interface.13:58
lekernelwell13:58
wolfspra1lunless you don't like that for some reason13:59
lekernelmany of the flickernoise patches are imported milkdrop presets which were written in 2000-200213:59
wolfspra1lok that's all history13:59
wolfspra1lI talk about Milkymist now13:59
lekernelI think that can be called stable :)13:59
wolfspra1lwe want people to join13:59
lekernelI see no reason for breaking backward compatibility13:59
wolfspra1lyou just wrote video-in patches a few days ago13:59
wolfspra1lyou are missing my point13:59
lekernelvideo-in support is an extension over milkdrop13:59
wolfspra1lthe backward compatibility is to our own stuff14:00
wolfspra1lmidi, dmx, video-in14:00
wolfspra1lpeople want to know that 'we' = Milkymist, stand behind this 'Patches' thing14:00
wolfspra1lthat it's not some random programming language that will change every 6 months14:00
wolfspra1lwithout proper documentation, breaking backward compatibility, etc.14:00
wolfspra1lif we can say 'no' to all these things, it's good - more people will join I think14:01
lekernelwe can say 'no'14:01
wolfspra1lthat's what I'm trying to understand with my questions14:01
wolfspra1lcool, perfect14:01
lekernelI'm documenting it, too14:01
wolfspra1lwe need to think about versioning then, at some point (not urgent)14:01
wolfspra1lto get the message across14:01
wolfspra1lanother quick question - you are working on llhdl14:02
wolfspra1lis it already possible to create the m1 bitstream with llhdl?14:02
lekernelno, not yet14:02
lekernelit will take time. and LLHDL is just a side project, my main priorities are on m1 and flickernoise14:02
lekernelthere are many things to sort out in LLHDL before it can handle something as complex as MM SoC14:03
lekernelalso, the p&r tools (which aren't part of llhdl) would need some work too. and I don't like the current antares architecture and am thinking about redoing it completely14:04
lekernelbut anyway. those are hobby projects :-)14:04
wolfspra1llekernel: got it. thanks.14:06
lekernelbtw, software with functionality equivalent to what LLHDL aims for have ~30k¬ licenses. it's non-trivial stuff to write that won't get done over a few weeks :-)14:08
wolfspra1lsure, fully understood. I was just curious where it stands.14:13
wolfspra1lcalling it a day, n814:13
lekernelFallenou: what is CPU_U32_FIX and ipalign() ?14:49
Fallenousomething I pasted from the tsmac driver14:50
Fallenoufrom lm32_evr bsp14:50
lekernelextern void *malloc(size_t); ? can't use stdlib.h?14:50
Fallenoulekernel: don't remember why I've put that14:52
FallenouI guess I needed it14:52
Fallenoumalloc was some kind of a define I has to #undef14:52
Fallenouline 3714:52
FallenouI had*14:52
lekernelok14:53
lekernel      txq = 2048;14:53
lekernel      if (txq < ifp->if_mtu)14:53
lekernel        break;14:53
lekernelwhat is that doing? txq isn't used elsewhere14:54
lekernel(in txdaemon)14:54
lekernelalso I guess the MTU will always be less than 2048, no?14:54
lekernelis there a reason for having this code, or is it just copy and paste cruft that should be removed?14:55
Fallenouit's clearly copy pasted from tsmac14:56
lekernelok, removing14:56
Fallenouyep14:56
lekernelfrom my understanding it does nothing anyway14:56
FallenouI think it's useless14:56
Fallenouand it does no do more in tsmac code :)14:56
FallenouMaybe they copy pasted it too14:56
lekernelbtw are braces on the line after if/for a requirement for rtems code?14:56
Fallenoudon't remember14:57
lekernelyeah there is a lot of copy and paste and cruft in rtems bsp's unfortunately14:57
lekernelsame with filesystems, but people more often need new BSPs than new filesystems14:58
lekerneland can also be put off by crap like eval_path14:58
lekernelFallenou: why do you check for sc->txDaemonTid == 0 in minimac_init()? isn't that condition always verified?15:34
lekernelbtw, as far as I remember, 0 is a valid RTEMS task ID15:34
lekerneli'm removing this cruft15:35
lekernelthis driver will be half the size when i'm done :)15:35
lekernelFallenou: interrupt handler routines can (and should) be static in general15:41
Fallenoulekernel: I think this "if" is there just to do some things only once15:41
lekernelno need to export them15:41
lekernelFallenou: minimac_init() is called only once, no?15:41
Fallenoulike creating the bsdnet_newproc15:41
lekernelit would break anyway when called twice15:41
FallenouI'm not sure15:41
Fallenouwith the ifconfig up/down stuff15:41
lekerneldo we have to support ifconfig down? what does that bring to the user?15:42
lekernelit's a lot less valuable than stable, simple and quickly developed ethernet15:42
Fallenouanyway i'm not sure minimac_init() is just called once15:43
lekernelthat's an easy check, just add printf at the beginning15:43
Fallenouthe real init, called *once* is rtems_minimac_driver_attach15:43
lekernela bit like replacing the CRC btw15:43
lekernelah, yeah, there's this stop thing15:44
Fallenouif there is a check, it's surely because it's called afterward somehow and we don't want to create extra proc15:44
Fallenoufor the txq I agree it was nonsens15:45
lekernellet's leave that aside, it's an unimportant feature (especially compared to stability)15:45
Fallenoubut I would let the if if I were you15:45
lekernelno, i'll just strip out all that ifconfig up/down support that makes things a bit more complex for a near-zero value15:45
Fallenouok15:47
lekernelbtw, what is the purpose of the RX daemon? can't we just call ether_input() from the interrupt handler?15:53
lekernelwhat does ether_input() do anyway? are there compute-intensive parts that should go into the daemon?15:54
lekernelhm...15:57
lekerneldo {15:57
lekernel      unsigned int mlen;15:57
lekernel      mlen = nm->m_len;15:57
lekernel      if (nm->m_len > 0) {15:57
lekernel        m_copydata(nm, 0, mlen, p->raw_data + len);15:57
lekernel        len += nm->m_len;15:57
lekernel      }15:57
lekernel  } while((nm = nm->m_next) != 0);15:57
lekernelcan't we replace that with a single call to m_copydata()?15:57
Fallenouether_input() is passing the packet to the tcp ip stack15:57
lekernelm_copydata(mbuf, offset, len, buf)15:57
lekernel   Copy data from an _mbuf chain_15:57
lekernelso clearly, m_copydata() already handles chained mbuf's15:57
lekernelno need to re-do it by hand15:57
Fallenoustrange that it works so :o15:58
lekernelwell that code works15:58
lekernelit's just unnecessarily complex, bloated and bug-prone15:58
lekernelnm->m_len is the length of that one particular mbuf, not of the chain15:59
Fallenouoh ok15:59
Fallenouso we can put the total length?15:59
lekernelm_length(mbuf, last)16:00
lekernel   Return the length of the mbuf chain16:00
lekernelwhere did you get that m_copydata code from?16:00
Fallenoulekernel: ether_input *cannot* be called from interrupt handler16:01
Fallenouimpossible16:01
lekernelwhy not?16:01
Fallenouit's the whole tcp ip stack16:01
Fallenoubehind ether_input()16:01
lekernelso what?16:01
Fallenouso if you put that in the handler16:01
Fallenouit will take forever to compute16:01
Action: xiangfu make the 'mkyaffs2image' works :)16:01
Fallenouwo :)16:02
lekernelwhat does that do anyway? decode packets, then fill the applications' socket buffers?16:02
Fallenouit's much more complex than that16:02
Fallenouyou have decoding several layers16:03
Fallenouand a tcp state machine16:03
Fallenouwhich merge packets together, re order them16:04
lekernelthere must be some kind of locking too16:04
Fallenoui'm pretty sure this can sleep16:04
Fallenouand we should not sleep in the handler :)16:04
lekernelsleep on what?16:04
Fallenoudon't know16:05
lekernelhmm... the rtems bsp guide also recommends using a RX task16:05
Fallenouwell yes I read the guides, documentations, and other bsp drivers to write the milkymist one :)16:05
lekernelwell, having some critical thinking helps too :)16:06
Fallenoulet's ask Joel maybe you're right16:07
Fallenouand ether_input() just feels a buffer16:07
lekerneli'll check the code16:07
Fallenouand the complex tcp ip stack reads this buffer16:07
lekernelthis is merely calling IF_ENQUEUE()16:09
lekernelwith splimp() and splx() calls for locking16:09
lekernelthere's also a call to schednetisr(NETISR_{IP,ARP}) which I guess triggers another "daemon" with the TCP/IP task16:11
lekernelno need to stack daemons...16:11
Fallenouisn't schednetisr some kind of scheduler call ?16:11
lekernelno, it's just calling rtems_event_send()16:12
lekerneland I guess IF_ENQUEUE wouldn't sleep/block either, since it's preceded by16:13
lekernelif (IF_QFULL(inq)) {16:13
lekernelIF_DROP(inq);16:13
lekernelm_freem(m);16:13
lekernel}16:13
lekernelto me the only possible troublemaker is the spl* functions16:13
Fallenouyes16:14
Fallenouthat's what I meant by "it can sleep"16:14
Fallenousleep/wait/block16:14
lekernellol, they do nothing on rtems16:15
lekernel#define splnet()016:15
lekernel#define splimp()016:15
lekernel#define splx(_s)do { (_s) = 0; } while(0)16:15
Fallenouwow16:15
Fallenouawesome16:15
lekernelit's pretty weird btw16:16
lekernelwhat happens if the TCP/IP stack reading the interface's input queue gets preempted by ether_input calling IF_ENQUEUE ?16:17
lekernelmaybe this is the sole purpose of the RX daemon16:18
lekernelcall ether_input() with a lower priority than the TCP/IP stack16:18
lekernelah they're using a global network semaphore (which you didn't implement btw)16:22
lekernelrtems_bsdnet_semaphore_{obtain,release}16:22
lekernelok i got it16:23
lekerneland we need that RX daemon to possibly block on the semaphore, which we can't do in the interrupt handler16:24
Fallenouwhy network driver should not include stdlib.h16:26
Fallenouhttp://www.rtems.org/onlinedocs/releases/rtemsdocs-4.10.0/share/rtems/html/bsp_howto/bsp_howto00117.html16:26
Fallenouok I get it16:27
Fallenouso I forgot to use the proper locking :x16:27
lekernelhmm ok... we don't really need malloc anyway16:27
lekernelFallenou: the Ethernet core always assert its interrupt line when a slot is in state PENDING16:46
lekernelso when you do printk("No rx buffers left in the pool! We are in big troubles!\n"); and then ack the interrupt without emptying the slot before, the interrupt stays asserted forever and the board runs the ISR in a loop without having time to refill RX buffer16:47
lekernelso, yes, in fact we are in big trouble as everything crashes then :-)16:47
Fallenouso the message is correct :'16:47
Action: Fallenou has a look16:47
Fallenouoh ok16:49
FallenouI didn't give that much thought about that case16:50
Fallenoubecause it is not meant to happen16:50
Fallenouif this happens we are not servicing interrupt fast enough16:50
lekernelbtw you shouldn't call bsp_interrupt_vector_{disable,enable} in the ISRs16:50
lekernellots of bugs I'm unrooting here it seems :-)16:51
Fallenouwell there is no need for the interrupt_vector_{disable,enable} anymore indeed16:53
Fallenoulekernel: it was needed before, when the unloading of the slot was done in the rxDaemon16:55
Fallenouthe handler disabled the interrupt16:55
Fallenouand the daemon reEnabled the interrupt16:55
Fallenouso that the handler doesn't get called in an infinite loop16:56
Fallenoubut now it's unneeded16:56
lekerneli'm actually wondering if bsp_interrupt_vector_enable wouldn't re-enable interrupts globally, resulting in more bugs and breakage when a packet is received16:57
lekernelanyway16:57
lekernelit shouldn't be put in the isr, period16:57
Fallenouyes16:58
lekernelFallenou: you shouldn't either read the packet slot status in rxdaemon when you already do that in the isr...17:04
lekerneland even less ack interrupts in the daemon17:05
Fallenouoh that's in the case of a RX FIFO overflow17:05
FallenouI never really knew what to do in this case17:06
Fallenouwhere do I read slot status in the rxDaemon ?17:07
Fallenoudon't have that in my code :o17:07
lekernelin this case, writing hopelessly broken code doesn't look like much of a solution :-p17:07
Fallenouwell I guess I asked there what to do if a fifo overflow happens17:08
Fallenoubut this code comes from the first version of the driver17:08
lekernelyou don't read slot status, but in case of FIFO overflow you print a warning and clear the reset bit, which is the good thing to do except that it should be done in the ISR before checking the slot status17:08
lekernelthen you mess up the interrupts17:08
Fallenouyes I do again the wrong vector_enable17:09
FallenouIt's a good thing to have multiple people looking at the code ^^17:09
Fallenouwell ok I should have moved the check for fifo overflow to the handler too17:12
Fallenouwhat is the benefit of checking for fifo overflow inside the handler ?17:13
Action: Fallenou heading home17:35
lekernelWTF is fedora doing... http://pastebin.com/BJysVLnD with just plugged cable19:01
lekerneland that process seems to be 'cat'19:02
lekernelusually I could get away quickly and without much hassle from those situations by using rm -f on the invoked binary that I never needed, but I guess my system wouldn't work very good without cat ...19:03
lekernelthis is super annoying. it breaks the serial cable19:06
lekerneland I need it just now19:06
lekernelah... it's not fedora... it's xiangfu's script that was still running in the background somehow19:08
kristianpaulhehe19:35
kristianpaulsuspicious ;)19:35
rejonhttp://www.archive.org/details/MilkymistAtFirefoxReleasePartyChina&reCache=119:46
rejontoo bad: http://www.kickstarter.com/projects/1091976372/open-source-5-axis-cnc-router-and-plasma-machine-p?ref=email&ref=48hr20:26
rohwell.. us-only20:33
rohkickstarter hurts itself (and others) that way20:33
rejonyeah20:36
rejonmy buddies http://pledgie.com project better20:36
rejonfor international20:36
rohwel.. still paypal20:39
kristianpaulwin 1420:50
kristianpauloops20:50
CIA-43rtems-milkymist: Sebastien Bourdeauducq master * r8bec323 / c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c : New Ethernet driver - http://bit.ly/fkwu5y21:07
CIA-43flickernoise: Sebastien Bourdeauducq master * r399797a / src/main.c : Start shell early to debug startup problems - http://bit.ly/eWDUEF21:08
lekernelphew. no more ethernet crashes (there are still more minor bugs though)21:08
lekernel1 files changed, 398 insertions(+), 499 deletions(-)21:08
lekernel rewrite c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c (77%)21:08
lekernel--- 192.168.0.42 ping statistics ---21:12
lekernel78753 packets transmitted, 78753 received, 0% packet loss21:12
mwallewha too much backlog21:22
mwalleterpstra_: no im using gdb over serial directly21:23
mwalleterpstra_: what altera cable? i know the altera usb byteblaster which is basically a ftdi with some transistors as levelshifters21:23
mwallelekernel: you'll need a gdb patch21:24
mwallebut the connection should work sometimes21:24
mwallelekernel: http://sourceware.org/ml/gdb-patches/2011-04/msg00066.html21:25
lekernelmwalle: with this patch, it works reliably for you?21:25
mwallethe timing has met without any trouble for me21:25
mwalleyes21:25
mwalle[mw@thanatos ~]$ lm32-elf-gdb --version21:26
lekernelno timing problem? with normal bitstream (not rescue) and ISE 13.1?21:26
mwalleGNU gdb (GDB) 7.121:26
lekernelit pretty weird, ISE meets timing very easily for rescue bitstream and fails for normal21:26
mwallemaybe i should update the whole repository :)21:27
mwallebut im not using ise's own libraries21:27
lekernelhmm... could be a PRNG difference, I've seen something like that when running ISE under FreeBSD21:27
mwallehttp://paste.debian.net/113114/21:28
lekernelhow fast is it btw?21:29
mwalle115200 baud, 9kbs21:29
mwallealthough gdb supports 480xxx baud out of the box21:29
lekernelmaybe for later versions of the soc, it would make sense to support very high baudrate21:30
lekernellike 20Mbps on serial21:30
mwallethere are macros for baudrates up to 4mbit21:30
mwallethe chip supports 12mbit21:30
lekernelsuch baudrates would probably need something more clever than the current plain clock divider though21:31
mwalleand wont work with 16times oversamlping :)21:34
mwalle80/16/1 =  5mbit.. but i could not get it to work21:35
lekernelno... I have tried with the ML401... even some 400kbps had problems21:35
lekernel(but they could have been related to the level shifters or cable)21:35
mwalle480xxx worked at least with flterm the last time i tried21:35
mwallelekernel: could you try gdb again, enabling remote debug? (set debug remote on)21:35
mwalleshould print you the packets and responses21:35
lekernelsure. need to figure out again how to compile it first :p21:35
mwalleif you see sth like 'qSupported' with the same response, break hasnt worked and you are still on a shell (or some other echo service :)21:36
lekernelok to use gdb 7.2?21:37
mwallei hope so :)21:37
lekernelok, let's find out :)21:38
mwallebreakpoints and watchpoints work too, but watchpoint wont advance the PC, dunno why. or who is responsible to advance it. so i suggest to use singleshot watchpoints only :)21:40
lekernelah, much better :)21:43
lekernelcongratz :)21:43
lekernelbtw, if I use gcc -g and not strip the binary, the additional info should be removed by objcopy -Obinary, no?21:45
lekernelI'm thinking about always using -g for flickernoise builds, so we can fully exploit gdb :)21:46
lekernelif it doesn't bloat the final image that's perfect21:46
lekernelseems ok in fact :)21:46
lekernelwow, seems all gdb commands work21:49
lekernelthat's mighty cool21:49
lekerneleven p, step, etc. :))21:50
lekernelexcellent21:50
mwallelekernel: you specify the sections you want to copy, doesnt you?21:52
lekernelno21:53
lekernelbut still it seems to omit the debug info automatically21:53
lekernelso I'll just always put them in the ELF image I think21:53
mwalle$(OBJCOPY) $(SEGMENTS) -O binary $< $@21:53
mwallefor bios.bin21:54
mwalleSEGMENTS=-j .text -j .data -j .rodata21:54
lekernelflickernoise doesn't have this21:54
lekernelin fact I think it could be removed from the BIOS too :-)21:54
mwallemh ok, dunno what -Obinary copies by default :)21:54
lekernelgdb works really great in flickernoise21:55
lekernelwith symbols etc.21:55
lekernelthanks for that :)21:55
mwalleunfortunately theres no threadig support ;)21:55
lekernelit's still usable21:55
mwallebtw theres a pycon video about gdb and python support21:56
lekernelhttp://pastebin.com/Q1T7g4Z921:56
lekernelthat's what you get21:56
mwallenice :)21:58
Fallenouawesome :)21:59
mwallelekernel: btw theres no msd anymore :) could you send me a system/flickernoise image i can flash?22:03
mwallei still have the demo on my board ;)22:03
lekernelyeah i'll try to post complete soc+flickernoise images tonight22:07
lekernelor tomorrow morning22:07
mwallekk22:08
lekernelhopefully i'll manage to coax ISE into meeting timing ...22:09
lekernelwith striping and without -g: 1544220 raw binary image22:15
lekernelwith: the same22:15
lekernelso -Obinary just picks the right sections by default22:16
CIA-43rtems-milkymist: Sebastien Bourdeauducq master * r7715b83 / c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c : reduce scope - http://bit.ly/hjpLUD22:17
CIA-43flickernoise: Sebastien Bourdeauducq master * rd231b8e / src/Makefile : Add debug info to ELF image and do not strip - http://bit.ly/hKx0DM22:18
lekernelhmm... when loading a big image I get packet errors from time to time22:18
lekernel(gdb) load22:18
lekernel`/home/lekernel/Milkymist/flickernoise/src/bin/flickernoise' has changed; re-reading symbols.22:18
lekernelLoading section .boot, size 0x170 lma 0x4000000022:18
lekernelLoading section .init, size 0x1c lma 0x4000017022:18
lekernelLoading section .text, size 0x128298 lma 0x4000018c22:18
lekernelIgnoring packet error, continuing...22:18
mwalleplease enable debug22:18
lekernelhow do you do that?22:20
mwalleset debug remote 122:20
lekernelhttp://pastebin.com/yzzzGPKf22:22
lekernelthat's without the flterm passthrough22:23
mwalleyeah i can reproduce it here22:24
mwallehm maybe the max packet length is wrong22:25
mwallefor now you can set22:26
mwalleset remote memory-write-packet-size 50022:26
mwalleas a workaround22:26
lekernelseems to work :)22:28
lekernelbtw http://www.milkymist.org/wiki/index.php?title=Using_GDB_in-system_debugger22:28
lekernelok, dowloaded everything at 10k/s :)22:30
mwallei'll into that issue tomorrow22:30
mwallewe need a faster uart :)22:30
lekerneland continue restarts the app =]22:32
lekernelcool22:32
mwalleyeah load sets $pc iirc22:33
CIA-43milkymist: Michael Walle master * r63ef4c0 / tools/flterm.c : (log message trimmed)22:35
CIA-43milkymist: flterm: add gdbpassthrough support22:35
CIA-43milkymist: This patch adds support for GDB packets and serial console demuxing. To use22:35
CIA-43milkymist: it start flterm with --gdb-passthrough. Then start gdb and run the22:35
CIA-43milkymist: following commands:22:35
CIA-43milkymist:  set remote interrupt-on-connect on22:35
CIA-43milkymist:  target remote <pseudo terminal printed by flterm>22:35
CIA-43milkymist: Sebastien Bourdeauducq master * r00e9feb / tools/flterm.c : flterm: bump version number and update banner - http://bit.ly/ffSW7k22:37
mwallegn822:38
lekernelgn822:40
CIA-43rtems-milkymist: Sebastien Bourdeauducq master * r00d86d0 / c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c : ethernet: fix naming of TX/RX daemons - http://bit.ly/gjTftI23:10
CIA-43milkymist: Sebastien Bourdeauducq master * r26fba40 / boards/milkymist-one/synthesis/common.mak : Fix timing problems - http://bit.ly/fJkcML23:59
--- Wed Apr 6 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!