<kristianpaul>
is clamng so mature to for demos? :o
<kristianpaul>
jpbonn: what will/are the advtages of clang/llvm over the current gcc within the milkymist soc?
<larsc>
it will work ;)
<larsc>
(hopefully)
<kristianpaul>
he ;)
<jpbonn>
kristianpaul: no advantages- clang doesn't work for milkymist yet.  For us the advantages will be the ability to add features to the language for a variant on the mico32 cpu
<jpbonn>
For the long term I think most people view clang as a better compiler design that will eventually replace GCC.
<kristianpaul>
features to the language looks interesting if easy ;) i'll keep my eye on it who knows..
<wolfspraul>
for the record, when comparing gcc and llvm, it should also be noted that llvm is a strategic project by Apple, Adobe and nvidia to break the gpl and allow the growth of proprietary in-house IP into the toolchain
<wolfspraul>
I'm not saying this as a conspiracy, it's just how it is.
<wolfspraul>
however, I love the fact that llvm kicks the lazy gcc guys in the butt
<wolfspraul>
they deserve that :-)
<wolfspraul>
I am tired of people who hide their laziness behind self-imposed ethical superiority
<wolfspraul>
so if llvm can work better for Milkymist now, great
<wolfspraul>
and if it can kick the gcc guys, no matter how hard a kicking is needed, eventually it will hurt and they may step up their game too
<wolfspraul>
that's how I see it :-)
<larsc>
wtf. the audio chip i declared dead yesterday, works again today...
<kristianpaul>
hardware have seven lifes ;)
<Hodapp>
I for one always found it amusing how the hardware I'd dig out of a dumpster would outlive the new stuff.
<larsc>
maybe the was strange ionic activity yesterday or whatever
<kristianpaul>
(step up) yeah, i'm more interested in llvm to see how gcc guys step up after it became more usable in production :)
<wolfspraul>
larsc: not unusual
<wolfspraul>
so when you work with hardware, best is you have several of 'the same' board always
<larsc>
wolfspraul: but usually a board does not return from dead
<larsc>
zombie board ;)
<wolfspraul>
it does
<wolfspraul>
I say - not unusual
<wolfspraul>
I am working with hardware for years, trust me
<larsc>
ok
<wolfspraul>
the reality is that we always know little about the board, in all its depth
<wolfspraul>
hardware is analog
<kristianpaul>
he, my laptop was dead for 3 days, then i became alive, now it tends to happen by some hours.. i dint counted how many times, so i concluded after the seven shut off, no more.. :(
<wolfspraul>
so because we operate knowing/thinking we know maybe 1% of the technical facts present in the board in front of us, something like what you observed can happen
<wolfspraul>
and it can have been caused by a nearly infinite list of root causes
<kristianpaul>
they return larsc , oh yes.. like trying a second main in other house,, oh well...
<wolfspraul>
temperature change, humidity change, discharges from touching the board here or there, cooling down of some parts, and so on
<kristianpaul>
now i understand why a controlled room so important
<larsc>
i have this one usb device which only works when i put it in a fridge for 10 minutes before using it. quite funny
<wolfspraul>
not unusual :-)
<wolfspraul>
like I say, we know little about a particular board
<wolfspraul>
think about all the manufacturing that went into it, into the ics, analog ics, pcb, smt, passive parts, etc. tolerances everywhere.
<wolfspraul>
it's like a house of cards
<wolfspraul>
you just think it's this clearly defined thing, but it isn't
<wolfspraul>
so when you do serious work on the boundary between hardware and software, you should have multiple boards and that may save you a lot of time
<kristianpaul>
5 a least? that was mm1 rc-1 right?
<wolfspraul>
once you are 100% in software land, you assume that you have a perfect binary environment around you, and then you are good with 1
<wolfspraul>
for a developer like lars maybe 2-3 is enough. it's just to make him save time and not get stuck with something popping up from the many unknowns inside a particular board
<wolfspraul>
if you work on the software-hardware boundary, you should have more than 1 board, for sure
<wolfspraul>
lars doesn't need 5 or 10 because he is not trying to improve the manufacturing process, he's trying to improve the software. but 2 will help him save time, imho.
<kristianpaul>
yeah, i understand your point, save time is really important, also to confirm proven functionallity in software side
<larsc>
i guess it is a bit of a trade of, what will cost more, developer time or another board
<wolfspraul>
I assume boards to be cheap, you are right
<wolfspraul>
if it's going to be a mass-produced consumer electronic that's the right assumption
<wolfspraul>
if it's something for a satellite or other expensive low volume product, that assumption may be wrong
<wolfspraul>
I'm just saying don't be surprised about a board doing strange things on you, like coming back alive after a day of death
<wolfspraul>
that is not unusual at all
<wolfspraul>
it's because we know very little about one particular board
<GitHub31>
[clang-demos/master] Added a simpler harness to run tests that uses mico hooks in qemu. - JP Bonn
<wolfspraul>
larsc: if you are on a production line where electronics are made, you will see, over time, an infinite variety of 'strange' behavior on this or that product
<wolfspraul>
after some time you stop asking 'why' on each one
<wolfspraul>
instead, the focus is on finding a pattern
<wolfspraul>
if there is a larger amount that all do the same strange thing, that's reason to focus on that
<wolfspraul>
it's driven by economics, not by trying to understand each board
<wolfspraul>
every line will happily discard boards found to behave 'strangely', as long as they are rare enough
<wolfspraul>
it's not a digital process
<wolfspraul>
it took me a while to accept this, but now I do. at the beginning I was flummoxed by some of the things I saw some boards doing, right in front of me.
<Thihi>
Well, considering that for instance cpu's are manufactured in conditions that need to be hundreds of thousands of times more clean than operating rooms, since any speck of dust that gets lodged in between the silicon wafers means a defect, it's no wonder not every part is perfect...
<wolfspraul>
correct, cannot be
<wolfspraul>
manufacturing is analog
<wolfspraul>
everything has tolerances, all the way in to the last transistor
<Thihi>
Yeah.
<wolfspraul>
so a board doing something strange is not unusual at all
<wolfspraul>
that was my original point
<wolfspraul>
the way to offset the time loss is to look at multiple boards
<Thihi>
Yes, just wanted to chime in. :)
<Thihi>
Since cpu manufacturing is HARD CORE and way cool. ;P
<wolfspraul>
Thihi: are you aware of Andrew Zonenberg's homecmos project?
<azonenberg>
Going to be doing some more boring (i.e. not nyan cat etc) test patterns tonight or tomorrow in preparation for a run on the campus SEM late this or early next week
<azonenberg>
I want to measure slope of edges (which will determine feasible aspect ratios) and thickness of some of my deposited layers
<azonenberg>
That was while diagnosing a strange particle contamination
<azonenberg>
Which ended up being silicon sawdust from fracturing wafers into individual dies
<Thihi>
Having just covered the Assembly 2011 (yeah, yeah, commercial, sellout, devoid of scene, to be dissed, etc.) for the local tech zine, I guess nyan cat just naturally appeals to my drained brain atm.
<azonenberg>
and was trivially removed by a more thorough clean before the first processing
<azonenberg>
And lol
<azonenberg>
I was doing the companion cube before that
<azonenberg>
but it got old
<azonenberg>
I already promised a friend my next tests (of curves) will use Keroppi
<azonenberg>
probably mudkip after that
<Thihi>
:)
<azonenberg>
MEMS are still a few months out
<azonenberg>
but i can make MEMES now ;)
<larsc>
hehe!
<Thihi>
No goatse yet? :(
<azonenberg>
Lol no
<azonenberg>
I might try "THE GAME" though
<Thihi>
Sigh. As nice as it is to chat with you guys. I should go write my stupid shitfuck article on the party. It's due in a couple of hours.
<Thihi>
And I still need to go through 1500 photos.
<Thihi>
:P
<azonenberg>
1500? Have fun lol
<Thihi>
:)
<azonenberg>
My entire archive last time i counted was like 20,000
<azonenberg>
but that goes back to 2004
<Thihi>
:D
<Thihi>
Well, I just bought a new camera for the event. I guess novelty kicked in.
<azonenberg>
If i had a DSLR i'd do a lot more too
<Thihi>
And since I'm not that good a photographer and I need to get at least 10 perfect photos, so ... 1500 to pick from sounds about right. ;P
<azonenberg>
this silly point and shoot takes a couple seconds to save each image
<azonenberg>
And lol, my policy is shoot first and ask questions later
<azonenberg>
Disk space is cheap
<Thihi>
But yeah, going through 1500 pictures of people to whom the demoscene should go fuck itself since it's interfering with world of warcraft to find the 10 pics is a lot of annoying work ;P
<azonenberg>
A guy i know from back in NJ is a police firearms instructor and he almost always double-taps with his SLR
<azonenberg>
although at important events when he doesnt want to crop anything important the policy is two in the chest, one in the head :P
<wolfspraul>
what is Assembly 2011 ?
<Thihi>
wolfspraul, one of the biggest demo parties.
<Thihi>
Held annually in Helsinki.
<Thihi>
This was the 20th.
<azonenberg>
thinks asm is better used in kernel mode
<azonenberg>
Not to say i haven't written hundreds to thousands of lines of ring0 MIPS asm for my kernel...
<azonenberg>
But using it for graphics seems a bit silly
<Thihi>
Well, to each his own. I do find well implemented and cool demo effects and especially intros to be essentially Way Cool, but then, I also think your 10 um nyan cat is that. So I guess, keep on hacking, and I'll love it.
<Thihi>
Gotta go.
<azonenberg>
The nyan cat isnt 10um actually
<azonenberg>
that process is a little flaky
<azonenberg>
i made him at 20um per pixel
<azonenberg>
the 15 is obsolete (not much smaller than the 10 but used different optics with serious problems)
<azonenberg>
and the 5 is still being debugged
<azonenberg>
it needs long exposures and my focuser drifts during them
<azonenberg>
so i get all kinds of blurs etc
<wolfspraul>
with 5 um you would be state of the art of the early 70's
<wolfspraul>
not bad
<azonenberg>
Remember MEMS are generally a lot larger than MOS devices though
<azonenberg>
I've seen youtube demos of mems devices from real labs that had parts 30um across
<azonenberg>
i'm already on par with that
<wolfspraul>
oh sure I'm not focused on numbers, I'm focused on understanding potential use cases
<wolfspraul>
or finding them
<azonenberg>
Yeah
<azonenberg>
Point is, CMOS is a lot less likely to be feasible (in terms of building a device of useful complexity)
<azonenberg>
than mems
<azonenberg>
And if it CAN be made to work, it will take longer to develop
<azonenberg>
Both due to the size and the sensitivity to trace metal ions
<GitHub130>
[llvm-lm32] jpbonn pushed 2 new commits to master: http://bit.ly/nfnT2q
<GitHub130>
[llvm-lm32/master] Fixed assembly prefix for local symbols. - JP Bonn
<GitHub130>
[llvm-lm32/master] Merge branch 'master' of github.com:milkymist/llvm-lm32 - JP Bonn
<xiangfu>
aw, Hi
<xiangfu>
aw, I am back :)
<wolfspraul>
xiangfu: hi! :-)
<wolfspraul>
we need a script to read the entire flash (all 32 megabytes) via jtag
<wolfspraul>
then we want to run that script multiple times to read the flash several times, and compare all files with md5sum
<wolfspraul>
do we have such a script already?
<xiangfu>
wolfspraul, not yet. should not hard. I will work on that now.
<xiangfu>
it will very very slow.
<wolfspraul>
how slow?
<xiangfu>
read via jtag. I don't know. I will test it here then let you know the time.
<wolfspraul>
yes
<wolfspraul>
if it's too slow, maybe we limit it to the partitions that are needed for normal operation
<wolfspraul>
normal bitstream, bios, rtems/flickernoise, data (?)
<xiangfu>
we use test boot.bin for verify the images not read via jtag. because it slow :)
<wolfspraul>
yes correct
<wolfspraul>
but we want to be able to compare the contents later on
<xiangfu>
yes. that much faster then whole flash.
<wolfspraul>
boot.bin is part of the test image?
<xiangfu>
ok
<wolfspraul>
my understanding of the process is this:
<wolfspraul>
1) flash test software
<xiangfu>
boot.bin is test image file name
<wolfspraul>
2) run test software, including crc checks
<wolfspraul>
3) remove/reflash test software?
<xiangfu>
no
<xiangfu>
1. flash all images
<xiangfu>
2 upload test image(boot.bin, including crc checks) by serial
<xiangfu>
3) run test image
<wolfspraul>
ah ok
<wolfspraul>
hmm
<wolfspraul>
ok but that way we cannot analyze the flash contents when the board is unreconfigurable
<wolfspraul>
we need a way to read the nor flash via jtag, to the PC
<wolfspraul>
what partitions are loaded in a normal boot process?
<xiangfu>
standby and soc are bitstream, FPGA code.
<wolfspraul>
is there a data partition too?
<wolfspraul>
separate?
<xiangfu>
yes. there is data partition.
<wolfspraul>
ok so it's standby -> soc -> bios -> flickernoise -> data
<xiangfu>
yes separate.
<wolfspraul>
5
<wolfspraul>
alright, the script should read all those
<wolfspraul>
and since we are trying to track down potential flash corruption, there should also be a way to download the entire 32 megabytes flat, into one file
<wolfspraul>
no matter how slow
<wolfspraul>
maybe a script with some options
<xiangfu>
there is one more:Â Â the SPLASH partition. for the SPLASH Picture.
<wolfspraul>
of course the speed is important, so we can practically use the script
<wolfspraul>
if it takes 2 hours to download the entire 32 megabytes that's a problem
<wolfspraul>
but let's start to implement it first
<wolfspraul>
we need more visibility into the flash contents via jtag
<aw>
xiangfu, good to see you are back.
<wolfspraul>
an easy to use script that you can tell to pick a certain partition or set of partitions, or the entire 32 megabytes
<wolfspraul>
xiangfu: ok, then the splash partition too. anything that is in the boot path. but the script should have parameters anyway, so we can quickly use it in different ways.
<xiangfu>
ok
<aw>
roh, the first 60pcs is arrival. no time to see it now. ;-O
<wolfspraul>
great, thanks!
<wolfspraul>
oh wow, cases in Taipei! great!
<xiangfu>
wow that is slow.
<xiangfu>
I am try to read 640K now.
<xiangfu>
640K needs about 5 Minutes
<xiangfu>
32M needs about 4.5 hours
<lekernel>
xiangfu, maybe Adam can load the SoC directly with 'pld load' and then (assuming the BIOS was not corrupted) check the CRCs?
<lekernel>
xiangfu, btw, it would be cool to add raw bitstream (the *.fpg files in milkymist updates) support to UrJTAG
<lekernel>
atm it needs a .bit header
<lekernel>
compared to *.bit files, the *.fpg files have their header stripped and the bits in the words are reversed (to match the flash connection to the fpga)
<lekernel>
or simply write a small fpg->bit conversion program ...
<xiangfu>
lekernel, (pld load soc) it then can CRC on bios and flickernoise.
<lekernel>
you can load boot.bin and check all CRCs
<xiangfu>
oh. yes.
<lekernel>
the only problem you will have is that the bitstream I have uploaded is in raw flash format
<lekernel>
urjtag will need a .bit header
<lekernel>
if you resynthesize it, use the tag "release_1.0", I hacked a lot on the head and I'm not sure of its stability.
<xiangfu>
ok.
<xiangfu>
I will try that.
<lekernel>
aw, if I understand correctly: there are 18 100% pass boards now, cases are there, the only missing parts is boxes?
<aw>
lekernel, 18 pcs available and cases * 60pcs arrival, 45 box and 34 EVA on the way; the rest are still have second ship from Yi includes m1 box, EVA, labels, brochure, and some new stickers.
<aw>
lekernel, the second ship from roh has not been received yet but soon in these may be 2 or 3 days.
<lekernel>
ok, i'm actually wondering when we can ship the first devices out
<lekernel>
this only depends on the second shipment from Yi
<GitHub189>
[linux-milkymist] mwalle pushed 1 new commit to master: http://bit.ly/qz3tr1
<GitHub189>
[linux-milkymist/master] lm32: fix command line parsing - Michael Walle
<GitHub190>
[scripts] xiangfu pushed 2 new commits to master: http://bit.ly/oN7NTI
<GitHub190>
[scripts/master] flash_jtag.sh, fix DATA - Xiangfu Liu
<GitHub190>
[scripts/master] new script file, read m1 flash content to file - Xiangfu Liu