#milkymist IRC log for Saturday, 2011-11-12

wpwraklekernel: regressions ... actually, there is one: if you move MIDI controls quickly, you can saturate the CPU, so the the patch stops for a slit-second04:36
wpwraklekernel: before, this didn't happen so often, because MIDI desynchronized easily. (could also be the RTEMS got a little slower, but that seems less likely)04:37
wpwrakperhaps an improvement could be to move the processing we have in handle_midi_event to the MIDI driver in RTEMS. that might reduce the number of task switches04:44
wpwraklekernel: ah, one drawback of setting CPU_ALIGNMENT to 4 is that this could make doubles straddle cache lines, resulting in reduced performance06:09
wpwraknot sure whether CPU_ALIGNMENT is used anywhere where it it likely to meet doubles, though06:10
lekernel_there are very few doubles or int64's in the whole thing, and cache lines are 32 bytes anyway (not 8)09:26
lekernel_or 16 for L109:26
wpwrak(very few) yeah, that's what i though. malloc comes from milkymist/software/libbase ? or is this only without rtems ?10:02
wpwrak(cache line size) doesn't matter in that case. as long as you align with >= sizeof(double), you're fine (that is, as long as you even care). anything else would only be wasteful10:03
lekernel_libbase is only without rtems10:09
wpwrakhmm, and rtems malloc is _Protected_heap_Allocate. which in turn ...10:18
wpwrak... has no line number information, grmbl, ...10:19
wpwrak... is _Protected_heap_Allocate_aligned_with_boundary ...10:20
wpwrak... is _Heap_Allocate_aligned_with_boundary ...10:21
wpwrak... which aligns to "page_size" ...10:22
wpwrak... which is set by _Heap_Initialize and aligned to CPU_ALIGNMENT or worse ...10:24
wpwrak_Heap_Initialize comes from _Workspace_Handler_initialization and gets its alignment from CPU_HEAP_ALIGNMENT10:27
wpwrakman. why use C if what you really want is spread out things over as many files as possible ? :-(10:28
wpwrakso, unless i got lost somewhere, your malloc aligns with max(CPU_ALIGNMENT, CPU_HEAP_ALIGNMENT)10:29
wpwrakwe have CPU_HEAP_ALIGNMENT == CPU_ALIGNMENT10:30
wpwrakso malloc aligns to 4 byte boundaries10:31
wpwrakmeaning that all doubles, (u)int64_t, and long long have a 1:8 probability of straddling L2 lines and a 1:4 probability of straddling L1 lines. now, do we care ? :)10:33
mumptaihi10:34
xiangfumumptai, Hi10:36
lekernel_xiangfu: hi11:11
lekernel_can you add Werner's GDB patch to your build scripts?11:11
lekernel_wpwrak: no, we don't. doubles are super-slow anyway (soft-fp) and 64 bits ints also slow (software emulation too). and they're used only in a few places where performance doesn't matter, like printf etc.11:13
wpwrakgood :)11:13
lekernel_maybe there are int64's in time management functions... which could be used in a few places11:14
wpwrakbtw, any plans to add a hw FPU, given that you already have one ?11:14
lekernel_no, what for?11:14
wpwrakspeed ? :)11:14
lekernel_all the performance critical code is integer only, no?11:15
wpwrakafaik, each MIDI message means a floating-point division11:15
wpwrakwell, each control message11:16
lekernel_as you said... can be replaced with a LUT11:16
wpwrakyes, but you have to fill that LUT11:16
wpwrakand if you go 2D, that's 16 k entries. that may be noticeable.11:16
lekernel_computing 128 floating points at startup sounds like a few millisecond at worst11:17
lekernel_mh, why not use the same LUT?11:17
wpwrakbecause each value depends on 2 variables. see the sensitivity example.11:17
wpwrakso the LUT is [128][128]11:17
lekernel_just do the combination in PFPU11:17
lekernel_it's fast there11:17
wpwrakthat's an option, yes11:18
lekernel_perhaps even faster than LUT reads11:18
lekernel_well, not perhaps, I'm pretty sure about it11:18
wpwrakdepends on how complex the expression is ;-)11:18
lekernel_for your example, it certainly is faster11:18
wpwrakbut uses precious cycle and registers, both from a small pool11:19
lekernel_we can easily double the number of registers11:20
lekernel_or more11:20
wpwrakalso, the LUT would compete with the floating-point division (/127.0) in the CPU. so it still wins ;-)11:20
lekernel_and cycles... if that matters, we can load the PFPU program twice for per-frames11:21
lekernel_or even stream it from an arbitrarily large buffer in DRAM11:22
wpwrakah, that reminds me. variables are never carried from frame to frame, correct ? i.e., you couldn't implement an EWMA in per-frame equations. correct ?11:22
lekernel_user defined variables are carried from frame to frame11:22
wpwrak(arbitrarily large) yes, but then your FPS go down :)11:22
wpwrakgreat11:23
lekernel_for per-frames, it should be OK11:23
lekernel_think that the PFPU currently does about 32*32 times more work for per-vertex equations11:23
wpwrakokay :)11:23
lekernel_and you would save some CPU time as it won't have to copy memory into the PFPU buffer11:24
wpwrakmaybe you could even do them in parallel. while doing the vertices, already compute the next frame11:24
lekernel_it's already working in parallel11:24
wpwrakah, great11:24
lekernel_that's why the renderer uses several threads11:25
wpwrakhaven't looked at the renderer yet11:25
wpwrakhmm, slow-down with fast MIDI inputs is bad. that wants fixing. maybe start with a LUT ;-)11:28
wpwrakah, and what do you think about moving the MIDI message detection into the MIDI driver in RTEMS, so that you only get one message on midi_q for every message, not for every byte ?11:29
wpwrakwe still couldn't get rid of the midi thread (unless there's a way to make the MIDI driver put its data directly into input_q), but at least it wouldn't have to run quite so often11:30
wpwrakone more thing: what's the easiest way to measure FPS at the CPU ? with that information, i could set up an automated benchmark for MIDI performance. hammer the M1 with a machine-generated flow of control changes and see how the FPS go down11:32
lekernel_there's no FPS-meter in FN atm11:33
lekernel_there's one in the demo firmware... but didn't port it11:33
wpwrakso, number of frames then ?11:33
wpwrakHMM. where's that "frame" variable ? grep '"frame"' comes up empty11:36
lekernel_it's not there11:36
lekernel_ah, sorry11:37
wpwrakthe FN handbook says it is :)11:37
wpwrakshall i doubt your very writing ? :)11:38
lekernel_I don't remember if the frame variable is there or not11:39
lekernel_if it is, it's just time divided by some constant anyway11:39
wpwrakso ... what else can i use then ?11:40
lekernel_there's nothing to measure FPS in FN atm11:41
wpwrakall i need is the frame count. i can keep track of time on the outside easily enough and the interval will be sufficiently large for communication overhead to be irrelevant11:41
lekernel_in the demo firmware, it's done by counting the number of frames since the last second timer tick11:42
wpwrakso is there some frame count(er) ?11:42
lekernel_yes11:42
lekernel_for time11:42
lekernel_(the time variable)11:42
wpwrakoh :) so time isn't real time11:42
lekernel_no, it isn't (unless there are no dropped frames)11:42
wpwrakkewl. let's see ...11:43
wpwrakaha, in sampler_task. very convenient.11:44
lekernel_yes11:44
lekernel_but there's no frame counter11:44
lekernel_time += 1.0/FPS;11:44
lekernel_that's all it does11:44
lekernel_FPS is defined at 24, which in turns defines the size of the audio buffer used for each frame11:45
wpwrakwell, it's a frame counter that counts in units different from 1. that don't bother me :)11:46
lekernel_kewl, my LV3 just arrived11:46
wpwrakwow !11:46
wpwraknow, let's see how long until usb-midi ;-)11:47
lekernel_seems it's just sending MIDI data down a USB endpoint11:47
lekernel_like the usb-midi standard specifies (for once, they didn't invent some rube goldberg machine)11:48
wpwrak(no trickery) i'm almost disappointed ;-)11:48
wpwrakhow does the device feel ?11:48
lekernel_ah, there's a little trick: it sends a MIDI time message every millisecond, which we'll probably want to filter early11:52
wpwrakwe filter this already11:53
lekernel_yes, but in an inefficient way11:53
wpwrakas in "ignore"11:53
lekernel_i'd rather hardcode the filter into the navre firmware (see another advantage of not having OHCI? :)11:54
wpwrakis the protocol byte-based or message-based ?11:54
lekernel_message based11:54
wpwraknaw, don't put too much stuff into that navre11:54
wpwrakin the end you want ohci anyway11:54
lekernel_running the whole USB stack every millisecond to ignore timing messages sounds like a waste of cycles11:55
wpwrakthat's of course true ...11:55
wpwraki wonder what sort of interrupt rate i generate by jerking controls around. maybe in the order of 2-3 kHz11:57
wpwrakand that stalls the system (briefly)11:57
wpwrakbtw, where does that navre firmware live ? in the bitstream ?12:00
lekernel_no, it's loaded by the rtems driver12:20
lekernel_there is no software in the bitstream, except the gdbstub12:20
lekernel_we can't put it in the flash because there would be problems when breaking into GDB in the middle of a flash write12:21
wpwrakoh, nice ! it already looks friendlier ;-)12:21
wpwrak(gdbstub) and load it at run time ?12:22
lekernel_no, it's read-only from LM32 so bugs can't mess with it12:22
wpwrak;-)12:22
lekernel_though something like a "password" protection could be useful12:23
lekernel_or read-only after first write and until a full reset12:23
wpwrakyes, something like this. would be nice if it could be updated without having to make a new bitstream12:24
wpwrakwell, it's a minor issue12:24
lekernel_I like the option of a read only "fuse" in the gdbstub core12:24
lars_hm, isn't it already writable at a special address?12:25
lekernel_the BIOS can load the gdbstub and set that fuse, and it will stay set until next system reset12:25
wpwrakthe BIOS could even default to not setting the "fuse". make it optional in case you really really need it (which is probably never :)12:26
lars_or are we talking about different gdbstub roms?12:30
lekernel_there is a writable portion which is used for the gdbstub stack etc. but afaik it's initialized everytime you enter the stub12:38
lars_hm right12:39
lekernel_cool, mm soc still meets timing with ise 13.313:06
lekernel_RULE 3.4513:09
lekernel_If a SLAVE supports the [ERR_O] or [RTY_O] signals, then the SLAVE MUST NOT assert13:09
lekernel_more than one of the following signals at any time: [ACK_O], [ERR_O] or [RTY_O].13:09
lekernel_hmm... let's happily violate that... reading the source it seems LM32 doesn't care13:09
lekernel_when there is something interesting at opencores, then I will care about wishbone compliance13:10
lekernel_so, what part of the address space should I generate bus errors on? the biggest power of 2 smaller than the size of the standby partition?13:11
lars_what's the biggest struct size we expect to see?13:14
wpwraki'd be happy already with 4 kB. a bit more would be even better, of course.13:15
wpwrakthe largest i've seen so far (on M1) was around 3900 bytes13:15
wpwrakin linux anything much larger than a page is heavily frowned upon anyway13:15
wpwrakthe biggest power of two would be 512 kB. rather lavish :)13:17
lekernel_otoh this uses a smaller comparator13:17
wpwrakbut then, there's probably not much risk of erring on the large side. it would only matter if we decided we wanted to shrink the partition.13:17
lekernel_=> less resources and faster propagation time13:17
wpwrakso yes, i think 4 kB should catch virtually everything13:18
lekernel_the larger the locked address space, the fewer comparator bits13:18
wpwrakah, i see13:18
wpwrakokay, then 512 kB ;-)13:18
wpwrakstandby.fpg is 483 kB anyway, so we probably won't shrink it to the next smaller power of two anytime soon anyway13:20
lekernel_another thing... right now, the flash chip would still see writes13:21
wpwrakcatching them would be nice, of course13:21
lekernel_is that a problem?13:21
lekernel_there will be one write to the flash chip, but immediate execution of the gdbstub reporting a bus error13:22
wpwrakyou could still corrupt standby with writes13:22
wpwrakwhat happens if no gdb is around ?13:22
lekernel_freeze13:22
lekernel_and nothing happens13:22
wpwrakokay, then the risk would be minimal. it would need something else to help with causing the trouble.13:23
wpwrakregarding freeze, it would be good if software could catch the exception and produce a stack trace or such13:23
wpwrake.g., on Linux this is VERY useful13:24
lars_shouldn't it genreate a exception?13:24
lars_DataBusError?13:25
lekernel_yes13:25
lekernel_software can catch it13:25
wpwrakperfect13:26
lekernel_ERROR:HDLCompiler:69 - "/home/lekernel/Milkymist/milkymist/cores/lm32/rtl/lm32_cpu.v" Line 2590: <reset_exception> is not declared.13:27
lekernel_meh13:27
lekernel_that's lattice code13:27
lekernel_ok, bitstream with bus errors compiling now ...13:28
wpwraki'm kinda curious about how far the system will make it before hitting a bus error ;-)13:38
lekernelyay, it still met timing13:43
lekernelnow let's see if my UrJTAG is still working with F16 libusb...13:44
lekernelof course not!13:45
lekernel*** glibc detected *** jtag: realloc(): invalid pointer: 0x08671d08 ***13:45
wpwrak(timing) still room for the MMU then ;-)13:45
lekernelgrmbl...13:45
wpwrak"never upgrade a running system" ? ;-)13:45
lekernelwhen is urjtag going to release a new version anyway?13:47
lekerneltheir last one was in april 2009 and tons of stuff has been added since then, like FPGA programming support and the M1 cable13:47
lars_lekernel: where can i see how changes I do to the hdl affect timing?13:54
lekernelsynthesize it13:54
lars_well, yes, but where is the report13:56
lars_there are like millions of lines scrolling by13:56
lars_i don't really know what i'm looking for13:56
lekerneljust at the end at the p&r, it should say "All constraints were met"13:58
lekernelyou have some details just above13:58
lekerneland you can use "make timing" for more details (generates a .twr file)13:58
lars_ok, thanks13:58
lekernelis there any way to cherry-pick one commit from the CURRENT branch into another branch without switching to that other branch (which would disrupt the synthesis currently running)?14:05
lars_i don't think so14:11
lekernel...and of course, the BIOS contains all NOPs for bus error exception vectors, so they fall through the ISR and nothing seems to happen14:55
lekerneleven dividing by zero in the BIOS runs the ISR! yay!14:59
lekernelI guess the RTEMS CRT will deserve a little review too ...15:02
wpwrak;-))15:16
wpwraki wonder how many new bug reports RTEMS will collect after the addition of this NULL pointer catcher ;-)15:17
lekernelyay, works15:26
lekernellet's try booting15:26
lekernelhe, i'm rendering a patch now :p15:27
lekernelit's not _that_ bad15:27
wpwrakwhee ! :)15:27
wpwraknow, try forcing a NULL pointer access15:27
wpwrak(not _that_ bad) yes,i've been running with watchpoints from 0x0-0xf, and nothing crept up. this already covers the most likely locations.15:29
lekernelyeah, I was doing that from the BIOS with the mr command15:29
lekernelbut nothing was happening because the bus error vector ran the ISR ...15:30
lekernelnow it's correctly catching the access15:30
lekernelwpwrak: want the bitfile?15:32
GitHub130[milkymist] sbourdeauducq pushed 3 new commits to v1.0: http://git.io/DQhTpg15:35
GitHub130[milkymist/v1.0] Drive PHY reset when Ethernet is disabled - Sebastien Bourdeauducq15:35
GitHub130[milkymist/v1.0] BIOS: sanitize exception vectors - Sebastien Bourdeauducq15:35
GitHub130[milkymist/v1.0] Generate bus errors on the first 512KB to catch NULL pointers - Sebastien Bourdeauducq15:35
GitHub46[milkymist] sbourdeauducq pushed 3 new commits to master: http://git.io/gRALOA15:35
GitHub46[milkymist/master] Drive PHY reset when Ethernet is disabled - Sebastien Bourdeauducq15:35
GitHub46[milkymist/master] BIOS: sanitize exception vectors - Sebastien Bourdeauducq15:35
GitHub46[milkymist/master] Generate bus errors on the first 512KB to catch NULL pointers - Sebastien Bourdeauducq15:35
mwalle(gdbstub) imho that should remain in the bitstream, so you could even load a bios from gdb (yeah theres still ram init missing, but thats on my todo list). and the gdbstub should be more or less stable ;)15:49
wpwrakmwalle: oh, i wasn't thinking of kicking it out. just of adding the possibility to update it easily16:05
mwalleah, ok. makes sense16:06
lekernelThe XADC includes a dual 12-bit, 1 Mega sample per second (MSPS) ADC and on-chip sensors. These ADCs are17:52
lekernelfully tested and specified (see the respective 7 series FPGAs data sheet).17:52
lekernellol17:52
lekernelreminiscences of the virtex4 XADC fuckup I guess :)17:53
lekernelanyway, I was looking for the primitive component for the hard DRAM PHY in kintex7... but I don't find it. would it be undocumented?17:57
lekernelhttp://www.xilinx.com/support/documentation/sw_manuals/xilinx13_3/7series_hdl.pdf17:58
lekernelah, it's called PHASER_IN and PHASER_OUT, and it's, indeed, undocumented18:10
lekerneltheir verilog models are even encrypted, nice!18:10
stekernisn't that the case for the spartan6 MCBs too?18:12
lekernelyes, same thing18:12
lekernelbut the S6 MCB is crappy anyway, I won't use it already simply for technical reasons18:12
stekernwhat is crappy about it (I'm not saying it's not, just asking out of curiousity)18:21
lekernelhttp://www.xilinx.com/support/answers/42026.htm18:22
lekernelhigh latency and buggy18:22
lekerneland not very flexible18:25
lekernelftp://ftp.macrogroup.ru/DigiEl/Xilinx/XLX_Seminar_NewElectronics/7series_Clocking_SelectIO_Tech_Module_Thomas_Klein.pdf18:30
lekernellooks much better than the MCB18:30
lekernelok, let me grab another kind of phaser to fire at the encryption =]18:31
wpwraklekernel: the new soc.fpg ? yes, please ! :)18:42
wpwrakby the way, about your idea to increase the color depth, are there enough memory bandwidth reserves to support this (at the current resolution) ?18:54
lekernelno, we'd have to increase memory frequency18:55
wpwraki this possible with the current M1 hardware ?18:55
wpwraks/i/is/18:56
lekerneltheoretically18:56
wpwrakheh :)18:56
wpwrakbtw, how is the LV3 ? does it feel "right" ?19:08
wpwraki'll still have to wait a week or so to get mine ... :(19:09
lekernelyeah, it looks good, and the mech controls are nice19:09
lekernelI haven't tried to really use it though19:09
lekernelthe first thing I did was look at the USB packets in wireshark while playing with the controls ;)19:09
wpwrakheh ;-)19:09
wpwrakyou should already be able to play with it via OSC and with my "X2" patch. (actually, that one needs a better name - i was thinking of "Tornado (Rain Dance MIDI RMX)")19:11
wpwrak(rmx) but it's still short of a few features. e.g., a don't like the color "path" and i need to add that distortion button19:12
wpwraks/a don't/i don't/  # grmbl. having a hard time completely waking up from that siesta19:13
wpwraki think the next feature needed will then be a lot more midiX variables :)19:13
wpwrakah, one advantage of a higher display resolution would be that also heavily iterated patterns would be less coarse when they reach the outside19:32
wpwrak(i'm just watching my patch run on autopilot for a day or so, to see if we have any other performance regressions)19:33
wpwrakwolfspraul: have you seen the movie "Borat" ? (full title: "Borat: Cultural Learnings of America for Make Benefit Glorious Nation of Kazakhstan")19:54
wpwrakwolfspraul: that path the M1 to faderfox is taking reminds me a bit of that borat's voyage to the US ;-)19:55
wpwrakbtw, does MTK or a variant with the same API run natively on Linux/X11 ?20:29
lekernelnope... but MTK itself runs easily on any platform20:31
lekernelit's plain C, you initialize it with a framebuffer address, you feed events to it and voila20:31
lekernelit doesn't contain any platform specific code20:31
wpwrakmmh. not so easy in a windowed environment then, without some glue. well, perhaps one could use SDL as glue.20:34
lekernelthat phaser looks like a very nice design. when you assemble all its components correctly, it seems you merely have to tell it when you are issuing SDRAM transactions, and it takes care of all the pesky details... you read/write the data synchronously20:34
wpwrakwould the original GeodeFX (?) toolkit be a better starting point for something like this than MTK ?20:35
wpwrak(phaser) sounds boring ;-)20:35
lekernelHPDMC has a similar module, so I'm not in unknown land :) the phaser is just a lot more complex20:35
lekernelgenode fx also has the windowing tightly integrated... I did not touch that part20:37
wpwrakah, that sounds even worse then20:37
lekernelwell, the future is multitouch anyway :) this will need a whole new GUI system20:38
lekerneland I don't see either how it can be integrated with X20:38
lekernelnot even sure I want that20:38
mwallelekernel: is that phaser thingy a single primitive or a predefined bunch of them?20:40
lekernelthere's PHASER_IN, PHASER_OUT and PHY_CONTROL20:41
lekernelthey're part of the clock management tiles which they moved close to the I/Os and SERDES20:42
lekernelthis file explains it nicely: ftp://ftp.macrogroup.ru/DigiEl/Xilinx/XLX_Seminar_NewElectronics/7series_Clocking_SelectIO_Tech_Module_Thomas_Klein.pdf20:42
mwalle(midi events) is it possible to combine multiple events (from the same control) into one event, to reduce cpu load? eg only the latest position for a slider may be interesting20:44
wpwrakhmmm .. just having a look at softusb-input/main.c ... so you've hard-coded the endpoint numbers ?20:45
wpwrak(instead of picking them from the endpoint descriptor)20:45
lekernelyeah... that should be fixed of course20:46
wpwrakof course ...20:46
lekernelbut I find this kind of messing around with endpoint numbers utterly boring20:46
wpwraki now see a lot more clearly about all those keyboards that some some magic reason don't work ;-)20:46
lekerneloh, sure20:46
lekernelthere's that, and lack of hub support, and lack of composite device support20:47
lekernelwell, don't get me started again on USB :)20:47
wpwraki think composite devices are rare birds. but there's devices with multiple interfaces that would be reasonably friendly.20:48
wpwrakof course, they won't work with hard-coded EP numbers ;-)20:49
mwalleThe Phaser blocks are reserved for Xilinx IP use only and are not available to20:50
mwallethe user.20:50
mwallenice ;)20:50
wpwrakmwalle: so this means that, when we make use of it, Xilinx will have GPLed IP for those blocks. nice :)20:52
lekernelmwalle: http://lekernel.net/re.jpg (from azonenberg :)20:53
azonenberglekernel: lol, glad to see you like it20:53
mwallewpwrak: if ise will allow us to use it?20:53
wpwrak(reverse engineering) sweet ;-)20:54
lekernelsure it will ... xilinx core generator uses it20:54
lekerneland this thing operates at the netlist level... if xst blocks it (but I think it won't), we can always edit the netlist20:55
wpwrakwolfspraul: this would be a great theme to start the upcoming quarterly news !20:55
wpwrak(reverse engineering) actually, i've never quite put so much effort into writing clear and detailed documentation as when presenting the findings of some reverse engineering ;-)20:57
azonenberglol21:00
wpwrakbtw, aren't hubs kinda transparent ? but let me guess ... it's because the device address is hard-coded, too ?21:08
lekernelmaybe :)21:10
wpwrakelevenbits .. @#*%!21:13
lekernelwpwrak: ah... see!21:13
lekernelit took me two weeks to get those damn eleven bits (and their CRC) right21:14
lekernelthis is utterly frustrating when I can develop a PS/2 controller in 30 minutes21:15
wpwraki understand. spending the extra hour to use them properly would have just been too much ....21:16
lekernelalso, I was using the Opencrap USB PHY at that time, which also added its share of bugs21:16
lekernel:) exactly21:16
lekernelbtw, if you want a quick test, try the demo firmware21:17
wpwrak0a81:0101 Chesen Electronics Corp. Keyboard ... bEndpointAddress     0x82  EP 2 IN ... that looks promising21:17
wpwraklet's see if the M1 hates it21:17
lekernelotherwise you have to update the header in RTEMS and rebuild it21:18
wpwrakah no, it doens't. funny21:18
Action: wpwrak wonders where that meme comes from that you have to AND away any bits that wouldn't fit into the target variable. pascal ?21:22
Action: wpwrak like out[1] = elevenbits & 0xff; // out is unsigned char *21:22
wpwrakah, 0x81 is address 1, EP 2. okay. that rhymes.21:23
wpwraklekernel: what's you plan with making usb-midi work ? have you already started to make changes ?21:25
lekernelno, I have not21:25
wpwrakgood. planning to start today ? or having other plans ?21:25
lekernelthis will come after the "bugfix" release... I have a few other things to fix too21:25
lekernel backport upstream RTEMS support21:26
wpwrakokay. then i can have a bit of fun with USB ...21:26
wpwrakwhat do you plan to backport ?21:27
lekerneland little things like http://www.milkymist.org/wiki/index.php?title=Flickernoise_roadmap#1.021:27
lekernelthere are a few things in FN that need to be changed to support RTEMS and YAFFS upstream21:27
lekernelthis is done in the master branch, but I holded back those changes in the stable_1.0 branch because of the lag bug21:27
lekernel(and another interrupt bug that I fixed)21:28
wpwrakah, so then there are some bugs i haven't found yet ;-)21:28
lekernelhm?21:28
wpwraki'm now running master with rtems cvs. so, if i understand correctly, i don't have these fixes21:29
lekernelwhat? the interrupt bug?21:29
wpwrakyes21:30
lekernelyou have the fix21:30
lekernelit was committed in August I think21:30
lekerneland the old RTEMS code didn't have it21:30
wpwrakno i'm confused :)21:30
lekernel(old = RTEMS checkout from summer 2010 + MM support patches, which is what the stable_1.0 branch is using atm)21:31
wpwrakare you planning to stay on stable_1.0 ? or move forward to RTEMS head ?21:31
lekernelmove everything to RTEMS head21:31
lekernelincluding stable_1.021:31
wpwrakexcellent21:31
lekerneleasier to maintain, less confusing :)21:31
wpwrakbut stable_1.0 = master - things needed for RTEMS head, no ?21:31
wpwrak(more or less)21:32
lekernelatm yes21:32
wpwrakto what needs backporting then ? :)21:32
lekernelwell... I just mean applying the changes to that branch as well and do some testing21:33
lekernelseems you're already doing the latter though :)21:33
wpwrak(easier to maintain) yes. keeping a gazillion of "stable" branches alive is madness. and we don't have nearly enough bored people sitting around for this21:33
lekernelyes sure21:33
lekernelI just want to apply the bugfixes and push out a new release. then I probably won't touch the stable branch again21:34
wpwrakah, so you do plan to update stable_1.0. i see.21:34
wpwraki'd just let it rot and go with the latest ;-) of course, xiangfu will have kittens when we bring him up to speed on monday. "look, we've changed everything !" :)21:36
lekerneljust _one_ update21:37
lekernelthen it will rot21:37
wpwrakalright, you're more scrupulous than me ;-)21:38
wpwraknow .. let's see if i can make heads and tails of why some of my USB keyboards work and others not ...21:39
lekernelwe'll soon need a 3rd USB port on that M1 ...21:41
wpwraki told you i want four ;-)21:41
lars_and i want otg21:51
lars_;)21:52
wpwrakah .. EP1 after all. hmm. that weird ACME keyboard has an undocumented EP2. how queer :)21:52
wpwrakUSB 3.0 !!21:52
wpwraknice. connecting my HHKB Pro throws the M1 straight into standby. i think it didn't do this before the reset rework. those extra 0.4 V will be put to good use :)22:18
wpwrakand one of my mice sends weird clicks when dumping its descriptors. M1 is happy with it, though22:18
wpwraknow .. what do i do to make FN pick up the new softusb-input.bin ? there's no "make install" in softusb-input/22:36
wpwrakokay, it goes into libhal ... but there's nothing that moves libhal.a22:46
wpwrakah, software/bios/Makefile ...22:47
wpwrakhow about killing that silly "demo" binary ? ;-) that would let us simplify the build process quite a lot22:50
wpwrakand here we go again. after trying a large set of HID devices on my PC, the mouse finally went berserk23:09
wpwraklekernel: thanks for the new bitstream ! works like a charm23:18
wpwrakgrmbl. when i build my own bios, all i get is a newline on the serial console :-(23:24
wpwrakboth with building "manually" and when using build_bios.sh23:26
wpwrakcan i reload navre from FN ? :)23:29
lekernelwpwrak: FN doesn't use libhal. you have to modify the header in rtems and rebuild.23:43
lekernelif you use the demo it should be automatic23:43
wpwrakwhat header do i need to modify in rtems ?23:45
lekerneland I don't see how that "silly" demo binary makes the build process significantly more complex23:45
lekernelyou can just ignore it23:45
lekernelsomething like c/libbsp/lm32/shared/milkymist_usbinput/softusb.h23:46
wpwrak(demo) seems that a few things could move from milkymist.git into flickernoise.git if it wasn't for the demo23:46
lekernel?23:46
lekernellike what?23:46
wpwrakoh, that's where the navre goes. so i don't need to replace the bios. nice.23:47
wpwraklike the patch compiler23:47
wpwrakwell, parts of it. some of it is already there23:48
wpwrakheh, diff of softusb-input.h - completely different ;-) that'll be fun23:51
wpwrakexcellent. USB still works. now, let's change something23:57
wolfspra1l[hhkb pro into standby] hmm. that means the 4.4v reset ic is definitely a no-go?23:57
--- Sun Nov 13 201100:00

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