01:04 <wolfspraul> wpwrak: since it's Monday (here), I am thinking about this week and beyond...

01:05 <wolfspraul> are the usb fixes finished? last I read something about a protocol analyzer?

01:05 <wolfspraul> Adam will probably soon get to layout

01:05 <wolfspraul> then kicad & boom

01:06 <wolfspraul> my feeling is after R4 we should jump ahead and go directly to -7 ddr3 spi, and so on

01:07 <wolfspraul> rather than another smaller incremental update

01:07 <wolfspraul> but just guessing, let's see how it goes the next few weeks

01:08 <roh> one step at a time

01:11 <wpwrak> (usb fixes) naw, there's another big round waiting to be done. the last round was about higher-level problems. the bit- or byte-level issues are still around. but they're hard to debug without proper tools.

01:12 <wpwrak> (usb) we'll also need to merge proper HID handlinh. xiangfu already wrote code to retrieve the report descriptor. now we have to parse it and use the "bytecode" it contains.

01:14 <wpwrak> (ddr, etc.) yes, maybe. depends on how well r4 goes. if we have no regression, i think an update of the core (fpga, ddr) is a good idea

01:14 <wolfspraul> ok

01:14 <wolfspraul> good

01:15 <wpwrak> lekernel should probably get a eval board, though. that way, he won't have to fight hardware issues (layout is probably quite hairy with faster DDRs) and intrinsic memory painfulness at the same time, when debugging the DDR controller

01:17 <wolfspraul> I'm not that far into the specifics yet, want to do a superb job with R4 first

01:17 <wolfspraul> and create a basis for the future

01:17 <wolfspraul> the reason I am thinking about R5, or anything post-R4, is simply to plan the run size of R4

01:18 <wolfspraul> but my feeling is we want to accelerate

01:18 <wolfspraul> or rather we 'can', if the foundation gets better

01:18 <wolfspraul> without destroying the product's usability

01:18 <wolfspraul> and yes I totally agree, it depends on R4 regression testing as well

01:18 <wolfspraul> I don't want to leap ahead when my product falls apart, turn into an infinite lab. no way.

01:19 <wolfspraul> R4 has to be rock solid and show that everything is under control, especially mem performance as sebastien pointed out already.

01:19 <wolfspraul> let's do that right first

01:19 <wolfspraul> and if we succeed, assuming that we will, then the next step

01:19 <wpwrak> (kicad & boom) i'm working on the new boom. but it'll still take a while until it can do anything useful. the design philosophy will change a bit - the old one was centered around pattern matching and text substitution, much like sendmail.cf. that made it flexible but also led to awkward solutions for some problems. the new one knows all the main data types (names, name sets, values with SI prefix and unit, tolerances) and handles parsi

01:19 <wpwrak> ng, comparison, etc. in C. so you only tell it what kind of fields you have but don't set up some elaborate chain of substitutions that lead to textual matches.

01:21 <wolfspraul> sounds good

01:21 <wolfspraul> do you remember the feedback from the first round?

01:21 <wolfspraul> I vaguely remember digi-reel as one of the biggest wishlist items

01:21 <wolfspraul> and/or tray

01:21 <wolfspraul> right?

01:22 <wpwrak> that's at least for the part that concerns characteristics (.chr files) and kicad. .chr file generation, i.e., parsing of vendor part codes, may still be better served by a purely string-based approach. but that can even live in a separate kind of program.

01:22 <wpwrak> yes, i have a distinction between "manual" and "machine" now ;-)

01:26 <wpwrak> reel vs. non-reel (possibly with reeling as an option) was the main feedback

01:28 <wpwrak> from my side, the main issue of the old one is lack of scalability, speed-wise. it's already approaching its limit with what i'm doing for ben-wpan.

09:59 <lekernel> mwalle: larsc: what do you think of Sergey's patch?

11:24 <mwalle> lekernel: can be applied, signals in lm32 port need a rework anyway

11:32 <lekernel> great, thanks. doing it.

11:34 <GitHub119> [linux-milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/-RZgSA

11:34 <GitHub119> [linux-milkymist/master] Fix of Linux signals for LM32 arch - Sergey Koulik

18:21 <sh4rm4> Fallenou, once the MMU is finished i'd be interested if musl libc could be ported to milkymist-linux