<GitHub78>
[autotest-m1/master] fix warning - Xiangfu Liu
<aw>
good that i flashed 8 pcs successfully by shorter BEN usb cable. ;-)
<kristianpaul>
aw: :-D
<wpwrak>
aw: smells like a signal integrity issue
<aw>
wpwrak, yeah....felt like that usb high speed accompanies most transmission lessons we didn't do well during design...I'll also watch if the vga problems is dependent to this after 20 pcs then well-known from data.
<kristianpaul>
(vga) yeah, thats still on the road..
<wpwrak>
what's the VGA problem ?
<kristianpaul>
no signal
<aw>
DDC is pass, then just no screen shows up.
<wpwrak>
ah, repeatably ? or just sometimes ?
<aw>
some boards
<aw>
from yesterday's data, I was easily to meet a vga no screen. this morning I've tested 5 pcs then vga is okay...surprised. surely the sample base is not bigger. let's accumulate more said like 15 ~ 20pcs successfully. well..just guessed...;-)
<wolfspraul>
aw: our test software absolutely has to do a 100% crc check on all data in nor
<wolfspraul>
I think it's not doing that now, argh
<wolfspraul>
:-)
<wpwrak>
aw: and if you re-test a board with good or bad vga, does the result persist ?
<wpwrak>
wolfspraul: that would be really bad :)
<aw>
was still there no matter what i replugged vga cable more times
<wpwrak>
kamikaze, blindfolded and wearing earplugs ;-)
<wpwrak>
aw: okay. did you try to reflash any of those with bad vga ?
<kristianpaul>
no screen shows up = no signal detected by the screen or just blank screen?
<aw>
no signal detected, if have signal detected ,my monitor will have a green LED on. ;-)
<aw>
wpwrak, i haven't digged into scope signals though. ;-)
<wpwrak>
that's one or two escalation steps away ;-)
<wolfspraul>
wpwrak: I would think it persists, and that's not that bad I think :-) just a problem with a chip somewhere
<wolfspraul>
on rc2, you have no idea how many chips Adam had to resolder manually
<kristianpaul>
but if bios load okay it at least should show a blank screen,that can be swiched with Esc key..
<wolfspraul>
I'm worried that we don't have 100% crc checks in the test software, at least that is my understanding
<kristianpaul>
yeah..
<wpwrak>
not having crc is bad. particularly if there are signal integrity issues.
<wolfspraul>
xiangfu is traveling right now, but...
<wpwrak>
USB has its own CRC, but if you hit it persistently enough, some errors will get through
<wolfspraul>
in true foss warrior style, he has his m1 in his backback, and is hacking on the road
<wpwrak>
(i've seen this happen in real life)
<wpwrak>
;-))
<wolfspraul>
I hope we get a CRC version of the test software today or tomorrow
<wolfspraul>
he has it written, testing now
<wpwrak>
you may also want to consider switching to full-speed, if that's not too difficult.
<wolfspraul>
and that after our last-minute high-speed fix :-)
<wolfspraul>
let's do one by one. first crc software.
<wolfspraul>
that will improve our visibility
<wpwrak>
yeah. and all the effort to get people to send back their unfixed boards. those may actually be the lucky ones ;-)
<wpwrak>
CRC is always good to have :) and it'll help you characterize the problem
<wolfspraul>
it's too early to point at high-speed now
<wolfspraul>
also to keep things in perspective, the majority of reflash ops works
<wpwrak>
(too early) yeah, the libusb issue is somewhere in there as well
<wolfspraul>
we are testing boards off of a manufacturing run
<wolfspraul>
correct
<wolfspraul>
bugs everywhere
<wolfspraul>
:-)
<wolfspraul>
but all we try to achieve with the boards now is 100% pass, and consistency among them. then the rest that will be discovered in the future is hopefully software fixable.
<wolfspraul>
i'm sure you will not try to tell me that there aren't 'a few' cases of if (board_rev==magic_num) do_silly_thing(); in the typical kernel code :-)
<wolfspraul>
maybe more like hundreds? :-)
<wpwrak>
there may be some. although the usual approach is to hide them via platform-specific callbacks and such :)
<wolfspraul>
you get my point
<wolfspraul>
I try to make boards with consistent quality
<wolfspraul>
that's a good basis for software
<wolfspraul>
so first of all I want 100% crc, and ugly blind spot imho
<wpwrak>
yup
<wpwrak>
firmware you can't verify is broken :)
<kristianpaul>
ah, got it now, crc is on bios not test software..
<kristianpaul>
i took that for granted :)
<wolfspraul>
we overlooked it before the run, my fault
<wolfspraul>
was not on my radar
<wpwrak>
kristianpaul: famous last words :)
<kristianpaul>
(hacking on the road) yeah, untill the battery dies, but is nice, i usually i think i'm more productive that way
<kristianpaul>
at least i can focus better
<wpwrak>
wolfspraul: if you can simply read the image back, that would also be sufficient for verification
<wolfspraul>
as an excuse I can say that things are improving in so many areas, that one just slipped through ;-)
<wolfspraul>
the jtag verify feature is too slow
<kristianpaul>
wpwrak: read back take time. and you can get few surprises from that back as well ;)
<kristianpaul>
so later you dount about whatyou write and what you think you read..
<wolfspraul>
xiangfu is on it, we'll have it soon I hope
<kristianpaul>
doubt*
<wolfspraul>
not via jtag, but via test software
<kristianpaul>
:-)
<wolfspraul>
yes, so the test software is much better, it can do the test over and over
<wpwrak>
kristianpaul: well, if you don't trust the readback, then fix it ;-)
<kristianpaul>
(backpack) and also batteries for mm1 included? will be cool, i got this voltaic thing (http://www.voltaicsystems.com/usb-battery.shtml) for that porpuse, but i havent tried, i need secure voltage input first :-)
<kristianpaul>
wpwrak: uclinux is happy with a inteerupt every 700us right?
<kristianpaul>
actually i think this will be run in userpace, as osgps linux module looks kinda forgotten..
<wpwrak>
kristianpaul: 700 us should be okay, even for a relatively slow CPU, yes
<kristianpaul>
good !
<aw>
why do default of Line & Mic volumn set at maximum not middle after boot up? curious.
<kristianpaul>
i remenber this values are not saved, if you modified and waiting to recover next boot will not happen
<wolfspraul>
it helps if you always have the same nick, liks 'caso' (but I guess that was taken so they kicked you to another one)
<wolfspraul>
you can change the nick with /nick some_nick
<wolfspraul>
try that
<Cristian>
ok, my name is Cristian :)
<wolfspraul>
seems that one is not registered
<wolfspraul>
oops
<wolfspraul>
it is :-)
<Guest97831>
Cristian is taken so... another one
<wolfspraul>
the way freenode works is that they have registered names
<wolfspraul>
then you have some seconds to enter your password
<wolfspraul>
otherwise the system kicks you to an auto-name
<wolfspraul>
you can try names, no problem
<wolfspraul>
:-)
<wolfspraul>
that should be safe
<wolfspraul>
cristian_casorra: seems to work
<cristian_casorra>
how I can put a pass¿
<wolfspraul>
hmm
<wolfspraul>
google for 'register freenode account'
<wolfspraul>
but with 'cristian_casorra' you should be safe
<wolfspraul>
so no need maybe
<cristian_casorra>
ok
<wolfspraul>
cristian_casorra: alright, so I'll get back to you the moment I have the full new units here with me
<wolfspraul>
and you let me know in advance if you have any questions after reading the web etc.
<wolfspraul>
you can always pop in here and ask, please don't hesitate
<wolfspraul>
right now it looks like I may have a unit for you in about 2 weeks
<wolfspraul>
I've been saying the same thing 2 weeks ago though :-)
<wolfspraul>
but we're almost there...
<cristian_casorra>
ok perfect, I'll check all the information in the web site, right now I can't because I have to make a protocoll for a dimmer controller... so... this weekend I'll try
<wolfspraul>
cristian_casorra: sounds good, we are here...
<aw>
0x85: just got d2/d3 dimly lit which cant reconfiguration after finished firstly rendering then I powered cycle.
<wolfspraul>
not good
<aw>
0x85 was finished all functionality test by test tool
<wolfspraul>
try to power cycle again :-)
<aw>
now..it can reconfiguration again. ;-) after maybe 3 minutes. ;-)
<aw>
let me record firstly. :)
<xiangfu>
wolfspraul, Hi
<wolfspraul>
hi
<xiangfu>
images CRC check in test image. : http://dpaste.com/581313/ now. I needs fix the BIOS check. all other look fine.
<wolfspraul>
xiangfu: do you mean Adam can try using that image?
<xiangfu>
no. let me first fix the BIOS problem. I think there is something wrong in my code.
<GitHub53>
[autotest-m1/master] move the images test to first - Xiangfu Liu
<xiangfu>
aw, sorry why it failed, you have to reload?
<aw>
that means if i knew a midi failed, i can only use step by step items to test. ;-)
<aw>
since the send/receive is too fast, so that i can't speed up to press a "e" to let it stop. then i have to reload image to use step by step item test.
<aw>
1. from this morning, there's no d2/d3 dimly lit more immediately after reflashed by using shorter BEN usb cable. ;-)
<wpwrak>
(midi spec) ah, nice. thanks !
<aw>
2. but I got can't reconfiguration while counting rendering times: 0x63 and 0x85.  :(
<aw>
well...time to dinner
<aw>
see later
<wolfspraul>
roh: hi there, how are things?
<roh>
wolfspraul: good.
<roh>
finished lasering yesterday evening and slept >12hours now
<wolfspraul>
you mean all logos lasered?
<roh>
yes
<roh>
on 80 of the 160 lids
<roh>
once centered per case in the middle. so if you do not like the logo, just put it to the bottom
<wolfspraul>
why would I want that? you don't like it?
<roh>
wolfspraul: well.. the customer could want that
<roh>
its also nice without the logo
<wpwrak>
roh: oh ... the grooves are on the outside or the inside ?
<roh>
inside
<wpwrak>
pheew :)
<roh>
i lasered it mirrored
<wpwrak>
very good. i just had one of those "oh shit" moment ;-)
<wpwrak>
s/moment/moments/
<roh>
hrhr
<wpwrak>
with a horror vision of M1s loaded with dirt, etc. ;-)
<roh>
wpwrak: well.. imagine a clean, eben and reflective surface on a dj-booth.. its not only dirt which would stick there.. also all kinds of .. eh.. poweders
<roh>
s/eben/even/
<wpwrak>
yeah, M1s could fetch a nice resale value ;-)
<roh>
will do final qc now and hopefully find a proper package
<wolfspraul>
ok, then shipping
<wolfspraul>
how did we ship last time?
<wolfspraul>
zecke is actually flying over on Sunday (to Beijing), but I wouldn't want to load the customs VAT stuff upon him...
<lekernel>
I will probably go (and have space in the car from Berlin)
<roh>
well.. too short after the camp
<lekernel>
mwalle, your components are on their way :)
<wpwrak>
roh: insufficient detox time ? ;-)
<roh>
wpwrak: simply plain madness.
<roh>
wpwrak: not because of detox but teardown etc.
<roh>
wpwrak: what most people dont know. there were festivals last weekend and there will be one next weekend just few km from the campsite with a lot of 'personal overlap'
<wpwrak>
aii ... sounds like fun :)
<roh>
so after the camp is after weeks of continous event/party for some
<wolfspraul>
lekernel: I understand you want to sell some m1 at the camp?
<wolfspraul>
I think from now on you should always have a few full boxes with you that you can just sell :-) for cash or whatever payment form you like :-)
<roh>
HA.. a notch in the clouds... LESS rain. bbl. need to use that
<wolfspraul>
maybe there is some paperwork to be considered though, if people want a receipt, VAT, etc. but as a 'small businessman' you may even be exempt from charging vat for a while, don't know. or you just ignore it.
<roh>
ignoring is a very bad idea.
<wolfspraul>
ah
<wolfspraul>
sometimes I love China
<wolfspraul>
I will have re-adjustment problems when I get back
<wolfspraul>
all this artificial bloated stuff... :-)
<wpwrak>
wolfspraul: they'll put you in jail for doing what you can get away with in china. wouldn't that be ironic ? :)
<wolfspraul>
not ironic at all
<wolfspraul>
there would be far more Chinese in jail in Germany than are in jail in China
<wolfspraul>
:-)
<wolfspraul>
think about that for a while, he he :-)
<wpwrak>
exactly ! :)
<wolfspraul>
I am very aware of this, no worries.
<wolfspraul>
I'm still here after all. everything has a price, one way or the other.
<wolfspraul>
lekernel: Adam has two interesting observations with boards 0x63 and 0x85
<wolfspraul>
he is doing full 'rendering cycles' now on each board, where he boots to render, lets it render 30 seconds I believe, and then power cycle. 10 times.
<wolfspraul>
on 0x63, the notes say "1. while counting rendering times, can't configuration more from @ 6 th power on 2. then reflash again successfully 3. can't configuration more from @ 4 th power on"
<lekernel>
sounds like this horrible reset bug is still not gone
<wolfspraul>
on 0x85, they say "1. finish 1st rendering test then power cycle again, then can't reconfiguration(d2/d3 dimly lit); then can reconfiguration after maybe 3 minutes"
<lekernel>
if the rework correctly done on those boards?
<wolfspraul>
he can later do measurements, first still go through all boards
<wolfspraul>
the 0x85 is interesting. basically it works again after waiting a few minutes.
<lekernel>
or maybe the particular representatives of the family of pesky diodes used on those boards have higher capacitance/reverse current
<wolfspraul>
it is possible that one could actually demonstrate this on more boards, if you only do enough cycles? maybe something we can improve in the startup/bitstream/rtems boot procedure?
<wolfspraul>
sure that's also possible
<wolfspraul>
that would be easy to fix :-)
<wolfspraul>
ok, just a heads up now
<wolfspraul>
right now, when the smallest unexpected thing comes up, the board will not be put into 'available' state
<wolfspraul>
later a lot of this may disappear under closer investigation or with small hardware fixes
<wolfspraul>
Adam is using a test image with full CRC now, btw
<wolfspraul>
and the shorter USB cable
<wolfspraul>
aw: you saw that lekernel thinks later you should check on 0x63 and 0x85 that the fix2 rework was 100% correctly applied, with all values correct etc. maybe replace the diodes?
<aw>
wolfspraul, hi sure. they are of course at the right but maybe have specifications shifted after my soldering. including capacitance/reverse probably, so I'll replace for new part when i back ti see them. thanks for reminds.
<aw>
s/ti/to
<wolfspraul>
sure
<wolfspraul>
good luck with testing! :-)
<wolfspraul>
keep telling us anything suspicious you see...
<aw>
yes...but hope not more though! ;-)
<aw>
just updated on wiki, alright; i am out now. will continue testing tomorrow, night. :)
<mwalle>
larsc: systemcalls like clone need all registers
<larsc>
do they?
<larsc>
the idea was to put r1-r10 in the clobber list for scall
<larsc>
so we don't have to save them
<larsc>
so we basically say the state of r1-r10 is undefined after a syscall
<larsc>
since scall is most of the time at the end of an function and r1-r10 is caller saved the restored values of the registers aren't going to be used anyway
<mwalle>
larsc: yes a new process/thread is created by copying all registers
<mwalle>
so the kernel needs them
<mwalle>
and r11- are callee saved and handled by gcc anyways :)
<larsc>
thats why we can't trash them in the syscall
<larsc>
but the new process doesn't care about the contents of r1-r10 either
<larsc>
or shouldn't
<larsc>
the only problem would be that clone() needs fn and arg
<larsc>
after the syscall
<mwalle>
larsc: why should we need to save them (r11-) ? if a function use them it'll save them
<larsc>
you mean in the kernel?
<mwalle>
any compiled function :)
<mwalle>
interrupt exceptions only save the caller saved registers
<larsc>
uhm, yea, but we need to restore r11- when cloning a process
<larsc>
but i guess to properly support ptrace we need to store and restore them
<larsc>
mwalle: another thing: should we add a "soc" node to the dts and put all on-soc components in there and all other outside of it?
<mwalle>
larsc: whats outside?
<larsc>
memory, buttons, leds
<larsc>
i'm just not sure if that would work
<mwalle>
imho the soc is actually the whole dts, memory is outside of the csr bus, thats ok, dunno for the leds/buttons
<mwalle>
i would not make it too complicated, imho there is no extra gain
<mwalle>
there is still the fml bridge missing, eg where do we put the code to flush it
<mwalle>
larsc: there is no way to build openwrt out of tree, is it?
<larsc>
not sure, never tried it
<larsc>
the devicetree documentation has an example where the soc has its own node
<larsc>
This node is used to represent a system-on-a-chip (SoC) and must be
<larsc>
  present if the processor is a SoC
