<wpwrak>
xiangfu: seems that we have to go back to pinning rtems and now also rtems-yaffs for a while
<wpwrak>
xiangfu: at least "head" seems completely unusable
<wolfspraul>
xiangfu: ah, good morning :-)
<wolfspraul>
as the next step we need not just daily builds, but also a daily (automated) test :-)
<wpwrak>
hehe :)
<xiangfu>
good morning.
<xiangfu>
wpwrak, I saw your email on USB rtems
<wpwrak>
maybe you could set up an M1 in your office that updates itself each day, then reboots. you'll catch this sort of thing instantly :)
jonand has joined #milkymist
<wpwrak>
at first i was afraid it had erased the FN configuration. but it just couldn't load any files. alas, only changing the permissions back to what they were before didn't seem to accomplish much.
cladamw has joined #milkymist
<xiangfu>
wpwrak, have you erased the data partition. which build you have tried? I would like to try that one :)
<xiangfu>
I mean reflash the data parition.
<wpwrak>
xiangfu: no no, the data partition is fine. it's FN+rtems+rtems-yaffs that can't read any files
<xiangfu>
ok.
<wpwrak>
xiangfu: once i installed an FN built with the pinned rtems, everything returned to normal. i didn't lose configuration or patches. they were just temporarily unavailable
<wpwrak>
xiangfu: you can try with the FN from the latest daily build. that one exhibits the problem. not sure when it started. may have been a while.
<xiangfu>
I will try the latest build.
Jia has joined #milkymist
<cladamw>
wpwrak, last week seems that you thought we should have our own symbols under /kicad-libs/components/ which same or as common one as KiCad default one ?
<wpwrak>
cladamw: yes
<wpwrak>
cladamw: we shouldn't depend on the "system" kicad libs
<cladamw>
like 'common', 'power', 'conn' ...
<wpwrak>
cladamw: these libs 1) have some bugs, and 2) they change sometimes, so we can't know what someone has installed on their system
<cladamw>
yeah... i've seen many pieces of emails in KiCad-users they've replied this bad once KiCad installs again.
<wpwrak>
yeah :)
<cladamw>
so no my questions are :
<wpwrak>
you update after a few years, and all of a sudden, everything is a little different :)
<cladamw>
1. Shall I go for like do a repository copy from "system" KiCad lib and merged ourselves under qi's kicad-libs/components ?
<cladamw>
since I started to use those very common libs which are belonged to KiCad's its system libs. ;-)
<wpwrak>
i would start with an empty library and carry over or redo the parts i find i need. that way, i can be sure everything is consistent
<wpwrak>
for example, you want to pay attention to font sizes. almost all of the power symbols have a 0.40" font somethere, which is basically unreadable
<wpwrak>
s/somethere/somewhere
<cladamw>
okay... but the empty library's name like same as 'common' and 'power' ?
<wpwrak>
yes, why not
<cladamw>
alright. :-)
<wpwrak>
or wait lemme check ...
<wpwrak>
hmm, the paths to the kicad libs are hard-coded. so there may be confusion of you use the same name. "common" should be fine, but "power" may cause problems
<wpwrak>
we could of course just follow the one lib per symbol principle even for "common", and have r.lib, c.lib, and so on. may be a bit excessive, but not much
<wpwrak>
"power" is tricky. well, we can abbreviate it. for example, "pwr.lib"
<cladamw>
okay ... agreed on naming "pwr.lib"
<cladamw>
:-)
<cladamw>
but this "pwr.lib" are mostly for common symbols of power not for chips from KiCad's default meanings. ;-)
<xiangfu>
wpwrak, cladamw I will split my common to c.lib/r.lib/led.lib
<cladamw>
so we use "pwr.lib" for common symbols
<wpwrak>
pwr.lib for power symbols
<cladamw>
xiangfu, nice, so could you do this now or ?
<xiangfu>
cladamw, now.
<wpwrak>
ah no, not for chips :)
<cladamw>
and rename "power.lib" to "pwr.lib"? :-0 btw, teach me that how to rename like this got git. :-)
<wpwrak>
git mv file.old file.new
<cladamw>
xiangfu, let me do this mv. i try. :-)
<wpwrak>
but we don't have anything called "power.lib" in git, so that's not necessary :)
<cladamw>
oah..yeah
<cladamw>
xiangfu, but we need to copy power symbol from board-m1 to kicad-libs/components/pwr.lib :-)
<xiangfu>
cladamw, from /usr/share/kicad/.... to kicad-libs/components/pwr.lib
<wpwrak>
but don't just copy the whole file. copy the components you need - and check that they look right, especially the font sizes. anything 0.40" (or is it 0.040" ? don't remember) should be at least ...50
<GitHub139>
[board-m1/master] linked bnc.lib and all parts in VideoIn.sch - Adam Wang
hypermodern has joined #milkymist
kilae has joined #milkymist
lekernel__ has joined #milkymist
voidcoder has joined #milkymist
<mwalle>
wpwrak: btw if you have some spare time, i'm curious which patch (the DCM->PLL or 72mhz usb) fixes the errors
<mwalle>
i doubt its the first.. but anyway
<mwalle>
wpwrak: is the lv3 a full speed device?
<lekernel__>
yes, it is
<mwalle>
lekernel__: ok :)
<wpwrak>
mwalle: i think any full-speed device triggers the errors. can be a keyboard, probably also storage or such. of course, if it's a type of device softusb doesn't recognize, you'll only get a small number of complaints before it decides to ignore the device