<wpwrak>
lekernel: regressions ... actually, there is one: if you move MIDI controls quickly, you can saturate the CPU, so the the patch stops for a slit-second
<wpwrak>
lekernel: 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)
<wpwrak>
perhaps 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 switches
<wpwrak>
lekernel: ah, one drawback of setting CPU_ALIGNMENT to 4 is that this could make doubles straddle cache lines, resulting in reduced performance
<wpwrak>
not sure whether CPU_ALIGNMENT is used anywhere where it it likely to meet doubles, though
<lekernel_>
there are very few doubles or int64's in the whole thing, and cache lines are 32 bytes anyway (not 8)
<lekernel_>
or 16 for L1
<wpwrak>
(very few) yeah, that's what i though. malloc comes from milkymist/software/libbase ? or is this only without rtems ?
<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 wasteful
<lekernel_>
libbase is only without rtems
<wpwrak>
hmm, and rtems malloc is _Protected_heap_Allocate. which in turn ...
<wpwrak>
... has no line number information, grmbl, ...
<wpwrak>
... is _Protected_heap_Allocate_aligned_with_boundary ...
<wpwrak>
... is _Heap_Allocate_aligned_with_boundary ...
<wpwrak>
... which aligns to "page_size" ...
<wpwrak>
... which is set by _Heap_Initialize and aligned to CPU_ALIGNMENT or worse ...
<wpwrak>
_Heap_Initialize comes from _Workspace_Handler_initialization and gets its alignment from CPU_HEAP_ALIGNMENT
<wpwrak>
man. why use C if what you really want is spread out things over as many files as possible ? :-(
<wpwrak>
so, unless i got lost somewhere, your malloc aligns with max(CPU_ALIGNMENT, CPU_HEAP_ALIGNMENT)
<wpwrak>
we have CPU_HEAP_ALIGNMENT == CPU_ALIGNMENT
<wpwrak>
so malloc aligns to 4 byte boundaries
<wpwrak>
meaning 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 ? :)
<mumptai>
hi
<xiangfu>
mumptai, Hi
<lekernel_>
xiangfu: hi
<lekernel_>
can you add Werner's GDB patch to your build scripts?
<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.
<wpwrak>
good :)
<lekernel_>
maybe there are int64's in time management functions... which could be used in a few places
<wpwrak>
btw, any plans to add a hw FPU, given that you already have one ?
<lekernel_>
no, what for?
<wpwrak>
speed ? :)
<lekernel_>
all the performance critical code is integer only, no?
<wpwrak>
afaik, each MIDI message means a floating-point division
<wpwrak>
well, each control message
<lekernel_>
as you said... can be replaced with a LUT
<wpwrak>
yes, but you have to fill that LUT
<wpwrak>
and if you go 2D, that's 16 k entries. that may be noticeable.
<lekernel_>
computing 128 floating points at startup sounds like a few millisecond at worst
<lekernel_>
mh, why not use the same LUT?
<wpwrak>
because each value depends on 2 variables. see the sensitivity example.
<wpwrak>
so the LUT is [128][128]
<lekernel_>
just do the combination in PFPU
<lekernel_>
it's fast there
<wpwrak>
that's an option, yes
<lekernel_>
perhaps even faster than LUT reads
<lekernel_>
well, not perhaps, I'm pretty sure about it
<wpwrak>
depends on how complex the expression is ;-)
<lekernel_>
for your example, it certainly is faster
<wpwrak>
but uses precious cycle and registers, both from a small pool
<lekernel_>
we can easily double the number of registers
<lekernel_>
or more
<wpwrak>
also, the LUT would compete with the floating-point division (/127.0) in the CPU. so it still wins ;-)
<lekernel_>
and cycles... if that matters, we can load the PFPU program twice for per-frames
<lekernel_>
or even stream it from an arbitrarily large buffer in DRAM
<wpwrak>
ah, 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 ?
<lekernel_>
user defined variables are carried from frame to frame
<wpwrak>
(arbitrarily large) yes, but then your FPS go down :)
<wpwrak>
great
<lekernel_>
for per-frames, it should be OK
<lekernel_>
think that the PFPU currently does about 32*32 times more work for per-vertex equations
<wpwrak>
okay :)
<lekernel_>
and you would save some CPU time as it won't have to copy memory into the PFPU buffer
<wpwrak>
maybe you could even do them in parallel. while doing the vertices, already compute the next frame
<lekernel_>
it's already working in parallel
<wpwrak>
ah, great
<lekernel_>
that's why the renderer uses several threads
<wpwrak>
haven't looked at the renderer yet
<wpwrak>
hmm, slow-down with fast MIDI inputs is bad. that wants fixing. maybe start with a LUT ;-)
<wpwrak>
ah, 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 ?
<wpwrak>
we 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 often
<wpwrak>
one 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 down
<lekernel_>
there's no FPS-meter in FN atm
<lekernel_>
there's one in the demo firmware... but didn't port it
<wpwrak>
so, number of frames then ?
<wpwrak>
HMM. where's that "frame" variable ? grep '"frame"' comes up empty
<lekernel_>
it's not there
<lekernel_>
ah, sorry
<wpwrak>
the FN handbook says it is :)
<wpwrak>
shall i doubt your very writing ? :)
<lekernel_>
I don't remember if the frame variable is there or not
<lekernel_>
if it is, it's just time divided by some constant anyway
<wpwrak>
so ... what else can i use then ?
<lekernel_>
there's nothing to measure FPS in FN atm
<wpwrak>
all 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 irrelevant
<lekernel_>
in the demo firmware, it's done by counting the number of frames since the last second timer tick
<wpwrak>
so is there some frame count(er) ?
<lekernel_>
yes
<lekernel_>
for time
<lekernel_>
(the time variable)
<wpwrak>
oh :) so time isn't real time
<lekernel_>
no, it isn't (unless there are no dropped frames)
<wpwrak>
kewl. let's see ...
<wpwrak>
aha, in sampler_task. very convenient.
<lekernel_>
yes
<lekernel_>
but there's no frame counter
<lekernel_>
time += 1.0/FPS;
<lekernel_>
that's all it does
<lekernel_>
FPS is defined at 24, which in turns defines the size of the audio buffer used for each frame
<wpwrak>
well, it's a frame counter that counts in units different from 1. that don't bother me :)
<lekernel_>
kewl, my LV3 just arrived
<wpwrak>
wow !
<wpwrak>
now, let's see how long until usb-midi ;-)
<lekernel_>
seems it's just sending MIDI data down a USB endpoint
<lekernel_>
like the usb-midi standard specifies (for once, they didn't invent some rube goldberg machine)
<wpwrak>
(no trickery) i'm almost disappointed ;-)
<wpwrak>
how does the device feel ?
<lekernel_>
ah, there's a little trick: it sends a MIDI time message every millisecond, which we'll probably want to filter early
<wpwrak>
we filter this already
<lekernel_>
yes, but in an inefficient way
<wpwrak>
as in "ignore"
<lekernel_>
i'd rather hardcode the filter into the navre firmware (see another advantage of not having OHCI? :)
<wpwrak>
is the protocol byte-based or message-based ?
<lekernel_>
message based
<wpwrak>
naw, don't put too much stuff into that navre
<wpwrak>
in the end you want ohci anyway
<lekernel_>
running the whole USB stack every millisecond to ignore timing messages sounds like a waste of cycles
<wpwrak>
that's of course true ...
<wpwrak>
i wonder what sort of interrupt rate i generate by jerking controls around. maybe in the order of 2-3 kHz
<wpwrak>
and that stalls the system (briefly)
<wpwrak>
btw, where does that navre firmware live ? in the bitstream ?
<lekernel_>
no, it's loaded by the rtems driver
<lekernel_>
there is no software in the bitstream, except the gdbstub
<lekernel_>
we can't put it in the flash because there would be problems when breaking into GDB in the middle of a flash write
<wpwrak>
oh, nice ! it already looks friendlier ;-)
<wpwrak>
(gdbstub) and load it at run time ?
<lekernel_>
no, it's read-only from LM32 so bugs can't mess with it
<wpwrak>
;-)
<lekernel_>
though something like a "password" protection could be useful
<lekernel_>
or read-only after first write and until a full reset
<wpwrak>
yes, something like this. would be nice if it could be updated without having to make a new bitstream
<wpwrak>
well, it's a minor issue
<lekernel_>
I like the option of a read only "fuse" in the gdbstub core
<lars_>
hm, isn't it already writable at a special address?
<lekernel_>
the BIOS can load the gdbstub and set that fuse, and it will stay set until next system reset
<wpwrak>
the BIOS could even default to not setting the "fuse". make it optional in case you really really need it (which is probably never :)
<lars_>
or are we talking about different gdbstub roms?
<lekernel_>
there is a writable portion which is used for the gdbstub stack etc. but afaik it's initialized everytime you enter the stub
<lars_>
hm right
<lekernel_>
cool, mm soc still meets timing with ise 13.3
<lekernel_>
RULE 3.45
<lekernel_>
If a SLAVE supports the [ERR_O] or [RTY_O] signals, then the SLAVE MUST NOT assert
<lekernel_>
more than one of the following signals at any time: [ACK_O], [ERR_O] or [RTY_O].
<lekernel_>
hmm... let's happily violate that... reading the source it seems LM32 doesn't care
<lekernel_>
when there is something interesting at opencores, then I will care about wishbone compliance
<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?
<lars_>
what's the biggest struct size we expect to see?
<wpwrak>
i'd be happy already with 4 kB. a bit more would be even better, of course.
<wpwrak>
the largest i've seen so far (on M1) was around 3900 bytes
<wpwrak>
in linux anything much larger than a page is heavily frowned upon anyway
<wpwrak>
the biggest power of two would be 512 kB. rather lavish :)
<lekernel_>
otoh this uses a smaller comparator
<wpwrak>
but 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.
<lekernel_>
=> less resources and faster propagation time
<wpwrak>
so yes, i think 4 kB should catch virtually everything
<lekernel_>
the larger the locked address space, the fewer comparator bits
<wpwrak>
ah, i see
<wpwrak>
okay, then 512 kB ;-)
<wpwrak>
standby.fpg is 483 kB anyway, so we probably won't shrink it to the next smaller power of two anytime soon anyway
<lekernel_>
another thing... right now, the flash chip would still see writes
<wpwrak>
catching them would be nice, of course
<lekernel_>
is that a problem?
<lekernel_>
there will be one write to the flash chip, but immediate execution of the gdbstub reporting a bus error
<wpwrak>
you could still corrupt standby with writes
<wpwrak>
what happens if no gdb is around ?
<lekernel_>
freeze
<lekernel_>
and nothing happens
<wpwrak>
okay, then the risk would be minimal. it would need something else to help with causing the trouble.
<wpwrak>
regarding freeze, it would be good if software could catch the exception and produce a stack trace or such
<wpwrak>
e.g., on Linux this is VERY useful
<lars_>
shouldn't it genreate a exception?
<lars_>
DataBusError?
<lekernel_>
yes
<lekernel_>
software can catch it
<wpwrak>
perfect
<lekernel_>
ERROR:HDLCompiler:69 - "/home/lekernel/Milkymist/milkymist/cores/lm32/rtl/lm32_cpu.v" Line 2590: <reset_exception> is not declared.
<lekernel_>
meh
<lekernel_>
that's lattice code
<lekernel_>
ok, bitstream with bus errors compiling now ...
<wpwrak>
i'm kinda curious about how far the system will make it before hitting a bus error ;-)
<lekernel>
yay, it still met timing
<lekernel>
now let's see if my UrJTAG is still working with F16 libusb...
<lekernel>
when is urjtag going to release a new version anyway?
<lekernel>
their last one was in april 2009 and tons of stuff has been added since then, like FPGA programming support and the M1 cable
<lars_>
lekernel: where can i see how changes I do to the hdl affect timing?
<lekernel>
synthesize it
<lars_>
well, yes, but where is the report
<lars_>
there are like millions of lines scrolling by
<lars_>
i don't really know what i'm looking for
<lekernel>
just at the end at the p&r, it should say "All constraints were met"
<lekernel>
you have some details just above
<lekernel>
and you can use "make timing" for more details (generates a .twr file)
<lars_>
ok, thanks
<lekernel>
is 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)?
<lars_>
i don't think so
<lekernel>
...and of course, the BIOS contains all NOPs for bus error exception vectors, so they fall through the ISR and nothing seems to happen
<lekernel>
even dividing by zero in the BIOS runs the ISR! yay!
<lekernel>
I guess the RTEMS CRT will deserve a little review too ...
<wpwrak>
;-))
<wpwrak>
i wonder how many new bug reports RTEMS will collect after the addition of this NULL pointer catcher ;-)
<lekernel>
yay, works
<lekernel>
let's try booting
<lekernel>
he, i'm rendering a patch now :p
<lekernel>
it's not _that_ bad
<wpwrak>
whee ! :)
<wpwrak>
now, try forcing a NULL pointer access
<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.
<lekernel>
yeah, I was doing that from the BIOS with the mr command
<lekernel>
but nothing was happening because the bus error vector ran the ISR ...
<lekernel>
now it's correctly catching the access
<lekernel>
wpwrak: want the bitfile?
<GitHub130>
[milkymist] sbourdeauducq pushed 3 new commits to v1.0: http://git.io/DQhTpg
<GitHub130>
[milkymist/v1.0] Drive PHY reset when Ethernet is disabled - Sebastien Bourdeauducq
<GitHub46>
[milkymist/master] Generate bus errors on the first 512KB to catch NULL pointers - Sebastien Bourdeauducq
<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 ;)
<wpwrak>
mwalle: oh, i wasn't thinking of kicking it out. just of adding the possibility to update it easily
<mwalle>
ah, ok. makes sense
<lekernel>
The XADC includes a dual 12-bit, 1 Mega sample per second (MSPS) ADC and on-chip sensors. These ADCs are
<lekernel>
fully tested and specified (see the respective 7 series FPGAs data sheet).
<lekernel>
lol
<lekernel>
reminiscences of the virtex4 XADC fuckup I guess :)
<lekernel>
anyway, I was looking for the primitive component for the hard DRAM PHY in kintex7... but I don't find it. would it be undocumented?
<lekernel>
ok, let me grab another kind of phaser to fire at the encryption =]
<wpwrak>
lekernel: the new soc.fpg ? yes, please ! :)
<wpwrak>
by the way, about your idea to increase the color depth, are there enough memory bandwidth reserves to support this (at the current resolution) ?
<lekernel>
no, we'd have to increase memory frequency
<wpwrak>
i this possible with the current M1 hardware ?
<wpwrak>
s/i/is/
<lekernel>
theoretically
<wpwrak>
heh :)
<wpwrak>
btw, how is the LV3 ? does it feel "right" ?
<wpwrak>
i'll still have to wait a week or so to get mine ... :(
<lekernel>
yeah, it looks good, and the mech controls are nice
<lekernel>
I haven't tried to really use it though
<lekernel>
the first thing I did was look at the USB packets in wireshark while playing with the controls ;)
<wpwrak>
heh ;-)
<wpwrak>
you 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)")
<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 button
<wpwrak>
s/a don't/i don't/Â Â # grmbl. having a hard time completely waking up from that siesta
<wpwrak>
i think the next feature needed will then be a lot more midiX variables :)
<wpwrak>
ah, one advantage of a higher display resolution would be that also heavily iterated patterns would be less coarse when they reach the outside
<wpwrak>
(i'm just watching my patch run on autopilot for a day or so, to see if we have any other performance regressions)
<wpwrak>
wolfspraul: have you seen the movie "Borat" ? (full title: "Borat: Cultural Learnings of America for Make Benefit Glorious Nation of Kazakhstan")
<wpwrak>
wolfspraul: that path the M1 to faderfox is taking reminds me a bit of that borat's voyage to the US ;-)
<wpwrak>
btw, does MTK or a variant with the same API run natively on Linux/X11 ?
<lekernel>
nope... but MTK itself runs easily on any platform
<lekernel>
it's plain C, you initialize it with a framebuffer address, you feed events to it and voila
<lekernel>
it doesn't contain any platform specific code
<wpwrak>
mmh. not so easy in a windowed environment then, without some glue. well, perhaps one could use SDL as glue.
<lekernel>
that 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 synchronously
<wpwrak>
would the original GeodeFX (?) toolkit be a better starting point for something like this than MTK ?
<wpwrak>
(phaser) sounds boring ;-)
<lekernel>
HPDMC has a similar module, so I'm not in unknown land :) the phaser is just a lot more complex
<lekernel>
genode fx also has the windowing tightly integrated... I did not touch that part
<wpwrak>
ah, that sounds even worse then
<lekernel>
well, the future is multitouch anyway :) this will need a whole new GUI system
<lekernel>
and I don't see either how it can be integrated with X
<lekernel>
not even sure I want that
<mwalle>
lekernel: is that phaser thingy a single primitive or a predefined bunch of them?
<lekernel>
there's PHASER_IN, PHASER_OUT and PHY_CONTROL
<lekernel>
they're part of the clock management tiles which they moved close to the I/Os and SERDES
<lekernel>
this file explains it nicely: ftp://ftp.macrogroup.ru/DigiEl/Xilinx/XLX_Seminar_NewElectronics/7series_Clocking_SelectIO_Tech_Module_Thomas_Klein.pdf
<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 interesting
<wpwrak>
hmmm .. just having a look at softusb-input/main.c ... so you've hard-coded the endpoint numbers ?
<wpwrak>
(instead of picking them from the endpoint descriptor)
<lekernel>
yeah... that should be fixed of course
<wpwrak>
of course ...
<lekernel>
but I find this kind of messing around with endpoint numbers utterly boring
<wpwrak>
i now see a lot more clearly about all those keyboards that some some magic reason don't work ;-)
<lekernel>
oh, sure
<lekernel>
there's that, and lack of hub support, and lack of composite device support
<lekernel>
well, don't get me started again on USB :)
<wpwrak>
i think composite devices are rare birds. but there's devices with multiple interfaces that would be reasonably friendly.
<wpwrak>
of course, they won't work with hard-coded EP numbers ;-)
<mwalle>
The Phaser blocks are reserved for Xilinx IP use only and are not available to
<mwalle>
the user.
<mwalle>
nice ;)
<wpwrak>
mwalle: so this means that, when we make use of it, Xilinx will have GPLed IP for those blocks. nice :)
<azonenberg>
lekernel: lol, glad to see you like it
<mwalle>
wpwrak: if ise will allow us to use it?
<wpwrak>
(reverse engineering) sweet ;-)
<lekernel>
sure it will ... xilinx core generator uses it
<lekernel>
and this thing operates at the netlist level... if xst blocks it (but I think it won't), we can always edit the netlist
<wpwrak>
wolfspraul: this would be a great theme to start the upcoming quarterly news !
<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 ;-)
<azonenberg>
lol
<wpwrak>
btw, aren't hubs kinda transparent ? but let me guess ... it's because the device address is hard-coded, too ?
<lekernel>
maybe :)
<wpwrak>
elevenbits .. @#*%!
<lekernel>
wpwrak: ah... see!
<lekernel>
it took me two weeks to get those damn eleven bits (and their CRC) right
<lekernel>
this is utterly frustrating when I can develop a PS/2 controller in 30 minutes
<wpwrak>
i understand. spending the extra hour to use them properly would have just been too much ....
<lekernel>
also, I was using the Opencrap USB PHY at that time, which also added its share of bugs
<lekernel>
:) exactly
<lekernel>
btw, if you want a quick test, try the demo firmware
<wpwrak>
0a81:0101 Chesen Electronics Corp. Keyboard ... bEndpointAddress    0x82  EP 2 IN ... that looks promising
<wpwrak>
let's see if the M1 hates it
<lekernel>
otherwise you have to update the header in RTEMS and rebuild it
<wpwrak>
ah no, it doens't. funny
<wpwrak>
wonders where that meme comes from that you have to AND away any bits that wouldn't fit into the target variable. pascal ?
<wpwrak>
like out[1] = elevenbits & 0xff; // out is unsigned char *
<wpwrak>
ah, 0x81 is address 1, EP 2. okay. that rhymes.
<wpwrak>
lekernel: what's you plan with making usb-midi work ? have you already started to make changes ?
<lekernel>
no, I have not
<wpwrak>
good. planning to start today ? or having other plans ?
<lekernel>
this will come after the "bugfix" release... I have a few other things to fix too
<lekernel>
backport upstream RTEMS support
<wpwrak>
okay. then i can have a bit of fun with USB ...
<lekernel>
there are a few things in FN that need to be changed to support RTEMS and YAFFS upstream
<lekernel>
this is done in the master branch, but I holded back those changes in the stable_1.0 branch because of the lag bug
<lekernel>
(and another interrupt bug that I fixed)
<wpwrak>
ah, so then there are some bugs i haven't found yet ;-)
<lekernel>
hm?
<wpwrak>
i'm now running master with rtems cvs. so, if i understand correctly, i don't have these fixes
<lekernel>
what? the interrupt bug?
<wpwrak>
yes
<lekernel>
you have the fix
<lekernel>
it was committed in August I think
<lekernel>
and the old RTEMS code didn't have it
<wpwrak>
no i'm confused :)
<lekernel>
(old = RTEMS checkout from summer 2010 + MM support patches, which is what the stable_1.0 branch is using atm)
<wpwrak>
are you planning to stay on stable_1.0 ? or move forward to RTEMS head ?
<lekernel>
move everything to RTEMS head
<lekernel>
including stable_1.0
<wpwrak>
excellent
<lekernel>
easier to maintain, less confusing :)
<wpwrak>
but stable_1.0 = master - things needed for RTEMS head, no ?
<wpwrak>
(more or less)
<lekernel>
atm yes
<wpwrak>
to what needs backporting then ? :)
<lekernel>
well... I just mean applying the changes to that branch as well and do some testing
<lekernel>
seems you're already doing the latter though :)
<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 this
<lekernel>
yes sure
<lekernel>
I just want to apply the bugfixes and push out a new release. then I probably won't touch the stable branch again
<wpwrak>
ah, so you do plan to update stable_1.0. i see.
<wpwrak>
i'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 !" :)
<lekernel>
just _one_ update
<lekernel>
then it will rot
<wpwrak>
alright, you're more scrupulous than me ;-)
<wpwrak>
now .. let's see if i can make heads and tails of why some of my USB keyboards work and others not ...
<lekernel>
we'll soon need a 3rd USB port on that M1 ...
<wpwrak>
i told you i want four ;-)
<lars_>
and i want otg
<lars_>
;)
<wpwrak>
ah .. EP1 after all. hmm. that weird ACME keyboard has an undocumented EP2. how queer :)
<wpwrak>
USB 3.0 !!
<wpwrak>
nice. 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 :)
<wpwrak>
and one of my mice sends weird clicks when dumping its descriptors. M1 is happy with it, though
<wpwrak>
now .. what do i do to make FN pick up the new softusb-input.bin ? there's no "make install" in softusb-input/
<wpwrak>
okay, it goes into libhal ... but there's nothing that moves libhal.a
<wpwrak>
ah, software/bios/Makefile ...
<wpwrak>
how about killing that silly "demo" binary ? ;-) that would let us simplify the build process quite a lot
<wpwrak>
and here we go again. after trying a large set of HID devices on my PC, the mouse finally went berserk
<wpwrak>
lekernel: thanks for the new bitstream ! works like a charm
<wpwrak>
grmbl. when i build my own bios, all i get is a newline on the serial console :-(
<wpwrak>
both with building "manually" and when using build_bios.sh
<wpwrak>
can i reload navre from FN ? :)
<lekernel>
wpwrak: FN doesn't use libhal. you have to modify the header in rtems and rebuild.
<lekernel>
if you use the demo it should be automatic
<wpwrak>
what header do i need to modify in rtems ?
<lekernel>
and I don't see how that "silly" demo binary makes the build process significantly more complex
<lekernel>
you can just ignore it
<lekernel>
something like c/libbsp/lm32/shared/milkymist_usbinput/softusb.h
<wpwrak>
(demo) seems that a few things could move from milkymist.git into flickernoise.git if it wasn't for the demo
<lekernel>
?
<lekernel>
like what?
<wpwrak>
oh, that's where the navre goes. so i don't need to replace the bios. nice.
<wpwrak>
like the patch compiler
<wpwrak>
well, parts of it. some of it is already there
<wpwrak>
heh, diff of softusb-input.h - completely different ;-) that'll be fun
<wpwrak>
excellent. USB still works. now, let's change something
<wolfspra1l>
[hhkb pro into standby] hmm. that means the 4.4v reset ic is definitely a no-go?