<larsc>
quoted from the documentation
<mwalle>
from epapr?
<larsc>
epapr?
<mwalle>
embededded power application platform requirements
<mwalle>
from power.org
<mwalle>
linux kernel documentation?
<larsc>
yes
<mwalle>
yeah but keep in mind that this is very power pc specific, eg they search their properties or root nodes by of_find_node_by_type(NULL, 'soc')
<larsc>
hm, ok
<kristianpaul>
if mm soc dont have a RTC or clock, how to you implemnted that in linux?
<larsc>
we don't
<kristianpaul>
ah :)
<larsc>
the clock will be reset each boot
<kristianpaul>
but busybox have  a ntp client right?
<larsc>
yes
<kristianpaul>
ahh, but there is no driver for minimac2...
<mwalle>
kristianpaul: not yet :)
<mwalle>
maybe this weekend
<kristianpaul>
*g*
<mwalle>
but i still dont have a working initramfs and/or kernel :(
<mwalle>
Freeing unused kernel mem: 100k freed
<mwalle>
init: memory exhausted
<larsc>
no memory?
<mwalle>
i dont think so :)
<mwalle>
i guess sth is wrong with my initramfs
<mwalle>
i have to go
<mwalle>
see you tomorrow
<lekernel>
mh, with rtems cvs head, the flickernoise binary works in QEMU and freezes at boot on the board
<lekernel>
I get this warning from QEMU though: qemu-system-lm32: milkymist_sysctl: timer0: trying to write a value greater than the limit. Clipping.
<lekernel>
maybe the context switch timer is broken
<tuxbrain>
any good CNC machine to drill pcb that works under linux?
<roh>
we got a mill... whats your fileformat? gerber? gcode?
<kristianpaul>
wich mill then roh ?
<roh>
i got one here, which will be retrofitted with another high-speed spindle, the current one has 3000rpm. also i can access another mill which already has 2 heads with 20krpm
<roh>
or do you need a buying-recommendation?
<kristianpaul>
i think
<tuxbrain>
buying recomendation, but if you give that for free I will be happy :)
<kristianpaul>
:-)
<roh>
hrr
<roh>
tuxbrain: mills are highy application specific.. for pcbs only there are special mills.. but they are quite pricy
<kristianpaul>
like werner one?
<tuxbrain>
I see ones about 6k¬ but only works with windows
<tuxbrain>
and the soft inside the machine is a mistery
<kristianpaul>
i think will be hardware some DIY/floss style CNC for making PCBs acuurately btu worth the source :-)
<kristianpaul>
sourcing*
<kristianpaul>
tuxbrain: may be try asking in #cam ?
<wpwrak>
pcb engraving is a little tricky. you need some system that maintains the exact altitude. not sure how well they do with the modern thin boards.
<kristianpaul>
wpwrak: your cnc is capable of that?
<wpwrak>
my mill can drill holes and cut through the PCB. i made a few attempts at engraving, but they didn't go so well.
<wpwrak>
i have some ides that might yield better precision, but i don't know yet whether they will work
<wpwrak>
the idea is to scan the surface first, then use the altitude profile to compensate for board warping and such
<wpwrak>
but again, that's probably only good for 1.6 mm boards. with 0.8 mm, it may have to cut too deep into the board to make sure it always removes all the copper everywhere
<wpwrak>
also, the finer the traces, the thinner the bits and thin bits are more expensive and break more easily
<wpwrak>
so cost goes up with O(n^2)
<wpwrak>
i made my peace with the chemical process :)
<kristianpaul>
some chemicals and a good laser printer and transfer process could do wonders i guess :)
<wpwrak>
tuxbrain: since you're planning to move into new premises anyway, make sure you have a balcony for the etching. then it's not so bad. you can store the acid outside so the fumes don't cause trouble. with HCl+H2O2, etching is quick and you have no liquid waste to worry about
<tuxbrain>
ups this is MM channel :P I think I was on qi-hardware on
<wpwrak>
heh ;-) let's continue over there then :)
<roh>
we got a automatic depth regulator for the 2nd spindle
<roh>
its a vertical sled and a shaft around the spindle which hold the right cutting depth precisely by sliding over the copper surface