<qi-bot>
[commit] acoul: ixp4xx: fix MAC parsing and switch (unmanaged) functionality for wrt300nv2 (thank you Ernesto Elbe) http://qi-hw.com/p/openwrt-xburst/75c6116
<qi-bot>
[commit] nbd: remove brcm47xx symlinks to brcm-2.4 (unfortunately svn does not allow a proper type changing commit) http://qi-hw.com/p/openwrt-xburst/c791c2b
<qi-bot>
[commit] nbd: remove the brcm-2.4 target, it will no longer be supported in future releases. please use brcm47xx with broadcom-wl instead http://qi-hw.com/p/openwrt-xburst/1fe4998
<qi-bot>
[commit] cshore: busybox: Fixed remote logging bug in which starting syslog before the network (and hence the remote host being available) results in failure to do any remote logging http://qi-hw.com/p/openwrt-xburst/03dd7f3
<qi-bot>
[commit] cshore: block-extroot, block-mount: Fixed multiple bugs which prevented e2fsck from being executed on the external root filesystem before mounting it as root.  Added /etc/e2fsck.conf which indicates that the clock is broken (since most OpenWRT devices don't have a battery backed RTC) so that e2fsck will not exit with fatal error when the rdat has not yet been run (i.e. before network). http://qi-hw.com/p/openwrt-xburst/7bc978b
<qi-bot>
[commit] nbd: ath9k: fix false positives in the baseband hang check by repeating the test a few times before pronouncing the hardware dead and resetting it http://qi-hw.com/p/openwrt-xburst/7d97750
<qi-bot>
[commit] nbd: ag71xx: fix a memory corruption bug that happens if you flood the interface with packets while it's being brought down http://qi-hw.com/p/openwrt-xburst/950d12e
<qi-bot>
[commit] nbd: ag71xx: reset the hardware during open(), this improves recovery from tx timeouts on ar724x considerably http://qi-hw.com/p/openwrt-xburst/d856215
<qi-bot>
[commit] nbd: mini_fo: add error pointer checks after dentry lookups to fix various crash bugs (fixes #7277, #7207, #7259) http://qi-hw.com/p/openwrt-xburst/14cab98
<qi-bot>
[commit] jow: [package] comgt: add usb hotplug handler to bring up 3g ifaces on boot or when the dongle is attached http://qi-hw.com/p/openwrt-xburst/b11b5fb
<qi-bot>
[commit] nbd: ar71xx: only reinit the ethernet MAC at .open() on ar724x for now, until we've figured out what part of it causes the issue described in #7563 http://qi-hw.com/p/openwrt-xburst/f381433
<qi-bot>
[commit] nbd: repair the damage that was done to the packet socket type filter patch when it was forward ported to 2.6.33 http://qi-hw.com/p/openwrt-xburst/9b8cc43
<qi-bot>
[commit] nbd: mac80211: update to wireless-testing 2010-07-06, add another patch to finally fix the annoying buffer leak in ath9k http://qi-hw.com/p/openwrt-xburst/9f4c286
<qi-bot>
[commit] nbd: wifi: fix duplicate ht capabilities in the hostapd config file by clearing the list at config load time http://qi-hw.com/p/openwrt-xburst/098781b
<qi-bot>
[commit] hauke: kernel: add missing dma_dev member to struct ssb_device to make b43/b43legacy compile with current mac80211 version http://qi-hw.com/p/openwrt-xburst/a04d4f8
<qi-bot>
[commit] cshore: [package]: block-mount:  Enable swap before doing fsck so that large filesystem checks have swap as well as memory (as they take large memory for large partitions).  Closes #7599. http://qi-hw.com/p/openwrt-xburst/52993b9
<qi-bot>
[commit] cshore: [package]: block-mount: Fixed two bugs in fstab.init.  /etc/fstab was used where /tmp/fstab should have been, and locking was insufficiently careful and was such that it could result in deadlock when hotplug was in use. http://qi-hw.com/p/openwrt-xburst/36d52e8
<qi-bot>
[commit] cshore: [package] block-mount: Attempt swapon a after mounting as well as before.  This ensures that swap on a filesystem is enabled. http://qi-hw.com/p/openwrt-xburst/c98e83d
<qi-bot>
[commit] nbd: ep80579-drivers: the build system for this package is broken beyond repair. work around this by only using the kbuild make invocations and ignoring the other crap http://qi-hw.com/p/openwrt-xburst/79debaf
<qi-bot>
[commit] cshore: [package] base-files & telnet: Fixed telnet starting even with root password when shadow passwords in use. http://qi-hw.com/p/openwrt-xburst/b1acaee
<qi-bot>
[commit] jow: [package] nvram: handle nvram at varying offsets within the eraseblock (fixes Edimax PS-1208mfg with FLSH at offset 0) http://qi-hw.com/p/openwrt-xburst/98b06e8
<qi-bot>
[commit] nbd: move the crda dependency to the kmod-cfg80211 package, get rid of crda's dependency on mac80211. this fixes circular dependency issues http://qi-hw.com/p/openwrt-xburst/0e2c7a5
<qi-bot>
[commit] nbd: kernel: add the new 'crashlog' feature, which tries to store kernel oops/panic logs in a fixed location in RAM to recover them after the reboot and make them available to user space using debugfs http://qi-hw.com/p/openwrt-xburst/5b42ce6
<qi-bot>
[commit] nbd: gcc: split up the build process into three distinct stages (minimal, initial, final), to clean up the dependency handling nastiness and to improve support for rebuilding parts of the toolchain http://qi-hw.com/p/openwrt-xburst/344914c
<qi-bot>
[commit] nbd: add a build system option for collecting all kernel debug information (including modules) in a tarball http://qi-hw.com/p/openwrt-xburst/7b7e470
<qi-bot>
[commit] nbd: squashfs4: backport an upstream change to fix the file mode check to allow setuid/setgid binaries (thx, ermo) - fixes #7653 http://qi-hw.com/p/openwrt-xburst/f2f28c8
<qi-bot>
[commit] nbd: ar71xx: add support for the tp-link tl-wa901nd devices (patch by Pieter "Fate" Hollants, from #7528, without the ethernet fifo cfg values) http://qi-hw.com/p/openwrt-xburst/858ebac
<qi-bot>
[commit] jow: [atheros] renaming of the IP175C switch driver brioke switch detection on the Dir-300 and others, fix it http://qi-hw.com/p/openwrt-xburst/8c71102
<qi-bot>
[commit] cshore: [package] dropbear: Explicity list default RootPasswordAuth value in default config file so that users know to turn off RootPasswordAuth as well as PasswordAuth to prevent password logins as root. http://qi-hw.com/p/openwrt-xburst/dbf1301
<qi-bot>
[commit] nbd: ar71xx: remove the fifo cfg overrides for the ap91 ethernet code - these values have been wrong on every single device i've tested, falling back to the atheros values seems to be the right thing to do http://qi-hw.com/p/openwrt-xburst/a0d848e
<qi-bot>
[commit] nbd: kmod-ipsec: fix a compile error with some configurations. since CONFIG_XFRM_IPCOMP is not selectable on its own (no prompt), always select CONFIG_INET_IPCOMP along with it, to make sure that it gets enabled http://qi-hw.com/p/openwrt-xburst/bffb902
<qi-bot>
[commit] nbd: mac80211: update to wireless-testing 2010-07-26 + pending patches - adds a change that might fix some calibration issues http://qi-hw.com/p/openwrt-xburst/f7ff2ae
<qi-bot>
[commit] jow: [buildsystem] make base-files dependent on opkg host compile, fixes install errors when package/compile and package/install are invoked separately http://qi-hw.com/p/openwrt-xburst/b31d05c
<qi-bot>
[commit] acoul: generic/patches-2.6.34: Make devtmpfs available on (embedded) configurations without SHMEM/TMPFS, http://qi-hw.com/p/openwrt-xburst/2122c93
<qi-bot>
[commit] nbd: ath9k: improve stuck beacon recovery and noise floor handling. significantly improves stability under strong interference in ap mode http://qi-hw.com/p/openwrt-xburst/8132fc9
<qi-bot>
[commit] nbd: ath9k: improve stuck beacon recovery by reading nf values from the hw when a calibration is pending (instead of waiting for the next cal interval) http://qi-hw.com/p/openwrt-xburst/4b368f4
<qi-bot>
[commit] cshore: [brcm63xx] base-files: brcm63xx.sh: Added comtrend (96348GW-11) to routers with buttons and leds on preinit http://qi-hw.com/p/openwrt-xburst/b1544d6
<qi-bot>
[commit] cshore: [brcm63xx]: base-files: diag.sh: For power button as preinit status led, end with led left on, not off http://qi-hw.com/p/openwrt-xburst/53a9db6
<qi-bot>
[commit] jow: [package] base-files: r22444 caused interfaces to remain down if the macaddr option is used, fix it. Also localize the txqueuelen option variable  http://qi-hw.com/p/openwrt-xburst/8eea743
<qi-bot>
[commit] jow: ip17xx: r21709 broke VLAN functionality on the IP175C switch, add back mdelay() to wait before reading back the phy state, fixes ethernet on the DIR-300 and possibly others http://qi-hw.com/p/openwrt-xburst/fe9e702
<qi-bot>
[commit] mirko: nptl-supoprt should not autoselect EXTRA_WARNINGS as this results in extra CFLAGS which may not be supported by older compilers (as e.g. gcc-4.1 which e.g. the x86 target is currently using) http://qi-hw.com/p/openwrt-xburst/040075b
<qi-bot>
[commit] hauke: brcm47xx: do not generate image for wgr614_v8 as long as we did not get any positive reports with that device. http://qi-hw.com/p/openwrt-xburst/6196853
<qi-bot>
[commit] acinonyx: [package] dnsmasq: Squelch a 'touch' error when no dhcp leases file is defined in config, thanks stsp (#7720) http://qi-hw.com/p/openwrt-xburst/d9deabc
<qi-bot>
[commit] jow: [package] uhttpd: add option to reject requests from RFC1918 IPs to public server IPs (DNS rebinding countermeasure) http://qi-hw.com/p/openwrt-xburst/fd370b6
<qi-bot>
[commit] jow: [kernel] ssb: give the PCI core more time to initialize, fixes PCI issues with Atheros cards on the Asus WL-500w and possibly others (#4710) http://qi-hw.com/p/openwrt-xburst/79af254
<qi-bot>
[commit] jow: [ar71xx] add uci-defaults script to migrate vlan 0 to vlan 1 after sysupgrade on devices using the RTL8366s switch http://qi-hw.com/p/openwrt-xburst/698224c
<qi-bot>
[commit] nico: package/grub: add a prereq check for 32 bits host development files when building on x86_64 (closes: #7753) http://qi-hw.com/p/openwrt-xburst/2a449c9
<qi-bot>
[commit] nbd: ath9k: remove an unnecessary BUG_ON in the aggregation code and clean up block ack window tracking to use less memory http://qi-hw.com/p/openwrt-xburst/94f6a65
<qi-bot>
[commit] jow: [package] 6in4: bypass uci state when reading local IPv4 addr, specify TTL during tunnel creation (#7769) http://qi-hw.com/p/openwrt-xburst/28ddaa0
<qi-bot>
[commit] nbd: toolchain: fix the sysroot mess by getting rid of $(TOOLCHAIN_DIR)/usr and moving it back to $(TOOLCHAIN_DIR), this change makes the toolchain relocatable again, which should fix the SDK http://qi-hw.com/p/openwrt-xburst/dc74adf
<qi-bot>
[commit] nbd: kernel: speed up building kernel packages by getting rid of unnecessary CompareKernelPatchVer calls http://qi-hw.com/p/openwrt-xburst/67dac5c
<qi-bot>
[commit] nbd: scripts/feeds: switch to the right feed metadata when installing a package to fix dependency handling (patch by matthijs from #5891) http://qi-hw.com/p/openwrt-xburst/30d6c70
<qi-bot>
[commit] nbd: ath9k: fix a WARN_ON when aggregation start is issued more than once, should improve stability with 802.11n http://qi-hw.com/p/openwrt-xburst/6361f69
<qi-bot>
[commit] nbd: rtl8366_smi: when setting VLAN ports, always initialize the PVID to ensure that the VLAN MC entry gets allocated. Fixes problems with tagged-only ports (#7795) http://qi-hw.com/p/openwrt-xburst/a9266bc
<qi-bot>
[commit] nbd: add a command for printing a cleaned up make target database - will be used to analyze package dependencies at some point http://qi-hw.com/p/openwrt-xburst/9dd40f1
<wolfspraul>
xiangfu: I think your merge triggered a couple hundred commitlog lines here :-)
<xiangfu>
wolfspraul: yes. it's 500+.
<wolfspraul>
at least we know now that the commitlog scripts are stable. we might think about an upper limit?
<larsc>
wolfspraul: please ban the bot
<wolfspraul>
larsc: I was hoping it's over soon, hold on... :-)
<wolfspraul>
woops. that wasn't me.
<wolfspraul>
maybe we saw all commits now. not very informative of course...
<wolfspraul>
xiangfu: what merge was that?
<xiangfu>
merge the upsteam to our "master" branch
<xiangfu>
wolfspraul: I saw the upstream already switch to 2.6.35. but we are still 2.6.32.
<wolfspraul>
maybe openwrt backfire still uses 2.6.32. the plan was to follow the backfire release I think.
<wolfspraul>
larsc: what do you mean with 'ban the bot'?
<wolfspraul>
it's funny before we had an implicit commitlog limitation, it was cut off after 1024 bytes. then we thought that's not good because mirko's merges 'crash the bot'. now it's unlimited but may also not so good.
<wolfspraul>
so should we cut off after 20 commits or so?
<larsc>
probably a good idea
<wolfspraul>
git log has a -<n> parameter so that's easy to do
<wolfspraul>
but the bot won't say "more commits..." or so, so some people may feel something is wrong too
<wolfspraul>
larsc: alright then, let's just do it
<wolfspraul>
20 is enough?
<emeb|mac>
wolfspraul: just saw your email about ASIC dev
<wolfspraul>
ah great. you want to invest 100 million USD?
<emeb|mac>
Wish I had that much to play with...
<emeb|mac>
interesting perspective
<emeb|mac>
making a hard version of the Milkymist FPGA design seems like a good start
<emeb|mac>
but that can be pretty expensive too.
<emeb|mac>
used to work in chip design
<wolfspraul>
larsc: I added a -20 parameter to git log, hope that works
<wolfspraul>
we find out next time :-)
<larsc>
good
<wolfspraul>
xiangfu: on your next merge, you can be more relaxed. we should only see 20 commitlog lines (not sure the first or last 20)
<wolfspraul>
not your fault, all me here with the setup. have fun merging, just make sure everything stays clean...
<wolfspraul>
emeb|mac: I like the way this Jim Turley wrote about the challenge. we need to find a way to get at least some visibility with these old-school industry guys. make them at least laugh about it, and follow a little...
<wolfspraul>
and who knows, maybe someone will even develop some sympathy I don't know
<emeb|mac>
wolfspraul: that's an idea
<wolfspraul>
it will take several years, it's similar to the Linux kernel emerging in the early 90's. can a group of loosely connected individuals who volunteer some time and their savings ever come up with anything that actually works? we will see
<wolfspraul>
at least it's well understood how the clasically process works, and knowing that and learning from it is always good I think
<wolfspraul>
emeb|mac: did you have some time to peek over Xue btw?
<emeb|mac>
wolfspraul: grabbed the latest KiCAD db & started looking.
<emeb|mac>
then entropy set in...
<emeb|mac>
Still trying to free up some time for a close look
<emeb|mac>
looks like more progress since my last pull though so I'll update
<wolfspraul>
ok it's a start. thanks!
<wolfspraul>
if you worked in IC design before and have some people that might be interested in Milkyist, please introduce it to them and point to the project
<emeb|mac>
sure - keeping an eye on it.
<wolfspraul>
I am interested in putting this into a more professional context, financially, break out some stuff into ASIC etc. but there needs to be a commercial reasons, we cannot just produce expensive unsellable toys.
<emeb|mac>
I guess I'm still wondering what the MM design brings to the table besides open source.
<wolfspraul>
yes first of all just that - it protects the users freedoms
<emeb|mac>
so the question is how much is that worth in cash to an end user
<wolfspraul>
I believe once educated about it, it can both be a lot of people and they will see a significant value in it.
<emeb|mac>
that's good.
<wolfspraul>
I'm not so worried that freedom has no value, I am more worried to do it right, that it is actually different from others, and to make products with it that actually work well and are easy to use.
<emeb|mac>
from a development standpoint do you see this being done with OS tools to the maximum extent possible?
<wolfspraul>
what is 'this'? and what 'OS tools' do you mean?
<emeb|mac>
this = MM ASIC, OS tool = ASIC dev tools done w/ open source
<wolfspraul>
ah
<wolfspraul>
we are not at the ASIC step yet, and for the entire Milkymist I don't think will be for years or until we find a commercial partner to pull it off with
<wolfspraul>
also one would ask 'why' to go into ASIC at all? reprogrammable is not bad!
<emeb|mac>
that's a realistic development path.
<emeb|mac>
agree
<emeb|mac>
and preserves the value of the open source code nature of the design
<wolfspraul>
so first there needs to be a product where the IC design we have is super stable and bug free and optimized, and someone doesn't mind to remove programmability!
<wolfspraul>
we don't have that today, not nearly
<wolfspraul>
then there needs to be a reason to go ASIC, for example economical
<wolfspraul>
say the fpga costs 40 USD
<emeb|mac>
but even once the design is stable, reprogrammable HW is an advantage in many cases.
<emeb|mac>
and FPGA costs will continue to come down.
<wolfspraul>
a general Chinese rule of thumb (ignoring cost differences in processes) is that whenever you need 10K of any IC, it's cheaper that you make your own IC
<wolfspraul>
that's very Chinese of course, but you get the idea
<emeb|mac>
that threshold is lower than I would have expected
<wolfspraul>
well FPGAs will always have a proprietary premium, of course since they do contain lots of proprietary IP
<wolfspraul>
yes, China
<wolfspraul>
but it's probably only true for 90nm or larger
<wolfspraul>
anyway
<wolfspraul>
10k*40 = 400k USD
<wolfspraul>
I wouldn't want to take on a 45nm product with 400k USD
<wolfspraul>
but at some point the logic will in fact kick in
<wolfspraul>
and it's cheaper to go asic, because you remove the proprietary IP of the fpga
<wolfspraul>
so that's one angle
<emeb|mac>
even 90nm at that price point is pushing it based on the numbers I know
<wolfspraul>
in China that is the rule of thumb, I am relaying from talking with industry people here
<emeb|mac>
that's true -
<wolfspraul>
so another angle is that we may want to do our own free GPL fpga one day
<emeb|mac>
there's an interesting thought
<wolfspraul>
so maybe the first 'asic' we make is actually a small fpga?
<wolfspraul>
I don't know
<wolfspraul>
it's hard to predict all these things, I am trying to steer through it somehow
<emeb|mac>
a mind bender certainly
<wolfspraul>
that's why it's good to have products and be focused on sales of those products
<wolfspraul>
so I'm super happy about the Ben NanoNote
<wolfspraul>
and upcoming Milkymist One, Xue, etc.
<emeb|mac>
actually kind of flips Turley's arguement around
<wolfspraul>
those are products, I can worry about certification, online shop, credit card gateways, customer support/returns, mechanical design, etc. etc.
<emeb|mac>
start with product, then go up the chain
<wolfspraul>
then from there come the priorities on how we free ICs and in which order/in which way
<emeb|mac>
yep
<roh>
wolfspraul about your "'why' to go into ASIC at all?" - if i understood correctly, fpga still need multiple the 'power' as the pure asic one synthesizes in it, right? so 'saving power' (which is incredibly important in mobile stuff) is another reason why 'staying fpga' doesnt make sense. and price of course.
<wolfspraul>
yes true
<wolfspraul>
but Milkymist One is plugged into the wall, and even the power supply is quite inefficient
<wolfspraul>
Xue is already (hopefully) capable of some mobile use though
<wolfspraul>
but yes, you are right
<wolfspraul>
only keep in mind costs, fpgas are at 45nm now
<wolfspraul>
those are multi-million USD and very exclusive manufacturing processes
<roh>
did availability get better?
<wolfspraul>
so if I have to compete with that in a 500nm process, my power consumption may actually be higher than the same design running in a 45nm fpga :-)
<wolfspraul>
yes, I think spartan-6 is getting better. I have the ones I need in stock anyway.
<roh>
wolfspraul i understand. so its a quite complex tradeoff with >3 variables. yikes
<wolfspraul>
yes, and Xilinx already works on the 28nm spartan-7 and throws millions at making that work...
<roh>
just hopes that the 'lets do an asic' 'lets use an fpga' keeps to a minimum in the industry.
<wolfspraul>
(it won't come up until x years from now, but still, they are working on it and ignoring those developments would not be very wise)
<roh>
makes reverse-engineering hard to not feasible - which would make me have less work
<wolfspraul>
roh: you prefer fpga or asic?
<wolfspraul>
I think fpgas are growing, definitely
<roh>
i've seen some custom arm soc recently.. and it made me worry
<roh>
wolfspraul i prefer if people use 'readymade and public documented shit' ;) atleast for reverse-enginerering
<roh>
fpga i only see in 'special purpose' hardware. usually not in any end-user box. mostly devices like high-end routers (networking equipment from cisco, juniper, extreme, etc.)
<roh>
sometimes a cpld or so finds its way into a ce-device. but that happens seldomly. i guess only if 'the guy who designed it knew them already and had a weird problem to solve'
<roh>
i guess they are just too expensive and the soc 'too good' to be a good cost/gain relationship for consumer electronics
<wolfspraul>
yeah, but look at it the other way :-)
<wolfspraul>
the fpga companies are doing so good they can afford to keep prices high
<roh>
for development you are totally right. fpgas are the way to do your asic. just not many people 'ourside the industry' doing that
<wolfspraul>
a company love to keep prices high :-)
<roh>
s/our/out/
<wolfspraul>
I think if they wanted to, or if in fact their bottom line would increase, they could drive prices down aggressively.
<roh>
also power consumption?
<wolfspraul>
but there is no need for them to do that right now, they first need to get into the right products that volume can take off and the bottom line will actually grow from lower prices.
<wolfspraul>
I don't know enough details and cannot compare.
<wolfspraul>
but you don't lower price unless you are sure you will make it back in high volumes.
<roh>
i mean.. its really hard to beat the pmu paired with recent soc on what they do. and an fpga is still not a mixed signal wonderchild
<wolfspraul>
from what I can see, they are driving in that direction, but carefully
<wolfspraul>
first I talk about price
<wolfspraul>
once the price is right, the rest often sorts itself out...
<wolfspraul>
I don't know, I'm not an industry observer. I just focused on my couple products...
<roh>
heh. i look more to 'availability' and 'tools'. atleast that are my criteria for selecting or dismissing chips mostly.
<wolfspraul>
just imagine a spartan-6 would cost 5 USD. what would happen? I don't know.
<wolfspraul>
but if you really think it through you realize that probably something big could happen...
<wolfspraul>
but then a large company is no casino (or rather shouldn't be). so they will not just do crazy tests like that, but steadily continue to build and grow their businesses.
<roh>
bad tools can make your life hell, and even kill the product. so they are a must, not a should or may. and we need 'the same stuff as usual' anyways... also a fpga needs >1 vcc, some clocks etc. all the analog stuff.. the complexity is not the digtal stuff in my experience. its the stuff which looks so innocent and simple in the schems.
<roh>
wolfspraul even if spartan6 is at 5Euros. i got no free toolchain. so its less opensource than 'some cheap arm soc' which i got all datasheets for
<roh>
atleast from my pov. (as long as no 'firmware' besides what runs on the arm is involved)
<roh>
i can live with only half-documented chips, as long as there is no reconfigurable vodoo happening inside, but plain gates. (which can be reverse-engineered also if needed)
<roh>
there are service-companies to open the package, take the die, and grind it down layer by layer and make pictures, reverse the gates etc.
<roh>
more a question if its neccessary. a latch is a latch and as long as it does as it should i dont care how exactly it looks like.
<roh>
i donwn know if i am 'less opensource oriented' because of this 'purely pragmatic oriented view' on hardware. but one thing i have learnt at openmoko: dont underestimate the destructive force of 'firmware' (not meaning the stuff you compile for your host-cpu)
<roh>
destructive as in 'onto your development process'
<roh>
.oO(ar6k... gllin...)
<wolfspraul>
roh: I will never underestimate the destructive force of firmware :-)
<wolfspraul>
we worked for the same place...
<roh>
dont get me wrong: i'd love to see a fully opensource soc. i just dont see the big 'gain' for me as the user or me the developer or me the hacker
<roh>
i rather feat that the way there is so long, that it will make one 'less competetive' in performance to other soc
<roh>
s/feat/fear
<wolfspraul>
roh: you think too static. I am not playing catchup anywhere. We innovate on features (freedoms) that others neglect. The longer they do that the better, we will be years ahead once those features become more relevant to someone, which is largely a marketing challenge.
<roh>
maybe i am too paranoid there.
<wolfspraul>
it's not a catchup game, at all
<roh>
performance-wise it is.
<roh>
i really like open stuff. but it needs to be atleast in the same league to make sense to use. nice, but useless toys i have too many already.
<roh>
the moko for example never became my phone, even when it worked finally. just not enough runtime.
<roh>
i am fully with you on freedom. i just think its more important on the tool, firmware and sw side, as well as documentation, than 'if i know my gates exactly'
<roh>
if its an asic the freedom boils down to 'documentation', may be vhdl or verilog source. but it doesnt make me more powerful than before, as a user or developer
<wolfspraul>
sure, we are on the same page
<sdschulze>
Stupid question: how suitable is MilkyMist actually for general-purpose computing?  I.e. for code that does not make use of any of the parallel floating-point extensions (or not the right ones).
<sdschulze>
Just reading Wolfgang's ML posting.
<sdschulze>
What do the other 75% of MilkyMist consist of that are not related to VJ extensions?
<wolfspraul>
sdschulze: maybe ask in #milkymist (also on freenode)? since Milkymist is built around a Mico32 core, I would think it is suited for 'general purpose' computing although I don't fully understand what you are getting at
<wolfspraul>
ah no, you misunderstood that (or my text wasn't good)
<GNUtoo|laptop>
sdschulze, good question: does the milkymist have a screen output? like vga? or better?
<wolfspraul>
if you look at all of the Milkymist sources, the Mico32 part is about 25%
<wolfspraul>
the rest is not 'vj stuff' but all sorts of peripherals, memory controller, usb, ethernet, etc.
<wolfspraul>
the 25% is only important to get the terminology right in terms of whether it is a Mico32 architecture, or Milkymist architecture
<wolfspraul>
but since 75% is built on top of Mico32, I think one can call the whole thing a 'Milkymist architecture' without being disrespectful to Mico32, which of course plays a very important role
<wolfspraul>
GNUtoo|laptop: yes, vga (forgot how high the resolution can go)
<wolfspraul>
thanks for reading my post btw! :-) I almost wrote it to myself as a sort of starting point/todo item in the mailing list archives, but now I get lots of reactions...
<wolfspraul>
cool!
<wolfspraul>
also I'm a bit worried we are running out of steam on this project, I need to think ahead a bit and find more resources/support.
<wolfspraul>
it's fun to take on a project that would (and should) normally be financed with 100 million USD with a few 10K, but if that's just a prerequisite to failure then maybe it's not so much fun after all
<wolfspraul>
there is all these cool things people want to do now, Xue, Milkymist NanoNote, and in the meantime we have very basic things missing everywhere, for example hunting down a strange memory stability problem right now. Those things make me wake up at night...
<GNUtoo|laptop>
ok
<GNUtoo|laptop>
nice!!!
<GNUtoo|laptop>
but it's uclinux right?
<wolfspraul>
Milkymist is an IC design, Mico32 (lm32) is the instruction set architecture at the core of it
<wolfspraul>
so that's OS or kernel agnostic
<wolfspraul>
there is no MMU in the IC design right now, adding one is possible but a lot of work and postponed until later
<wolfspraul>
as of today, I am aware of 2 kernels that are running on the Milkymist One boards, one is RTEMS, and the other one Linux
<wolfspraul>
I think that's a normal Linux 2.6, but without mmu. There are several patches/efforts around Linux, afaik the most promising one for Milkymist/Milkymist One is http://github.com/tmatsuya/linux-2.6
<wolfspraul>
for toolchain, I think lm32 support was just added in gcc 4.5? I may not get all details 100% right
<GNUtoo|laptop>
ah ok so it's still not done yet
<GNUtoo|laptop>
anyway I'll get a bug 2.0,not as free(no free soc) but still good, it has got a screen output
<wolfspraul>
was is not done yet?
<wolfspraul>
I think Linux boots on Milkymist One today, although from 'it boots' to 'it's really good' can be a long long way :-)
<wolfspraul>
I encourage you to add the #milkymist channel on freenode to your channels
<GNUtoo|laptop>
ok
<GNUtoo|laptop>
it boots means serial console?
<GNUtoo|laptop>
ok
<wolfspraul>
there are not many people there yet, but the ones are there are very responsive and knowledgeable, like lekernel the founder of Milkymist
<wolfspraul>
I think Linux boots, ethernet works, vga works, etc. but for details as in #milkymist
<GNUtoo|laptop>
ah can't join...too much channels
<GNUtoo|laptop>
ah no it finally joined
<wolfspraul>
the first target is RTEMS, I think mostly because it's better suited for the VJ application anyway, and because Linux may be harder to get to work, and work well, than RTEMS
<wolfspraul>
but that doesn't mean we don't want Linux, we definitely do, and in fact some work has already started.
<GNUtoo|laptop>
ok
<wolfspraul>
sometimes I feel the most important is to be able to focus and rally around narrower, more focused goals first. and then go for the big wide everything.
<roh>
no mmu? irgh
<roh>
well.. will eat gate space also...
<wolfspraul>
mmu can be added, and like I said, I love the focus Sebastien has :-) he's Mr. Focus! the (lack of) mmu is not critical right now
<GNUtoo|laptop>
ok
<lekernel>
roh, if you had to invent and build your FIB machine yourself, perhaps you'd find IC reverse engineering a lot harder
<lekernel>
my point is, contrary to IC reverse engineering, there are no (or very few) tools for FPGA reverse engineering so you can't really compare the difficulty
<lekernel>
btw talking about IC competitiveness: look at the parallax propeller
<lekernel>
old process, slow performance, high price, but still a success ...
<larsc>
it's all about marketing
<roh>
lekernel propeller isnt really a success. avr is a success. pic were one.
<roh>
propeller is major fail.
<roh>
do they have a compiler which runs on >1 arch now?
<lekernel>
well, it's not that bad
<lekernel>
even if it doesn't compare to AVR/PIC
<roh>
or is it still that crap written by a few guys in asm?
<lekernel>
oh, it's crap :)
<lekernel>
personally I don't like the propeller at all
<roh>
i like the idea of propeller. the implementation of the tools makes sure i dont touch it.
<wpwrak>
oh dear. another battery disaster.
<lekernel>
but still it seems it makes very decent sales
<roh>
lekernel btw: success is something i do not measure in commercial winnings.
<roh>
wpwrak?
<roh>
wpwrak your lab on fire?
<wpwrak>
no .. adam's mail on the list
<wpwrak>
lekernel: (propeller) i think they tried too do "do their own thing", with own built-in IDE, I think even programming language, etc. at least that was the situation when i looked at it some years ago.
<lekernel>
yeah, that's what they did
<wpwrak>
s/too/too much/
<roh>
wpwrak last i checked their compiler was hand-forged asm, which made it completely nonportable. not on unix, not on anything !=i386
<lekernel>
I think they have a C compiler now, but it produces poor code
<wpwrak>
roh: yeah, this sort of things
<lekernel>
still that propeller chip, as bad as it is, finds many users among hobbyists
<roh>
lekernel there are also people using the arduino java ide, even if its bad and makes one bang your head even if its not gcc or your code ;)
<lekernel>
and all the yuppies who see "eight cores" and go "wow, this is the future of computing!"
<wpwrak>
lekernel: it's s cute chip. if i had infinite time, i might write a decent compiler for it. i already threatened to do that for m8c, but then i got sucked into the openmoko black hole :)
<roh>
for the time and money wasted on propeller, one could buy 8 avrs and be done with development in half the time *ducks*
<lekernel>
roh, i'm already convinced of that :p
<wpwrak>
roh: the "do it all in software" approach is nice. not efficient, but attractive from an openness point of view.
<wpwrak>
lekernel: that is, until you make your fpga synthesizer ;-)
<lekernel>
I'm already struggling with milkymist development problems, so that's not before long
<wpwrak>
lekernel: well, MM has a december deadline and i don't see you as someone who'd want to show up empty-handed at CCC, so i guess it'll work one way or another :)
<roh>
wpwrak i think its not good from a darwinistic pov to help companies survive which are too stupid ;)
<roh>
makes bad managed companies to survive too long.
<lekernel>
wpwrak, I hope I won't indeed... and that sdram problem i've been fighthing for a week now quite undermines that
<lekernel>
fuck!!!!
<wpwrak>
roh: oh, give the small but stupied ones a break :)
<roh>
wpwrak means: dont write compilers for stuff as long as they dont give _everybody_ the full datasheet AND pay you money for it.
<roh>
nice boards (SIE) .. even if i note need to note: i completely lost track of your codenames on qi-hw
<roh>
make a table!
<wpwrak>
lekernel: ah, that's the instability wolfgang has mentioned
<roh>
really misses the 'this is the product, and it got version numbers'
<wpwrak>
roh: the many renames were indeed confusing
<lekernel>
yeah
<lekernel>
we have a very subtle crappiness in what I suspect to be the memory subsyste
<roh>
wpwrak yep. especially since its only 'marketing bs' *ducks* .. waste of everybodys time (usually)
<lekernel>
like a bug that manifests itself in like one case in a billion, but with a 83MHz clock and one access every few cycles you do the math how long the system survives
<wpwrak>
roh: sometimes, names change because you really didn't get it right in the beginning. particularly when using descriptive names
<wpwrak>
lekernel: sucks :-( is this something new or just something you wouldn't have seen before (due to environment/kind of testing/whatever)
<wpwrak>
?
<roh>
wpwrak so what? better stick with it (as long its not a legal problem) and seperate marketing and development. nobody in development cares under which label marketing sells the end-result. just dont make development crazy with renames ;)
<lekernel>
wpwrak, exactly, when I run simple software there is no problem
<lekernel>
it's only when using complex software, like a linux system or rtems+gui that it manifests itself
<lekernel>
nice, isn't it?
<wpwrak>
roh: but then you end up with misleading descriptive names. that's also bad. also, if a change is inevitable, make it early. remember "make" :-)
<roh>
wpwrak means: you could even give every 'product' a codename, and a number. which have nothing to do with the sales-name
<roh>
or even number the products
<wpwrak>
lekernel: seems that murphy likes you :)
<roh>
make it 'board42_v23'
<roh>
SIE would be like 'board5_v4 or so?
<wpwrak>
roh: that's even more confusing :-)
<roh>
wpwrak renames are confusing. anything with a concept you dont break makes more sense
<wpwrak>
roh: why not use the first digits of the project's initial commit ? ;-)
<roh>
wpwrak also fine with me. any string which stays the same with some revision number which is monotonic increasing is fine *g*
<wpwrak>
roh: i disagree. ben-wpan is easier to remember than 0cfb
<roh>
also dual-useage makes trouble
<roh>
you dont know how often i got asked why qi-hw is named like the bootloader
<wpwrak>
roh: the bootloader it doens't use ? ;-)
<roh>
namespaces need to be uncluttered. if a name is taken by anything near, dont use the string.
<wpwrak>
roh: there goes the hash :)
<wpwrak>
lekernel: how does clock speed affect it ?
<roh>
.oO(if i found a company which does hw, i'll name the devices i build by marihuana flavours... makes sure the marketing dept. never uses them :)
<roh>
s/found/fund/g
<lekernel>
haven't tried yet... changing the clock speed isn't super easy
<lekernel>
but I'll do at some point
<wpwrak>
lekernel: oh ? how's that ?
<roh>
hm? cant you just feed it clock from a function generator instead of the crystal?
<wpwrak>
roh: better idea: use the slang words for "penis" in exotic countries. marketing won't notice before it's too late ;-)
<lekernel>
if I go above 13ns I have to disable the DDR DLL, then I have to recompute divisors for UART, etc. reconfigure the DCMs, etc.
<lekernel>
roh, no
<roh>
funky question: is the cpu synthetisized inside a fpga capable of fully static operation?
<lekernel>
yes
<lekernel>
of course
<roh>
nice.
<lekernel>
you seem to have very little knowledge about FPGAs, no wonder you think reverse engineering them is impossible
<roh>
of course? afaik no 'recent' grown up cpu can do that
<lekernel>
the problem with lowering the clock frequency isn't about the logic being a non-static design
<roh>
only small stuff like avr and such
<lekernel>
but it's because there are a lot of PLLs etc. in my soc design
<wpwrak>
lekernel: hmm, would it be possible to lower the clock temporarily ? e.g., high to set up, low while stress-testing for hours, then high again to see the results ?
<wpwrak>
ah, plls. i see
<roh>
lekernel i dont say its impossible, i say its unfeasible usually, atleast without major expense
<roh>
and fpga knowledge
<lekernel>
for logic FPGAs only support very basic stuff with (almost) only D flip flops and LUTs
<lekernel>
no complex latches or dynamic logic
<roh>
i see. so nothing which could make trouble like in a superskalar cpu
<lekernel>
this has nothing to do with superscalar, you can perfectly make a static synchronous superscalar cpu
<lekernel>
it's usually because of pipelining tricks
<wpwrak>
lekernel: perhaps output dividers on some plls then. not sure if such a coarse instrument would help much, though.
<lekernel>
will I just have to bite the bullet and reconfigure all those PLLs...
<roh>
hm. cant you just 'halve' the clock?
<wpwrak>
ah well, success doesn't always come easy ...
<roh>
meaning, keeping all plls and 'use the then fitting baudrate on the uart manually?
<roh>
could be less work than lots of calculations
<roh>
need to run..  have fun. good hacking
<larsc>
lekernel: i'm finding this whole acm website and their subscription models very confusing. apperently i got an account as part of gsoc, but with which i can't do anything accept getting regular newsletter spam.
<lekernel>
it's not confusing, it's exploitation... www.ieeesucks.com (the same applies to ACM)
<lekernel>
try to google the paper title to find an open access source
<larsc>
in the welcome email there was something written about full access, when i click the link i get to a page where it says to gain full access i have to buy a professional membership :/
<larsc>
hm, looks as if i can access it with my university library account
<lekernel>
usually you can
<lekernel>
they also do IP address based authentication, so using proxies in universities helps too
<lekernel>
same goes for getting papers out of I€€€, Elsevier and other similar greedy publishers
<lekernel>
basically their publishing policy can be summed up as "always money in, never money out"
<lekernel>
ie. authors pay for publishing, readers pay for downloading
<lekernel>
what really amazes me is professors getting pedantic with the "IEEE code of ethics"
<sdschulze>
wolfspraul: I wouldn't believe economists too much.
<wolfspraul>
how where what?
<sdschulze>
regarding the article in your post
<sdschulze>
We can save the $50 Millions for marketing.
<wolfspraul>
ah
<sdschulze>
and regarding development...
<wolfspraul>
I like the article, well it's my thinking too maybe, so I like it. People forget how much time it takes to get to market.
<sdschulze>
Well, the marketing that caused me to by a Ben was paid by O'Reilly...
<sdschulze>
*buy
<sdschulze>
and tuxbrain's travel expenses to FOSDEM :)
<sdschulze>
In a company that relies on development by its employees, you can reach a point where the market value of your product is smaller than your debts.
<sdschulze>
Plus, I don't see any competition in the target audience.
<sdschulze>
for us
<sdschulze>
notices the mixup.
<sdschulze>
Development can go on -- slowly, though -- without money.
<wolfspraul>
ah yes, sure
<wolfspraul>
but we are still in the real world, it's very very hard
<wolfspraul>
so the products we are actually making do need to perform some function today
<wolfspraul>
at least I firmly believe that
<sdschulze>
You only need quite some money and quite some volume if you want to manufacture ASICs.
<wolfspraul>
that's why even though people laugh about the NanoNote, I take it very serious and sell one by one to people for 99 USD
<wolfspraul>
yes but that looks at the money as if it's a big blob that will fall from the sky one day
<wolfspraul>
but it won't
<wolfspraul>
so I do the NanoNote thing, and so far I love it
<wolfspraul>
of course the strategy is a bit hard to explain, and we cannot be off-chart technically for too long
<wolfspraul>
but my pain level did not get worse for 1 year, that's a good sign :-)
<sdschulze>
You want to do FPGA first, right?
<wolfspraul>
it's not an option
<wolfspraul>
I am doing Milkymist One RC2 next
<wolfspraul>
and then Xue
<wolfspraul>
from the distance it may not be obvious how risky those projects are, and how easily time and money will disappear into them
<wolfspraul>
I am 100% focused on Milkymist One RC2 now, on the manufacturing side
<wolfspraul>
and on the Ben side, on OpenWrt and other software images, ben-wpan, gps, microsd breakout, case hacking, etc.
<wolfspraul>
that's enough :-)
<wolfspraul>
ah, forgot the server - need to get the kicad schematics diff visualization live
<sdschulze>
Isn't the MilkyMist One FPGA-based?
<wolfspraul>
yes
<wolfspraul>
Spartan-6
<wpwrak>
wolfspraul: (money falling from the sky) working investors is a skill that's still missing in the qi-hw circle
<wolfspraul>
don't say that. but the (serious) investors I spoke to all gave me their good advice as in 'earn your way'
<wpwrak>
gee, what happened to the good old times with bubble baths ?
<wpwrak>
hehe, that old gmenu2x is indeed quite evil :) trying clock output on the other ben which still had that thing installed. getting 7.02 MHz instead of 16.0
<wolfspraul>
yeah I know
<wpwrak>
those little batteries seem to be a constant source of pain.already in openmoko, we never got them right, despite years of trying
<wpwrak>
probably best to just use a CR2032 battery holder
<wpwrak>
at least where size isn't a problem
<wolfspraul>
oh you mean the exploding batteries in the SIE run?
<wpwrak>
Ornotermes: i updated clk.c again. there was still a bug: i wrote to the MMC controller's registers before the clock was enabled. that write was just ignored
<wpwrak>
Ornotermes: as a workaround for the old version, just run the it twice
<wpwrak>
wolfspraul: yup
<Ornotermes>
ah, that explain some things :P
<wolfspraul>
wpwrak: btw, for the /dev/breakout codes lars posted, what was the point of that? do we have a /dev/breakout device already? is this what we should do/will do/might do/will not do? I didn't get it...
<wpwrak>
i think he wants to write a driver and this was the proposed API
<wpwrak>
guess he doesn't like me scribbling over registers from user space ;-)
<wolfspraul>
ah ok
<Ornotermes>
bould by nice any way, use it from shell scripts and such
<Ornotermes>
could*
<wpwrak>
there's a of course a latency penalty in going through the kernel. but for many applications this doesn't matter so much
<wpwrak>
Ornotermes: yup. and maybe even coordinate with the MMC driver
<Ornotermes>
but i would kind of prefer to have it in /sys/bus/gpio/... or something like that
<wpwrak>
now .. why does my 16 MHz clock become DC ? need to simulate the damn filter
<kristianpaul>
wpwrak: whats the name for the acid to etch PCB that is not brown-colored?
<kristianpaul>
you said two if i remenber well
<wpwrak>
kristianpaul: there are three: ammonium something, sodium something, and HCl with peroxide
<wpwrak>
kristianpaul: the latter you buy at hardware stores (ferreterias) and pharmacies
<kristianpaul>
sure i'm going to the ferreteria now :)
<wpwrak>
kristianpaul: (you mix the ingredients yourself - one part HCl into two parts peroxide)
<kristianpaul>
so i said HCL?
<wpwrak>
kristianpaul: peroxide is often called "agua oxigenada"
<wpwrak>
kristianpaul: "acido muriatico"
<kristianpaul>
ahh i have in some in the bathroom !
<kristianpaul>
grat
<wpwrak>
doesn't get any easier :)
<kristianpaul>
good you speak spanish :)
<lekernel>
be careful, the HCl + hydrogen peroxyde mixture generates chlorine gas
<wpwrak>
yup, keep the window open
<kristianpaul>
wikipedia es said cloruro de hidrogeno
<kristianpaul>
okay
<wpwrak>
kristianpaul: you can try if they understand this at the hardware store :)
<kristianpaul>
loll
<kristianpaul>
no way ;)
<kristianpaul>
i wonder why i called muriatico anyway..
<wpwrak>
also took me a while until i found out that "oxygenated water" is peroxide
<wpwrak>
the HP paper, i spray it with alcohol, then gently wipe off the alcohol and the upper layer of coating. the i let the thing dry for an hour or so
<wpwrak>
you may try some shops with computer supplies. that's how i found mine
<wpwrak>
you can also use other papers but that's the one i found works best
<kristianpaul>
okay
<kristianpaul>
ahh thats photograpic paper, i have how to ask now
<wpwrak>
hmm, i wonder if hp still make it
<wpwrak>
yes, for ink printers
<kristianpaul>
wpwrak: in the idbg board how do you solder the QFN chip?
<wpwrak>
(qfn) apply flux generously, place the chip, dab a bit of solder at all the pad/trace corners
<wpwrak>
(on all four sides)
<wpwrak>
then apply flux again, do another pass so distribute the solder better
<wpwrak>
check visually if all pads look as if they're connected. if not repeat flux and solder until they do
<wpwrak>
to remove bridges, clear the iron's tip and pass over the bridge. that will remove a bit of solder and redistribut ethe rest
<wpwrak>
s/clear/clean/
<wpwrak>
if you have a large quantity of excess solder, remove it with a solder wick
<wpwrak>
make sure you have a good quality solder wick that doesn't decompose easily. there's a nice one under the "goot" brand
<wpwrak>
cp-2015. very fine braid. but a slightly more coarse will do, too
<wpwrak>
for the solder, the thinner the wire the better (for dosage - small SMT stuff only needs the tiniest quantities of solder). i use 0.7 mm, which is just about borderline.
<wpwrak>
for tinning the PCB, apply flux to the whole board, then put a small drop of solder on the board and "smear" it with the soldering iron
<wpwrak>
may have to raise the iron's temperature for this
<wpwrak>
for flux, i recomemnd water-soluble. it's easy to clean off the board and doesn't stick very much
<wpwrak>
the more common rosin type of flux is extremely sticky and hard to remove
<wpwrak>
(sticky = your tweezers get sticky, too, so you have to clean them all the time)
<wpwrak>
there is also "no clean" flux but i don't like it so much. first of all, you may still need to clean, and second, it sticks even less than the water soluble, so it's hard to put the components in place
<kristianpaul>
hmm i need flux..
<kristianpaul>
well thats for next week
<kristianpaul>
or for a sparkfun order..
<wpwrak>
important: flux must be cleaned off the board. it's a weak acid so it can damage traces over time, and it is also a weak conductor, so it can mess up your circuit
<wpwrak>
particularly the water soluble flux is bad in the later regard
<wpwrak>
in a pinch, any cheap flux will probably do. but life gets easier with a good flux :)
<kristianpaul>
are you aware of a cheal-good PSU with current limit feature?
<kristianpaul>
or what i can use from TI to do current-limit ?
<wpwrak>
PSU ? you mean a regulator or a lab power supply ?
<kristianpaul>
regulator
<kristianpaul>
i'll lab but i dont have too much space at home either money..
<wpwrak>
(reg) uh, dunno. i hardly ever use regulators
<kristianpaul>
what do you use?
<wpwrak>
an alaog lab power supply isn't too expensive. maybe USD 100 or so
<kristianpaul>
look i'm worried about avoid short cicuit
<kristianpaul>
over overload
<kristianpaul>
i jsut need control the current flow to some limits
<kristianpaul>
thats it
<wpwrak>
that's what a lab supply is for :)
<wpwrak>
also lets you choose the voltage
<kristianpaul>
..
<wpwrak>
and one circuit's overload is another circuit's normal load. you really want a real lab supply
<kristianpaul>
i have my own analog power supply but dont limit current
<wpwrak>
you had the acid delivered to your home ?
<wpwrak>
or did you send out your minions ? :)
<kristianpaul>
delivered
<wpwrak>
wow :)
<kristianpaul>
also other stuff, ahh damm they missed the "agua oxijenada"
<wpwrak>
well, you said you had some in the bathroom
<kristianpaul>
oh yes !
<kristianpaul>
hmm i need be carefull witht he measure i know there is soemthing for that
<kristianpaul>
should be be really accurate?
<kristianpaul>
its saturday i have until 6pm to buy all
<kristianpaul>
i'll use some "transfer paper" someday and never used just to see how it goes
<wpwrak>
(measure) naw, i think it's pretty tolerant
<kristianpaul>
wpwrak: well some stuff was deliver from my madre when she coming from office to home :)
<kristianpaul>
Is okay to said Qi-hardware is a comunity?
<kristianpaul>
or sort off of that?
<wpwrak>
doesn't sound overly incorrect
<wpwrak>
that cheap power supply in ebay doesn't seem to have knobs for current limiting
<kristianpaul>
ah :(
<roh>
kristianpaul ask me tomorrow. i got a very nice schematic somewhere for a short-circuit proof lab psu based on mc34063
<roh>
700mA max, but you could add some better switching transistor easily i guess
<roh>
kristianpaul btw: i got the big brother of the model you pasted last. the 2x 0-30V, 0-3A + 5V 3A fixed. analog knobs, lcd displays for 2x voltage and 2x current with green backlight. simple linear design lab psu. ~160Euro
<roh>
btw: they are sold basically unmodified since 30 years.. based on 2N3055 transistors. proven design (tm). only the displays changed from 'meters' to 'dvm' at some point
<kristianpaul>
good :)
<kristianpaul>
thansk roh
<roh>
oh.. sorry.. didnt see you are in .co
<kristianpaul>
i'm
<kristianpaul>
yeah :(
<roh>
for sure better weather than berlin *sigh*
<roh>
;)
<kristianpaul>
today is raining
<kristianpaul>
sunny seems to be later
<kristianpaul>
btw where you think i was located roh ?
<roh>
i can check the schematics if i more awake later.. was out shopping childs toys with somebody.....
<wpwrak>
i hate it when simulation and measurement wildly disagree
<wpwrak>
weird. i get that 16 MHz clock, sent if through a cap for DC blocking and then a resistive divider. now, even the input (!) drops to nothingness already around 10 kHz.
<wpwrak>
unless my scope probe is somewhere in the nanofarad range, this doesn't make sense ;-(
<wpwrak>
ah, solved. two traces were connected that shouldn't be. caused rather interesting effects.
<kristianpaul>
I can swich to the current stable branch of openwrt-xburts
<kristianpaul>
i cant manager the broken SDL right now
<kristianpaul>
lets see..
<kristianpaul>
git..
<kristianpaul>
git checkout master
<kristianpaul>
?
<kristianpaul>
How do i quick from GMU in the new nanonote firmaware??
<rafa>
kristianpaul: alt+enter ?
<rafa>
ah.. no quit
<rafa>
quick what
<wpwrak>
i think he meant quit
<wpwrak>
rafa: how's the jlime meeting going ?
<rafa>
wpwrak: then for quit alt+enter
<rafa>
jlime.. so far pretty good
<rafa>
we had a lot of fun and we were discussing a lot of stuff
<rafa>
to do..  now we need to know how many years it will take to do all we were discussing :D
<wpwrak>
oh dear ;-))
<wpwrak>
did you succeed with the idbgs ?
<rafa>
wpwrak: idgb: noh :( we could not find all the tools. the main problem was that, filip, our guy from poland who coul d bring all the stuff neeeded
<rafa>
had a wedding the  first day of the meeting so he arrived the sencond day
<rafa>
also it was hard to contact him the previous days because he was very busy (he does not live in warsaw) anmd
<rafa>
3rd he came by train no soo useful to brin g all the stuff. So,
<rafa>
i showed them how to install it :) .. but i need to show them omore pictures with the dremel work
<rafa>
taht is the onnly part thta i was not able to explain very well
<wpwrak>
ah well, they'll figure it out one way or another :)
<rafa>
they wil manage that anyway.. at least keristoffer would kill to have that installed o
<rafa>
:)
<wpwrak>
at least they could get a good look at yours :)
<rafa>
yes, thety had
<rafa>
i need to ask wolfgang if he has mnore pictures with the dremel work. i remember that he took several
<kristianpaul>
fo we swich to english jsut to keep the chat more open?
<kristianpaul>
s/fo/do
<kristianpaul>
telnet 192.168.254.101
<kristianpaul>
after you set up the usb0 interface in your computer side
<kristianpaul>
remenber plug usb cable for this !
<wpwrak>
wolfspraul: which reminds me .. is adding qi-hw to the linux USB ID list on your to do list ? :)
<wolfspraul>
don't know
<wolfspraul>
:-)
<wolfspraul>
I don't even know how to add it.
<wolfspraul>
just wrote an endless mail about Lattice 'open source license' and the GPL. argh... hate these things.
<wolfspraul>
we need an organization like the FSF in hardware land
<wolfspraul>
not that I will do it, but someone should...
<wpwrak>
time to grow a beard and become the rms of hardware ;-)
<wolfspraul>
never
<wolfspraul>
reminds me I should go running a bit :-)
<kristianpaul>
lol
<wpwrak>
(license) heh :) btw, the main reason for finding distribution there may simply be that copyright law is all about distribution :)
<rafa>
morning
<kristianpaul>
rafa: morning :)
<rafa>
wpwrak: i can explain wolfgang how to start the beard
<wpwrak>
rafa: that was a quick night :)
<wpwrak>
;-))
<rafa>
yes.. we decided to talk for a while.. and now it is too late.. because the sweeden guys need to start their back trip at 6.30am
<wpwrak>
i thought today was still another meeting day ?
<rafa>
yes.. but some guys found hard to travel tomorrow.. so they start today tooo early
<wpwrak>
ah, pity
<wolfspraul>
wpwrak: sure, I think it's obvious that the Lattice license allows simulation, no?
<wpwrak>
wolfspraul: i didn't read it. let's see what response you get :)
<wolfspraul>
if you dig deep enough, it is probably not GPL compatible (leaving out the obvious export control part), but that's mostly also because the whole terminology is different, one is written from an IC perspective, the other one written from a software perspective
<wolfspraul>
I hope none.
<wolfspraul>
I talked to all relevant people. The FSF has made it clear they are not going down that road. They focus on software.
<wpwrak>
wolfspraul: i think you're off with the proprietary verilog libs
<wolfspraul>
they know people stick the GPL on all sorts of things, and they think that's funny and honors them