<xiangfu> Hi all.
<xiangfu> I am try to add this option to kernel command line: 'g_ether.host_addr=da:40:9a:d8:78:2a'
<aisa> coi lo'ai xiangu
<xiangfu> but I am not sure if the 'MAC Address' is free to use?
<xiangfu> aisa: Hi. :)
<aisa> xiangfu: you mean not already allocated to a vendor or device?
<xiangfu> aisa: yes.
<aisa> VMWare assigns dynamic mac addresses, so there must be some kind of experimental or open range.
<aisa> and there are most definitely blocks that aren't available,
<aisa> but as a worst case, purchase a network card, record the MAC address,
<aisa> and then never use that card ever again :-)
<aisa> I may misunderstand what you're trying to do...
<wolfspraul> I think 54:52: is reserved as a 'local' range or so
<xiangfu> aisa: nanonote also use the dynamic mac address. but when we reflash the kernel. the mac address changed. then we must remove the old one in .ssh/know_hosts.
<xiangfu> we just need a static mac address for NanoNote
<aisa> how about something like 3l:33:70:....?  :-D
<xiangfu> aisa: if we can just pick one dynamic mac address for static?
<aisa> I'm actually not clear how USB=>ethernet works,
<aisa> so I may not be helpfully contributed to the conversation.
<wolfspraul> 54:52:00:'B':'N':'N' :-)
<wolfspraul> can't find the document that says 54:52 is reserved for local use...
<xiangfu> will offline for 5 ~ 10 mins. back later :)
<wolfspraul> xiangfu: there's a bit that needs to be set, see http://en.wikipedia.org/wiki/MAC_address
<wolfspraul> if the bit is set, it's 'locally administered'
<wolfspraul> so forget the 54:52 stuff, don't know where I got this from. the locally administered bit is not even set there.
<wolfspraul> anything 02:00:00:00:00:00 should work. you can set any of the zeroes to a radomly chosen 'Ben NanoNote' identifier
<xiangfu> wolfspraul: rename to trunking_* done.
<aisa> w00t!  I want to update my repos.
<aisa> what did we do last time?
<aisa> oh right, editted .git/config
<aisa> xiangfu: openwrt_trunk => ??? and openwrt_backfire => ???
<xiangfu> oepnwrt_trunk --> tracking_trunk
<xiangfu> openwrt_backfire --> tracking_backfire
<xiangfu> aisa: ^
<wolfspraul> xiangfu: he, again :-) cool, I think now everybody is happy, we see...
<aisa> I'm deleting the remote branches in my local repository:
<aisa> git branch -rd origin/xburst
<aisa> etc.
<aisa> I've fixed the wiki too.
<xiangfu> aisa: thanks.
<qi-bot> [commit] Xiangfu Liu: this u-boot patch fix the c_size. it should 22bit. http://qi-hw.com/p/openwrt-xburst/67f5520
<xiangfu> just test one commit for make sure commit is works fine. now the email(update local to rename the branch) just sended. :)
<wolfspraul> xiangfu: do you know why the sound modules are not statically compiled into the kernel?
<wolfspraul> btw - my minimal rootfs is actually booting now, my mistake with the 'unable to mount rootfs' was that I didn't do an nerase - forgot how sensitive ubifs is to random data behind the actual filesystem...
<xiangfu> wolfspraul: no. larsc decide not compile into kernel.
<xiangfu> wolfspraul: I also don't know why.
<wolfspraul> ok
<wpwrak> gaah. way too much stuff.
<wpwrak> wolfspraul: data point: (from early last week) usp did a wifi chip design
<wpwrak> wolfspraul: data point: everybody but red hat seems to be unhappy about glib, yet not quite ready for a real fork
<qi-bot> [commit] Niels: don't perform action if a modifier is pressed http://qi-hw.com/p/nanomap/bf6b566
<qi-bot> [commit] Niels: move handling of application parameters to main.cpp http://qi-hw.com/p/nanomap/4e98efe
<qi-bot> [commit] Niels: add option to skip existing tiles while downloading; based on patch by Mikhail Peselnik http://qi-hw.com/p/nanomap/bfd639f
<wpwrak> data point (to no one in particular): despite my most accurate retelling of my experience making my usrp2 work, christoph didn't die laughing, although i think he was close :)
<wpwrak> now i have to figure out how to get my noise floor for +/-5Mhz or more below -30 dB ...
<wpwrak> (mac address) the company_id will come back for 802.15.4, too
<wolfspraul> hmm, overloaded
<wolfspraul> usp did a wifi chip design?
<wolfspraul> who is usp? and why do you mention this?
<wpwrak> wolfspraul: so it seems. how to procees ?
<wpwrak> wolfspraul: usp = university of sao paulo (info from maddog)
<wolfspraul> why should christoph laugh about your usrp2 work?
<wpwrak> (usrp2) because it's particularly kafkaesque :)
<wpwrak> in fact, kafka himself may have drawn inspirations from it :) all the instructions lead you in the wrong way, etc.
<wolfspraul> where is the url of that wifi chip design project, is it properly (freely) licensed, and is it actually working?
<wpwrak> (wifi) i still have to figure out these things ...
<wolfspraul> unfortunately academia has degenerated to 'who can make the most outlandish claims in a paper with a straight face' competition, so I won't hold my breadth...
<wpwrak> wel, there's a broad range for "wifi".  see that 802.11 module by microchip :)
<wolfspraul> answerin my own questions - no url, license 'not yet decided' (it's cool stuff, talking to qualcomm, indian government, south african government, and others), working: sure :-)
<wpwrak> so i don't know what they really did. but then, from what i've seen so far, they're serious about their work.
<wpwrak> probably an abandoned project by now (my guess)
<wpwrak> (gov) usp tend to have their finger on the pulse of the brazilian government ;-)
<wpwrak> so my main concern wouldn't be in the quality of their work (in the case of the wifi) but what may have been lost in the telling
<wpwrak> another data point: ESA apparently put some SPARC core on some satellites. that core should be Free and implementable. might be a plan B for milkymist.
<wpwrak> (plan B) sometimes, it's good enough to have a plausible plan B to advance with plan A ;-)
<wolfspraul> esa has this leon stuff
<wpwrak> that may be the one
<wolfspraul> but how does it help with Milkymist?
<wpwrak> it's an lgpl core whose non-open roots may be older than 20 years
<wpwrak> milkymist may still encounter IP issues
<wpwrak> the probability of encountering IP issues decreases with the availability of alternatives ;-)
<wolfspraul> which ones?
<wolfspraul> sure, but I'm not paying the fear tax
<wpwrak> (quite drastically so, in fact :)
<wpwrak> it's the antidote for the fear tax :)
<wolfspraul> since I don't pay the fear tax, I don't need the antidote either
<wpwrak> heh ;-) but it's good to have a remedy for the taxman, too :)
<wolfspraul> if you think there is an actual 'IP issue' we should look at it and clean it up sooner rather than later. and if we are not aware of any, that's it at that moment.
<wpwrak> i think it's a conditional ip issue. if lattice feel they should create some problems, they could.
<wpwrak> if the feel it's pointless, they won't.
<wpwrak> (or, of course, if they feel they should support what we're doing)
<wolfspraul> anybody can 'create problems' if they feel like
<wolfspraul> do you really see a problem somewhere or just spending too much time looking at nothing?
<wolfspraul> or you just can't believe that a company 'open sources' something, like Android?
<wolfspraul> Google holding back some patents, for tax day?
<wpwrak> sure. my point is that the existence of the free and proven to be useful SPARC dramatically increases our BATNA
<wolfspraul> come on, we can spend all our lives discussing this stuff...
<wolfspraul> I've looked at SPARC for a long time.
<wolfspraul> met with people, companies
<wolfspraul> I'm sure Sebastien would know more from the tech side.
<wolfspraul> I feel much better with Mico32
<wolfspraul> Sparc is used in military and space, quite a lot.
<wpwrak> in his paper, he didn't mention that sparc variant. he just commented on another, much more complex one.
<wolfspraul> those are customers who are paying 10,000 USD and more per chip.
<wolfspraul> oh the LEON project is very well known
<wpwrak> i don't have a problem with mico32. what i'm saying is that the possibility of using a sparc could make mico32 a more stable choice.
<wolfspraul> I forgot all the details that led me to eventually join Milkymist.
<wolfspraul> a quick look at Wikipedia says LEON has a dual-licensing model and a commercial license if you want to embed it in a 'proprietary product'
<wolfspraul> I would think, already from the distance, that there are many more IP issues there. Are they OK with someone manufacturing LEON in ASIC under the LGPL?
<wpwrak> sounds fair so far
<wolfspraul> I'm always very careful about dual-licensing models.
<wolfspraul> Lattice is not doing that, they have an open core (totally open from their perspective), and proprietary enhancements around it.
<wolfspraul> like Android
<wolfspraul> Lattice believes that the quality of their proprietary peripherals will make someone pay them anyway, then open core is just to get started (for them).
<wolfspraul> now - if we take the open core, and add open peripherals around it - that's our choice.
<wolfspraul> I will try to talk to Lattice still one day, just not super high priority right now.
<wolfspraul> you can ask Sebastien what he thinks about LEON, I actually never talked to him about it.
<wolfspraul> I met with several companies last year that are making military ICs around Sparc. Interesting. Had no idea what kind of businesses exist :-)
<wolfspraul> but once one chip costs 10,000 USD the whole calculation kind of changes, in terms of 'moq', tape-out fees, etc.
<wpwrak> hmm, can't find clear information on the leon's licensing situation
<wolfspraul> even 100 chips is already a million USD then, can get a lot of stuff done :-)
<wpwrak> sure:)
<wolfspraul> but I can't work with these companies to make chips for consumer electronics, ever
<wpwrak> but leon is based on a very old sparc design. so there should be no relevant patents.
<wolfspraul> for the instruction set, yes
<wolfspraul> from an IP perspective, there is nothing, absolutely nothing, wrong with Mico32
<wolfspraul> it's as clean as it can get, comparable like I said maybe to something like Google's Android
<wolfspraul> Lattice has strategic motivations to open up this core
<wpwrak> also the sparc architecture is quite old by now :) well, perhaps missing a few years. but not much
<wolfspraul> not altruistic
<wolfspraul> but the opening itself is done in a clean and professional way, and a company is standing behind it
<wpwrak> (mico32) again, i'm not saying that there's anything wrong with mico32. i'm just saying hat there may be a plan B.
<wolfspraul> if there would be a patent issue against Mico32, I would expect Lattice to defend it, after all they have (proprietary) business attached to it
<wolfspraul> Sebastien mentioned several recently, didn't see LEON though
<wolfspraul> we need to ask him about LEON
<wolfspraul> LEON at least is definitely real
<wpwrak> when talking to people who think all you have is plan A, and they control plan A, that may give them ideas. having a plan B may eliminate these ideas.
<wpwrak> (sebastien and leon) yup
<wolfspraul> yes, but: Lattice has said this is an open IP, they themselves stand behind it.
<wolfspraul> that's as if Google would suddenly come out with a press release saying "sorry guys, we have some Android patents and everybody has to pay now"
<wpwrak> i was thinking of this more as a data point of possible use for your meeting :)
<wolfspraul> Lattice's business reason is the proprietary IP around the open core
<wpwrak> is it the ip or the chips ?
<wolfspraul> I think IP, but I don't know Lattice's business very well.
<wolfspraul> they probably license whole IP packages to customers, with their own open core, plus proprietary peripherals/enhancements.
<wolfspraul> if you look at it that way you also see why they need an open core: to spread their design, which otherwise would be seen as totally obscure/proprietary.
<wpwrak> that would be good for us
<wolfspraul> yes but I am guessing, I need to talk to some real people first
<wpwrak> well, there can be many reasons for "open". sometimes, the term gets twisted. but it's good if you can obtain clarification.
<wolfspraul> wpwrak: wrong. Lattice mainly sells FPGAs and CPLDs
<wolfspraul> they seem to have not been doing very well in the last 10 years, if Wikipedia is painting a realistic picture my feeling is they had a lot of changes of direction.
<wolfspraul> 770 people
<wpwrak> that's indeed why i'm a bit concerned.
<wolfspraul> so who knows when and why they started this Mico32 effort, and whether the people in charge of the strategy back then are even still there :-) Publicly there has not been much new stuff been released around Mico32 since 2008, I think.
<wpwrak> there's a certain tendency among "closed" companies to "open" things when they are already broken beyond repair.
<wpwrak> so this could be that
<wpwrak> or it could be somthing else, of course L(
<wpwrak> L( = :)
<wolfspraul> yes. so let's leave it there until someone actually talks to someone from Lattice.
<wolfspraul> the world is still driven by humans
<wolfspraul> it's amazing what you can find out sometimes by just talking to people
<wolfspraul> and we should quiz Sebastien about LEON. good point!
<wpwrak> yup. sounds good to me. i just wanted you to know about the leon alternative, because sebastien dismissed all of sparc based on a different design.
<wpwrak> (humans and talking) indeed :)
<qi-bot> [commit] kyak: NanoMap: "skip downloaded tiles" is upstream. http://qi-hw.com/p/openwrt-packages/74176f0
<wpwrak> for the talks with lattice, i would encourage them to call the "mico32" the "lattice mico32". i mean, who even recalls they still exist ? :)
<qi-bot> [commit] kyak: NanoMap updated to Commit bfd639fd99e6e77cb58b9649a7ddb1c03068ef2d http://qi-hw.com/p/openwrt-packages/0a3c8a2
<lekernel> wpwrak, I did mention ESA's SPARC in my paper (2.2, §2)
<lekernel> it's well documented, clean and probably bug-free; but slow and bloated
<lekernel> if you want to talk to Lattice, there's Johnathan on the Milkymist list who's a Lattice employee
<lekernel> he subscribed/posted by himself, I did not talk to them
<kyak> xiangfu: hi
<xiangfu> kyak: hi
<kyak> should i now change from openwrt_backfire to tracking_backfire?
<kyak> git pull says:
<kyak> * [new branch]      tracking_backfire -> origin/tracking_backfire
<kyak> * [new branch]      tracking_trunk -> origin/tracking_trunk
<kyak> Your configuration specifies to merge with the ref 'openwrt_backfire'
<kyak> from the remote, but no such ref was fetched.
<xiangfu> kyak: yes. you better do that.
<kyak> why is it called like this?
<xiangfu> kyak: tracking_backfire is better then openwrt_backfire.
<xiangfu> it's more apropos :)
<kyak> all right
<wolfspraul> kyak: no rename is complete with at least another, immediately following rename
<kyak> wolfspraul: so true :)
<bartbes> I still can't build gforth..
<bartbes> stil the same error too:
<bartbes> vm.push_string("GetAllSetNames"); vm.push_cfunction(get_all_set_names); vm.set_table(-3);
<bartbes> ehm
<bartbes> not that
<bartbes> :P
<bartbes> make[3]: *** No rule to make target `kernlb.fi', needed by `gforth'.  Stop.
<bartbes> that
<bartbes> (preceded by asm_fs not being found)
<qi-bot> [commit] Wolfgang Spraul: added config.miminal http://qi-hw.com/p/openwrt-xburst/e19e456
<qi-bot> [commit] Xiangfu Liu: config.full_system: add at, file, gsm-utils, i2c-tools, jpeg-tools http://qi-hw.com/p/openwrt-xburst/ea5d4e5
<wpwrak> lekernel: ah, so that included the LEON. i thought you were talking about some later SPARC, as the LEON is supposedly simple. so it isn't quite that nice :(
<wpwrak> wolfspraul: (renames) someone should collect quotes for the weekly news ;-)
<lekernel> wpwrak, i talked both about opensparc and grlib/leon/esa sparc (which are the same project)
<wpwrak> lekernel: ah, i see. didn't realize they were the same. pity. would be nice to have more viable choices around.
<lekernel> well LM32 is quite nice, even if widely disregarded
<lekernel> even clones of crappy processors like the 6502 seem more popular
<wpwrak> (6502) hehe, that's true :)
<lekernel> but I guess this is the hardware hacker equivalent of the "dancing pigs" problem of the security hacker
<lekernel> also it seems (to me) that some FPGA begineers tend to prefer crappy stuff because they think properly designed stuff would be too complicated for them
<wpwrak> heh :) well, 6502 is arguably well-established. some may even have childhood memories :)
<djbclark> kristianpaul: sorry what was the question?
<wpwrak> heh, another "gpios via mmap" binding. now we have C, LUA, Gforth, Python in the works.
<wpwrak> hmm, how to design a DIY anechoic chamber for RF testing ... wikipedia says it can't be done cheaply :-(
<wpwrak> or maybe just wait till late at night, when most RF generated in immediate response to human actions disappears :)
<qi-bot> [commit] Werner Almesberger: Updated to do list. http://qi-hw.com/p/ben-wpan/d14e55b
<qi-bot> [commit] Werner Almesberger: atusd/tests/psd*: first transmit power spectral density measurement http://qi-hw.com/p/ben-wpan/4c81175
<wpwrak> DocScrutinizer: Q: when picking small ceramic capacitors, there are the general-purpose type and special RF caps. the parameters that are quantified look pretty much the same. so is there really that much of a difference ?
<DocScrutinizer> possibly yes
<DocScrutinizer> general purpose may have unwanted resonances and whatnot, at RF freq
<DocScrutinizer> wpwrak: (anechoic) I guess wikipedia is right
<DocScrutinizer> goes googling "dancing pigs"
<wpwrak> DocScrutinizer: (resonances) hmm. wish they'd specify such things in way suitable for parametric matching.
<DocScrutinizer> wpwrak: the parasitary effects aren't specified or tested for on components that are 'not for RF usage'. So they simply can't specify such things precisely, asd they may vary largely even on one lot of components
<wpwrak> oh, i see. so it's really not good to pick the non-RF ones.
<lekernel> how high is RF?
<wpwrak> lekernel: up to 2.48 GHz
<osokuro> hi all.
<lekernel> ah, pretty high :)
<lekernel> I have the dream of DIY MMICs
<lekernel> the microwave band (and beyond) is really hard to get with, and a lot of circuits are non-reproducible because they use very specific/hard to find/super-expensive components
<osokuro> Any idea how sputtering differs from PVD or CVD?
<lekernel> sputtering is pvd (afaik)
<osokuro> Ah, okay.
<lekernel> with CVD instead of evaporating the final material directly, you use for example a gas that decomposes itself (via a chemical reaction, hence the name) into the final material on your target
<lekernel> that's how I understood it
<osokuro> Ah! You've just taught me something. Thank you.
<osokuro> (because I did not know the difference)
<lekernel> the main problem with all that off-the-shelf vacuum equipment is it's expensive as hell
<lekernel> it's convenient, but it's just horribly expensive
<lekernel> are about 300 euros
<osokuro> That's a high-voltage anode or cathode?
<lekernel> it's just a stupid feed through, ie isolated wire that goes into the vacuum
<lekernel> and you are supposed to spend 300 euros on each
<osokuro> So the real key is someone figuring out a cheap way to grind/lap the mating surfaces.
<lekernel> yeah, with little outgasing and vacuum tightness
<lekernel> maybe making vacuum chambers out of glass (like CRTs) would be cheaper
<osokuro> and then asking "do we really need to use difficult-to-process stainless steel or nickel alloys.
<osokuro> Ooo. Now there's a thought.
<osokuro> Nice thick borosilicate or maybe even soda-lime glass.
<lekernel> and for feed throughs you can melt the glass and insert the electrode (the actual technique for acheiving a tight and reliable joint is a bit more complex though)
<lekernel> but they are virtually free, they only cost some gas, electric wire and a bit of time
<lekernel> not 300€
<lekernel> I found a French manual from the 1920s that explains how to do :)
<osokuro> Ahhh. And the technique is applicable to very thick walls?
<lekernel> hmm... if you can melt it, yes :)
<lekernel> blowing glass is something I should learn someday, but so much things, so little time
<osokuro> Sounds like it's a good fit with your goals. Might be a priority.
<lekernel> so is finishing milkymist, writing fpga synthesis tools and what not :)
<osokuro> Speaking of which, is MM seen as a potential replacement for the XBurst in a future nanonote-like platform?
<lekernel> ever seen that?
<osokuro> Hah! That's fantastic!
<lekernel> yeah, Wolfgang thought about it, and maybe it'll happen in the future
<lekernel> but it's not a priority for me
<lekernel> this whole PWL website is about DIY vacuum tubes and neons
<lekernel> when I get a chance I should travel to Warsaw and meet up with this guy :)
<lekernel> i'm doing 25% of the road tomorrow btw :p
<osokuro> which road?=
<lekernel> moving from Paris to Berlin, then Warsaw is about 1000km more in the same direction :)
<osokuro> Ahhh. Then that's a long weekend!
<osokuro> We'll be well served in building out future in looking back at our past.
<lekernel> hmm... less than that actually, only 600km from Berlin... but i've heard Polish roads are crazy
<osokuro> I knew an operator of antique radio sets who died a few years ago. Made his own bakelite circuit boards from scratch. Wish I'd asked him how.
<lekernel> there is like a dozen antique radios lying in my mother's attic... I used to repair them when I was in high school
<lekernel> or use the tubes for other purposes, like making pirate radio transmitters
<lekernel> that was fun
<osokuro> I believe it.
<lekernel> I could get them easily and cheap at local second hand markets
<lekernel> even bought a box of more than 100 various tubes in new condition for 15€ one day
<lekernel> from an old repair shop that closed
<osokuro> Guess that's why I'm hanging around here.
<osokuro> Nearly everything we've built is useful. Many people today forget that.
<osokuro> (can anyone point me to simple instructions for flashing Debian to the nanonote?)
<qi-bot> [commit] Werner Almesberger: Removed DTC123JE transistor files. (Was used only in 20100903 design.) http://qi-hw.com/p/ben-wpan/876a5ca
<qi-bot> [commit] Werner Almesberger: Applied clock voltage divider fix and corrected too closely spaced via. http://qi-hw.com/p/ben-wpan/f17613b
<qi-bot> [commit] Werner Almesberger: Added Digi-Key catalog data for automated BOM processing. http://qi-hw.com/p/ben-wpan/6fc656f
<qi-bot> [commit] Werner Almesberger: bom/: automatic BOM generation (work in progress) http://qi-hw.com/p/ben-wpan/1a5d9f5
<qi-bot> [commit] Werner Almesberger: Corrected small footprint errors. Made 0R "inductor" a resistor. http://qi-hw.com/p/ben-wpan/5d28e1b