<wolfspraul>
let me rename the page to Sharism_inventory
<tuxbrain>
yes I remember somthing like that, there can I take the stimated price for valid?
<wolfspraul>
I don't know
<wolfspraul>
sourcing is very messy
<wolfspraul>
normally I would not want to start selling out of my inventory, I'm not trying to become a components dealer.
<wolfspraul>
but in your case, if there are some parts that are hard to get, or have a high MOQ, of course I help you and just 'move them' to you at whatever cost I paid + shipping.
<wolfspraul>
but if you have a run, at the end you will have some excess parts anyway
<wolfspraul>
maybe you start Tuxbrain_inventory :-)
<wolfspraul>
and btw, Carlos is already making a number of changes, towards V3 I think
<wolfspraul>
so you might want to at least think about whether you want to make more V2, or the newer V3/in-progress-V3 right away
<wolfspraul>
I am actually thinking about the components/ordering process
<wolfspraul>
(that's unrelated to your proposed run)
<wolfspraul>
when wpwrak is back from his barbecue sleep, I'll see what he thinks
<wolfspraul>
we should work on that process a bit, starting from the components in kicad, then generate some kind of list, then automatically query distributors/stock levels/moq/lead time from octopart.com or so, then automatically generate shopping lists for mouser/digi-key/arrow/etc.
<wolfspraul>
Yanjun Luo (the milkymist jtag-serial guy) was complaining about components/bom handling in kicad, and I remember werner working on some scripts in that area as well
<wolfspraul>
nice picture of the jtag-serial daughterboard sitting on Milkymist One
<wolfspraul>
:-)
<tuxbrain>
thank for the info, I don't think I can progress on this any ealier than next week
<tuxbrain>
but now I know where to start :)
<tuxbrain>
nice pic!
<wolfspraul>
it's hard work
<wolfspraul>
hardware is called like that because it's hard :-) (stealing a quote from Harald)
<wolfspraul>
so don't underestimate
<wolfspraul>
but in the long run it can be good for you, for sure
<tuxbrain>
I'm remodelating web site removing some crap like OM, Netwalker, GP2x.... and include SIE, Milkimist as comming next
<wolfspraul>
we can work together, you make some things, I make some things
<tuxbrain>
no really I don't understimate at all
<tuxbrain>
also adding some linux service we where also done to some costumers ,
<tuxbrain>
that work has priority to anything els
<tuxbrain>
else
<wolfspraul>
sure make some money!
<tuxbrain>
in paralel we have to do a course, a presentation for Hackmeeting in two weeks, host an Arduino Meeting at end of November, introduce my self in the fedora community, learn how FEL works, work on spi SDIO interface for ben, and time to time some sleep ,
<tuxbrain>
also dayli common taks, as now, gonna prepare to ship some orders, c u, and thanks for the info.
<kyak>
wolfspraul: out of interest, what is the warranty period for Ben?
<wolfspraul>
he, I don't know the official policy from our HK store
<kyak>
so it depends on where i bought it?
<wolfspraul>
it depends, for example Tuxbrain in the EU has to offer at least whatever minimum the EU requires
<wolfspraul>
sure
<kyak>
i see
<wolfspraul>
do you have a problem with yours?
<kyak>
no-no, just asking :)
<wolfspraul>
so far there hasn't been a single warranty case that we would not have resolved
<wolfspraul>
keep in mind how small our community still is
<wolfspraul>
so there are few people that are trying to take advantage etc.
<kyak>
so a defect rate is very small, that good
<wolfspraul>
ohs ure
<wolfspraul>
out of the first 1000 we sold, we had to replace maybe 6-8, worldwide
<wolfspraul>
mostly screen issues (fpc)
<wolfspraul>
most of those were 'refurbished', for example by replacing the fpc section
<wolfspraul>
some of the refurbished ones were sold at 50% off, some were donated for specific hacking projects
<kyak>
how do you repair? is there a repairing workshop?
<wolfspraul>
I wish.
<wolfspraul>
not really
<wolfspraul>
although of course little by little we are accumulating pictures and what not in the wiki. or werner's case scans.
<wolfspraul>
but definitely we are going in that direction
<wolfspraul>
I will stick with this form factor.
<wolfspraul>
(there may be other form factors later but this one is nice for a pocket computer)
<wolfspraul>
in terms of warranty, my actual goal is to make electronics that last 20 years
<wolfspraul>
that is definitely not the case with the Ben
<kyak>
oh lol :)
<wolfspraul>
the hinge will become loose
<kyak>
are you sure that the planet will still be there in 20 years? :)
<wolfspraul>
some mechanical parts are really bad, such as the microSD connector and battery connector
<wolfspraul>
kyak: oh it's no problem
<wolfspraul>
you just asked about warranty so explain how I see it
<wolfspraul>
can i offer 20yr warranty for the ben - probably not
<wolfspraul>
totally sure
<wolfspraul>
so back to electronics, I think devices built for longevity (mostly mechanical longevity) go together with free software best
<wolfspraul>
free software needs time to mature, like good cheese or wine :-)
<wolfspraul>
of course technology advances, more mhz, more memory, higher resolution screens
<wolfspraul>
that is fine
<wolfspraul>
but when we sell a device, yes, I think it should work for 20 years
<wolfspraul>
not the Ben though, but with the Ben we are learning why that is not the case
<wolfspraul>
:-)
<kyak>
i'd like to believe you, and i generally admire your ideas.. Though i think they are mostly far from real life
<wolfspraul>
so the Ya will be better
<wolfspraul>
he
<wolfspraul>
:-)
<wolfspraul>
kyak: how long do you think a computer should last?
<kyak>
hm... i think it _could_ last for a long time, but what's the point? the hardware will become outdated in several years anyway
<tuxbrain>
kyak define outdated , wolfgang has interesting thoutghs about it, that I start to understand :)
<kyak>
"outdated" means that that you can buy twice more powerfull device in two years for the same money
<kyak>
so what's the point of keeping the old one for years?
<tuxbrain>
btw about patent and not allowed material in qi, I find that page very inspiring, and fedora has some lawyers to assess them so I think it will basically fine
<kyak>
i suppose it is not 12 years old huge brick
<tuxbrain>
I think more on hardware like a car,
<kyak>
3-5 years is a general warranty period for devices with no mechanical parts
<tuxbrain>
allways there are new carss, more bautifull , more faster, more confotable
<tuxbrain>
but meanwhile your car woks and is useful and doesn't estar to waste money in repairs you hold it until this moment arrives
<tuxbrain>
at least on computers I work the same way
<tuxbrain>
meanwhile I can do my job on them, they stay, if not I try to upgrade the bottleneck part if not then is time to change
<kyak>
you are right, but computer is a bit different.. a new computer doesn't mean better ecology, safety etc
<wolfspraul>
kyak: I think you are lumping a lot of features into 'hardware'
<wolfspraul>
so of course many companies try to sell you something that they can declare outdated asap
<wolfspraul>
that's their business model
<wolfspraul>
when you become their customer, don't complain (only about your own stupidity maybe)
<wolfspraul>
if you make something bigger, it's easier to declare it outdated faster
<wolfspraul>
I'm looking at all this from a free software perspective.
<wolfspraul>
my mail client is mutt, and I don't think for email I will ever change, in my life
<wolfspraul>
that's my feeling
<wolfspraul>
there are not many more innovations in email. you tell me what happened in the last 10 years. spam filters?
<kyak>
there is a time period for deprecation that makes sense. Of course i won't buy new computers every year, but i also won't stick with any device for 20 years :)
<wolfspraul>
oh you probably shouldn't
<wolfspraul>
ok let me ask you this way then
<wolfspraul>
the microSD connector on Ben
<wolfspraul>
let's say it costs 15 US cents
<wolfspraul>
average life expectancy 2 years
<wolfspraul>
then there is another one, costs 80 US cents
<wolfspraul>
average life exepctancy 10 years
<wolfspraul>
which one should the manufacturer you like to buy computers from use?
<wolfspraul>
then there is a third one, let's say 1.20 USD, which will last 20 years, on average
<wolfspraul>
you pick...
<kyak>
well, in this case you should declare a life time warranty, most users will pick that
<wolfspraul>
don't understand
<wolfspraul>
which connector would you want your computer manufacturer to use?
<wolfspraul>
80 cents / 2 years
<wolfspraul>
sorry
<wolfspraul>
15 cents / 2 years
<kyak>
of course the most reliable one
<wolfspraul>
80 cents / 10 years
<wolfspraul>
1.20 USD / 20 years
<wolfspraul>
ahhh :-)
<wolfspraul>
he he
<wolfspraul>
maybe we mean the same thing all along
<wolfspraul>
I am not telling you you have to use 20 year old computers for some bizarre reason.
<kyak>
ah ok, i see your point
<wolfspraul>
I love high-tech.
<wolfspraul>
so I look at this from the manufacturer's perspective
<wolfspraul>
and I have issues with the Ben
<kyak>
20 years warranty doesn't mean that you will be actually using it in 20 years
<wolfspraul>
1. microSD connector
<wolfspraul>
2. battery connector
<wolfspraul>
3. hinge
<wolfspraul>
I want a hinge that after it becomes loose, can be tightened again.
<wolfspraul>
the ben's hinge cannot, it's a throw-away design.
<wolfspraul>
you want that?
<wolfspraul>
probably not...
<wolfspraul>
that's a separate question, first as a manufacturer I try to make devices that will have very few failures over as long a timespan as reasonably possible.
<wolfspraul>
I think that goes along best with free software.
<wolfspraul>
other manufacturers have other goals, that go along better with their software :-)
<wolfspraul>
so for example on Milkymist One, we spend a lot of time to identify the 'right' connectors
<wolfspraul>
DMX from Neutrik, USB and Ethernet from Molex, etc.
<wolfspraul>
we actually even did connector comparisons, and surprisingly the more expensive ones really turned out to be the better ones.
<kyak>
but frankly speaking, don't you want that a user who already has Ben to buy Ya?
<wolfspraul>
I think the happier he is with Ben, the more likely he will buy a Ya.
<kyak>
why would he buy it, if he's satisfied with Ben and it is working for years?
<wolfspraul>
and the Ya has to have something new/exciting anyway.
<wolfspraul>
no I am not worried about that
<wolfspraul>
I don't think the Ben has to be crappy and fail to increase my chances to sell a Ya.
<kyak>
yes, maybe that's a bad comparison because Ya has some obvious advatanges
<wolfspraul>
if there is nothing he needs in Ya, he can continue with the Ben, and maybe comes back in the future when we add something he actually needs.
<wolfspraul>
like I said, I am building a manufacturer that goes along best with free software
<wolfspraul>
and I am not worried about free software not supporting old devices anymore
<wolfspraul>
many other companies don't even have that option, because supporting old devices is terribly costly for them
<wolfspraul>
not on the mechanical side, but on the software side
<kyak>
yeah, they usually just stop suppoting it
<wolfspraul>
now, we say, OF COURSE, because they came out with crazy hacked-together vendor ports that are totally unmaintainable
<wolfspraul>
well they cannot, they maneuvered themselves into a dead-end road, primarily on the software side
<kyak>
this is a way to make people buy more
<kyak>
if you can endlessly update my devices sw, it will always satisfy y needs
<kyak>
*my needs
<wolfspraul>
you mean I should use artificial software obsolescence to sell new hardware?
<wolfspraul>
well that strategy won't work too well with free software either, because whatever trick I use to make my new software not work on the old hardware, people will just take it out, or run 100% free software on the old device in the first place
<kyak>
no, cause you are a good guy :) but this is what others do, and this is how they survive
<wolfspraul>
ah no
<wolfspraul>
I don't see myself as the 'good guy'.
<wolfspraul>
I just try to explain the business model, the one of Sharism, and other manufacturers.
<wolfspraul>
you need to understand that many other manufacturers just do not possess (!) the software skills needed to execute a strategy such as the one I hope will eventually work for Sharism.
<wolfspraul>
so the fact that they have unmaintainable vendor ports is something they don't know how to avoid
<wolfspraul>
look at the mess that is already clearly visible in the Android scene now
<wolfspraul>
do we believe this is still fixable?
<wolfspraul>
maybe it's already too late
<wolfspraul>
the manufacturers are again too fast, they let software companies talk them into quickly throwing this or that device on the market, even though software will be unmaintainable later
<wolfspraul>
but to me, 'hardware' is just a bit of mechanical, silicon, metal, etc. around free software
<wolfspraul>
so we try to dig into those various things that are 'hardware', and then build them in such a way that they perfectly fit the needs, of today and tomorrow, of free software
<wolfspraul>
makes sense?
<wolfspraul>
I don't have these ideas in very polished sentences, sorry...
<wolfspraul>
hope I get it across
<kyak>
i understand what you are talking about
<kyak>
but a simple example: i own a linksys router
<wolfspraul>
so in that view, I also say 'hardware' should last 20 years.why not? are electrons wearing out the wires they are running through? I doubt it.
<wolfspraul>
the problems in longevity come from cheap mechanical, you wouldn't believe how rusty (!) many cheap Chinese connectors are even after 6 months
<wolfspraul>
and they have not been in a humidity/temperature test chamber, no no
<kyak>
the first thing i did is throw away the manufcaturer firmware and put openwrt inside.. so now i'm greatly satisfied, and the device is working fine for years.. i don't need to buy another router
<wolfspraul>
great!
<kyak>
but if they prevented me from updating the custome software, I would just go and buy another router when i need some feature not supported by this router
<kyak>
so by giving such great freedom to their users, they reduce their sales :)
<wolfspraul>
you are trying to convince me with a hypothetical story that you aren't even following yourself?
<wolfspraul>
maybe if software would be un-updatable, you would not have bought their device in the first place
<kyak>
good point
<ezdagor>
Anyone know if there is a keymap file for the Nanonote?
<wolfspraul>
ezdagor: there was lots of keymap talk on the mailing list a while back
<wolfspraul>
if nobody else comes forward in irc, definitely also try emailing discussion@lists.en.qi-hardware.com
<ezdagor>
Nod.
<wolfspraul>
best if you subscribe first, I need to moderate non-subscriber mails and sometimes it takes time, or you don't see the answer unless people remember hitting reply-all etc.
<wpwrak>
wolfspraul: (automatic component list) well, ben-wpan/atusd has that already :) (adapted from the process we used in gta02)
<wpwrak>
wolfspraul: (bad usd connector) ah, you had bad experiences as well ? (i have one where my experiments dislocated one of the mechanical parts, so it doesn't "click" anymore. still works electrically, though)
<wolfspraul>
wpwrak: not only do I have bad experiences, but as I described to kyak earlier, I do believe that high quality mechanical and free software go together well, an ideal pair
<wolfspraul>
so I spend quite some time to dig into this, understand what is a good connector, what a bad connector
<wolfspraul>
what brands are actually good, which are just playing patent games and try to lock you in
<wolfspraul>
etc.
<wolfspraul>
we probably have to define some edurance tests at some point, kinda a like a 'free software mechanical quality' standard :-)
<wolfspraul>
below that is just crap...
<wolfspraul>
wpwrak: [component lists] ok, I start looking in ben-wpan/atusd then
<wolfspraul>
there are many things to improve, but that one seems like a reasonable next target
<wolfspraul>
what do you think?
<qi-bot>
[commit] Niels: let the user select a subdirectory to mass download tiles into. Use this for tiles you want to delete after usage. Just delete the subdirectory in $HOME/Maps. http://qi-hw.com/p/nanomap/c4d718f
<wpwrak>
wolfspraul: (bad quality) yes, agreed. i was just curious whether you had run into problems specifically with the uSD connector in the ben. this would become important when we start encouraging people to stick little pcbs in the uSD slot.
<wpwrak>
(bom) it's a relatively low-hanging fruit since much of the work is already done, yes
<wpwrak>
my bom processor isn't perfect but it does get the job done with a moderate amount of pain
<kristianpaul>
morning
<wpwrak>
the tricky bits are the substitution scripts and of course the component equivalences (e.g., digi-key 123-456-nd == murata xyz789)
<wpwrak>
also, one decision the bom system, doesn't take for/force on you is whether you want to introduce a qi-hw-specific layer of part numbers, and use these to pick parts.
<wolfspraul>
just sent another Sisvel mail to Chris
<wolfspraul>
he will shoot back I would think :-)
<wolfspraul>
he keeps saying that 'all devices' infringe, which is very unfortunate because he adds more FUD to the discussion
<wolfspraul>
oh well :-)
<wolfspraul>
he got burnt anyway, so he has the right to be angry...
<wolfspraul>
wpwrak: I don't want to introduce qi-hw specific anything, if possible
<wolfspraul>
I'll just look at what you have there first.
<wolfspraul>
is the bom coming out of the kicad files?
<wpwrak>
yeah, i don't believe that interpretation either
<wpwrak>
(bom) just a sec ...
<wpwrak>
here's the big picture: the stuff lives in ben-wpan/bom/
<wolfspraul>
Pulster could do a great service, he could publish the entire documentation he has about his lawsuit.
<wolfspraul>
but he will not, claiming all sorts of threads, confidentiality agreements, etc. etc.
<wpwrak>
the scripts come from svn.openmoko.org/trunk/eda/boom/. there's a path to it in ben-wpan/bom/Makefile
<wolfspraul>
it's a pity, he could really help others coming full circle on this
<wolfspraul>
oh well
<wolfspraul>
wpwrak: oh I see you want to continue the good tradition of KiCad to be the application with the most extensions?
<wolfspraul>
in the ben-wpan/bom directory I see .inv .gen .equ .sub .chr .inc
<wolfspraul>
almost every file has its own extension :-)
<wolfspraul>
I just run 'make' and see what happens :-)
<wolfspraul>
boom not found, but it did quite a few things
<wolfspraul>
have you heard of octopart.com ? do you think they are any good?
<wolfspraul>
oh nice! boom/README!
<kristianpaul>
:)
<wolfspraul>
hmm, as usual this is seriously good work. I will take some time to read through it first.
<wpwrak>
(octoparts) hmm, more or less. i use them when i can't find a part at the regular places. but often, they don't find stuff that is easy to find and they produce hits that are difficult to use. (e.g., manufacturer or "call for more information" brokers)
<wolfspraul>
two questions: are there standardized 'query APIs', and are there standardized 'shopping list' formats?
<wolfspraul>
I wouldn't want a digi-key only thing, we should be able to include farnell, mouser, arrow, and others if easily possible
<wolfspraul>
also if octopart has too many sources, but a good API (?), maybe we can include some?
<wolfspraul>
sorry I mean exclude some
<wolfspraul>
if possible, it would be great if things like MOQ and lead-time could be factored in as well
<wolfspraul>
well and stock-level
<wolfspraul>
stock-level, moq, lead-time
<wolfspraul>
wpwrak: some of the boom stuff seems to be around FIC-specific issues, that will probably never again appear in this way. true?
<wolfspraul>
for the rest, you start with the .lst file that comes out of KiCad.
<wpwrak>
i don't think there are any standard APIs. but the script that talks to the API isn't all that complex.
<wolfspraul>
do you see any overlap in what you do outside/after KiCad and what KiCad should or might do inside of KiCad one day?
<wolfspraul>
just trying to understand where the lines between tools/packages could be
<wpwrak>
hmm, not even sure there's anything FIC-specific in boom itself.
<wolfspraul>
is 'boom' a separate tool in and of itself, like fped
<wolfspraul>
ah OK, I look at the workflow in xfig
<wpwrak>
the inventory (.inv) does include MOQ and stock. it doesn't have lead time, though.
<wpwrak>
(boom vs. kicad) there was a bit of discussion about this. the general understanding is that BOM/inventory processing is very site-specific and kicad shouldn't try to get too deep into it
<wpwrak>
boom is separate, yes
<wolfspraul>
sure there is always a line
<wolfspraul>
if both sides (KiCad & boom) know about each other and define the line clearly, and communicate with each other, that would be perfect
<wolfspraul>
wpwrak: so you see boom similar to fped?
<wolfspraul>
in terms of packaging/independence I mean
<wpwrak>
(boom like fped) yes. fped is a bit more mature, though. boom is still somewhat experimental. also, the pattern matching syntax may been some simplification
<wpwrak>
(line) i just track whatever kicad does :)
<wolfspraul>
yes but it sounds like they are aware of boom
<wolfspraul>
that's encouraging
<wolfspraul>
same as with schhist, I am very interested in getting this to work on the projects server, automatically and server-side run
<wolfspraul>
doesn't need to be tomorrow, I think the problem boom tries to solve is a bit more messy than schhist, for example
<wpwrak>
the discussion was mainly about how to handle things in kicad and what the general requirements are.
<wolfspraul>
but you seem to be dancing around the right problems in boom, after a quick look
<wolfspraul>
I think I will play with it a bit locally first.
<wolfspraul>
lead-time is important, but we can look at missing features later. first I will try to understand what we have already, then how I can get it to run on the server
<wolfspraul>
in this case, bom stuff, I don't believe in the 'perfect' solution
<wolfspraul>
sourcing is always a bit messy, full of surprises
<wolfspraul>
so the system just needs to be flexible and robust and allow for easy modifications
<wpwrak>
yes, boom needs much more context. you need to define which parameters describe a part, you need to define how you represent this in the schematics, you need parts lists for manufacturers, you need translation tables for distributors, and you need scripts that poll the distributor's database
<wolfspraul>
but it seems to be like that already...
<wpwrak>
and you also need some system to manage your own inventory
<wolfspraul>
hmm
<wolfspraul>
ok one use case I am thinking about is this:
<wolfspraul>
I commit something into git
<wolfspraul>
an electrical design
<wolfspraul>
now I want to do a run of xx units, let's say 20
<wpwrak>
(lead time) yes. for now i simply use zero lead time = inventory. boom doesn't use parts that aren't in stock.
<wolfspraul>
ideally the server can present me with some data / price list, so I can quickly send out an order to digi-key for some parts, to farnell for others, to arrow for yet others.
<wolfspraul>
and maybe source some key parts totally elsewhere
<wolfspraul>
for me it's about making the life of someone who wants to execute a run easier
<wolfspraul>
how can he efficiently generate and upload and order a shopping list
<wpwrak>
for that query, you would (now) do this:Â Â make KITS=20 again show-atusd
<wolfspraul>
not click around websites forever
<wpwrak>
yes, definitely
<wolfspraul>
also prices, availability and lead-times are constantly in flux
<wolfspraul>
so it needs to be able to draw data from multiple vendors
<wolfspraul>
you think boom fits the purpose I am describing (now or in the future, just want to make sure I am looking at the right tool)
<wpwrak>
you'd also need vendor preferences. e.g., for me, electrocomponents.com.ar would be quite convenient. for you, not that much :)
<wolfspraul>
sure
<wolfspraul>
the process will be full of exceptions/customizations
<wpwrak>
you can control this in boom by what vendor lists you feed to the system
<wolfspraul>
sometimes you have some parts in stock from an earlier run
<wolfspraul>
or the price drops significantly if you order 50 instead of 20, so significantly that you are better off ordering the 50 today
<wolfspraul>
and so on
<wpwrak>
but once a vendor is included, it will be treated as equal to all others. so that's not very realistic.
<wpwrak>
boom does that kind of calculation
<wolfspraul>
well it cannot know about planned future runs :-)
<wolfspraul>
and the size of them
<wolfspraul>
unless you tell it somehow, of course
<wolfspraul>
but like I said I am not looking for the perfect system
<wolfspraul>
just a starting point, then we can refine it slowly for real runs, real shopping activity
<wpwrak>
no, that not :) but if 40 x MOQ 1 price > 1 x MOQ 50 price, it will get 50
<wolfspraul>
sure but if your run is 20, but at 50 the price drops a lot, and you have another run of 80 planned later, you may want to order 50 now already
<wolfspraul>
or even 100 right away, especially if there is another price drop there
<wpwrak>
yes, i understand. that's something it doesn't know :)
<wpwrak>
i think it would be useful for have some tool for interactively exploring the information/database. there are other areas as well, where the batch approach doesn't work so well, e.g., all the rewriting rules
<wpwrak>
but i think it's safe to get started with it as it is now. you can always convert data and add features later
<wolfspraul>
totally it needs to be able to easily make manual overrides, not everywhere but at some key places
<wpwrak>
(overrides) yes. there are some overrides you can do via equivalences. e.g., atrf.equ
<wpwrak>
there i'm substituting the expensive wuerth balun with the less expensive johanson part
<wolfspraul>
does it currently assumes the inventory is always there together with the parts data?
<wolfspraul>
for me they are different
<wolfspraul>
the server doesnt' know about inventory
<wolfspraul>
the inventory is local to whoever wants to do a run
<wpwrak>
it needs the inventory to decide what to pick
<wolfspraul>
so you upload your inventory, then the scripts can tell you what is missing
<wpwrak>
otherwise you get things like atusd.par, with a list of all possible choices. pretty much useless for humans.
<wolfspraul>
or the scripts will always run based on an inventory assumption of 0, then you need to deduct what you have already at the end, either manually or with a separate script that is run on the 'client' (i.e. the machine of the person doing the run)
<wpwrak>
(right now, the list is still manageable. but that's just because i didn't add a lot of sources)
<wolfspraul>
sure but I think about running this on the projects server now
<wolfspraul>
what 'inventory' does the projects server have?
<wpwrak>
inventory assumption 0 means that it will not produce any output
<wolfspraul>
well let me look at the whole thing first
<wpwrak>
i think what the project server can do for you is to give you a "reasonable" shopping list
<wolfspraul>
you have thought about it much more than me, you need to give me some time to catch up...
<wpwrak>
if you want to customize, the you need to run it locally
<wpwrak>
it would be possible to generate a list of alternative sources from the existing data. but that needs a different representation. e.g., with html output and when you click on a position, it shows you all the possible sources.
<wpwrak>
even that wouldn't be perfect, though, as there may be equivalent parts. and sometimes, parts for distinct components get lumped together.
<wpwrak>
e.g., if you need a 100 kOhm 1% resistor and some 100 kOhm 5% resistors, then it may be cheaper to buy everything 1% than splitting
<wolfspraul>
ok but that example would only matter in higher volumes
<wpwrak>
so you get one entry in the shopping list. but if you change the suppliers, that may change as well, so the number of positions in the shopping list is variable as well.
<wpwrak>
naw, particularly for small volumes :)
<wolfspraul>
whether a resistor has 1% or 5% accuracy?
<wpwrak>
if MOQ for a resistor is 1 at one place and 10 at the other, that may already make a difference. of course, it's cents.
<wolfspraul>
he, that's what I mean
<wolfspraul>
fractions of cents
<wolfspraul>
ok anyway, boom should try to deal with those cases, even to document them is good
<wolfspraul>
it's not infinite after all
<wolfspraul>
that's why I like boom, it tries to bring order into this mess
<wpwrak>
there a bit the problem of computational complexity. also, perl isn't the most efficient language for such things.
<wolfspraul>
k great I think I got it somewhat
<wpwrak>
but so far, it's holding up well, also for a larger project like gta02-core.
<wolfspraul>
let me read through the scripts and think a bit
<wpwrak>
have fun ! :)
<wolfspraul>
I want to get this up and running on the qi projects server, for sure
<wolfspraul>
one-click shopping list
<wolfspraul>
:-)
<wolfspraul>
maybe you also need to tell it your income level
<wolfspraul>
if you are rich, just order everything from digi-key, done
<wpwrak>
sounds good. also, people often wonder what the material cost of some project is. that would provide a quick answer.
<wolfspraul>
maybe you need to give it your self-declared hourly salary
<wolfspraul>
ah yes
<wpwrak>
digi-key aren't that expensive ...
<wolfspraul>
but frankly, if I get that type of 'bom' question I already know it's not going anywhere
<wolfspraul>
the people that are asking these questions have a strange mindset
<wpwrak>
many things there are quite okay.
<wpwrak>
;-)))
<wolfspraul>
well you know what I mean
<wolfspraul>
I just tend to say 500 USD nowadays, to make them go away.
<wpwrak>
well, it's an indicator. like "are we talking about a 1 USD or a 1000 USD part"
<wolfspraul>
hardware is hardware, every 1k has new surprises
<wolfspraul>
sure, but you know what I mean
<wpwrak>
yeah. it's not the price they'll see in the shop :)
<wolfspraul>
'bom' seems to be something that even people that should have never heard about this term have heard about, somehow
<wolfspraul>
and then it gets nasty
<wpwrak>
the bom is okay for those who actually do want to DIY. of course, few do, many talk :)
<wolfspraul>
what I want is probably mostly an ordering system
<wolfspraul>
so someone looks at project X, and decides he wants to order the parts for a run of 20
<wolfspraul>
the server should make it possible for him to actually send out those orders within let's say 4 hours, and not paying totally too much
<wolfspraul>
in other words comparing a few distributors, making a few manual overrides for stuff he found who knows where, etc.
<wolfspraul>
so the scripts should help to bring down the time it takes to issue actual orders (credit card in hand), while at the same time not letting costs go through the roof
<wolfspraul>
that's how I look at it
<wolfspraul>
then we can slowly improve it...
<wpwrak>
the algorithm should probably have some estimate of the S&H cost per distributor.
<wpwrak>
of course, that gets complicated on the computational side. i'm not sure brute force goes a long way with this. (brute force would be to try all 2^#distributors-that-have-at-least-one-non-unique-part-we-need combinations)
<wolfspraul>
he
<wolfspraul>
maybe an interactive javascript would also not be bad
<wolfspraul>
you just click around your multi-source order form until you are happy, then press the big BUY button
<wpwrak>
kristianpaul: yup, been there, done that :) and i doing it in u-boot didn't make me like u-boot better :)
<kristianpaul>
:/
<kristianpaul>
so what you sugguest for dual booting?
<kristianpaul>
no dual booting?
<kristianpaul>
iris.. ?
<kristianpaul>
grub?
<kristianpaul>
:p
<wpwrak>
adapt the idea of the "qi" boot loader
<wpwrak>
something small and specialized
<kristianpaul>
iris?
<kristianpaul>
well is getting close
<wpwrak>
iris looks like it's going in the same direction of u-boot. very complex and not very mainstream. so maintenance can easily become a problem.
<kristianpaul>
:/
<wpwrak>
if you really need maximum flexibility, use a linux system :) you could make a small recovery system that can also boot something with kexec. of course, it would be relatively large, but then everything would be standard tools.
<wpwrak>
i did something like this as well, http://kboot.sourceforge.net/ (never made it past proof of concept, though)
<kristianpaul>
what is uboot for right now, just boot linux and setup soem devices at startup?
<larsc>
on the jz4760 I more or less directly boot into linux and have a shell in one second after pushing the poweron key. something similar should be possible for the nanonote
<kristianpaul>
so you mean linux can boot it slef and do the other job?
<kristianpaul>
larsc: :O
<kristianpaul>
thats great
<wpwrak>
larsc: wow, 1 s is excellent !
<kristianpaul>
so the bootloader was moved to hardware some how?
<kristianpaul>
what power do we lost about hardware initialization with the jz4760?
<wpwrak>
larsc: how much of the user space comes from initramfs ?
<larsc>
but in theory you could put a minimal openwrt with nand tools initrd + kernel in 4 MB or so
<kristianpaul>
larsc: what stops current xbusrt in the ben to wont be able to same as jz4760?
<larsc>
nothing
<larsc>
well, the cpu is clocked slower, so it probably will take a moment longer
<wpwrak>
larsc: the video seems choppy. (4 mb) yup, that sounds about right for a minimum system. a few years ago, i put kboot (kernel + user space) on a 1.44 MB floppy. the only way to boot my Sony C1 ;-)
<wpwrak>
if we can get linux to boot in ~1-2 s, the first-stage boot loader can be kept very very simple. doesn't even need debugging output and such. just initialize the cpu, the ram, load system from nand and go.
<wpwrak>
no need for user input to select the boot partition, no need for uSD support, no file systems, etc.
<larsc>
the bootrom loads the first 8k from the nand and executes them
<wpwrak>
8 k is plenty for this kind of work
<larsc>
yes
<kristianpaul>
larsc: there is documentation aboout this "fast boot" method somewhere?
<larsc>
kristianpaul: there is nothing special about it. the first 8k contain the spl loader. on the nanonote the spl loader loads u-boot and executes it. for the jz4760 I modified it to load the kernel and execute it
<kristianpaul>
oh
<wpwrak>
larsc: what fs do you use ?
<larsc>
yaffs2
<larsc>
it's the only one which scales with nand size
<wpwrak>
larsc: okay, we wouldn't need scalability in this case. but a very fast root fs mount.
<wpwrak>
ever looked at logfs ? it did sound promising. but i didn't follow what happened with it.
<larsc>
i wanted to look at it but i couldn't find a tool which generates a rootfs
<larsc>
a rootfs image
<larsc>
wpwrak: do you thing it is possible to do zlib decompression in 3 or 4k?
<wpwrak>
larsc: i don't really know. but i think the code isn't all that large. needs lot of ram, but we have that.
<larsc>
yep
<larsc>
that way we could support compressed uImages
<wpwrak>
yup. ideally, decompression would run in parallel with nand loading.
<larsc>
indeed
<larsc>
nand access is right now the biggest bottleneck
<wpwrak>
we can do nand with dma on xburst, can't we ?
<larsc>
yes
<larsc>
but it's slower :/.
<larsc>
or i did it wrong
<wpwrak>
that's weird
<larsc>
well there is overhead in setting up the dma transfer
<larsc>
and if the cpu is otherwise idle it might indeed be slower
<wpwrak>
hmm, can't find any description of bus priorities
<wpwrak>
if the cpu just runs off the cache, then dma should be as fast as non-dma (in a reasonable architecture)
<larsc>
well you get additional dealys from starting the dma transfers
<larsc>
delays
<wpwrak>
can you set up the dma when initiating the nand operation or do you have to wait for it to enter the data transfer phase ?
<wpwrak>
in the former case, there should be no significant delay
<larsc>
hm, not sure. i don't remember the details
<larsc>
but i guess i could overwrite {read,write}_page and setup the dma descriptors while the nand chip executes the command
<wpwrak>
yup :)
<wpwrak>
what documentation do you use for the MIPS core ? also the xburst core manual doesn't seem to have bus priorities :-(
<wpwrak>
actually, the core wouldn'
<wpwrak>
t care about it. it's all in the bus
<wpwrak>
that would be a question for ingenic then: how to give DMA higher bus priority than the cpu ? (or give it has much priority as possible)
<wpwrak>
plan B: see if one could insert instructions into the busiest loops that let the cpu release the bus for a while do that the dma can write its buffers. hmm, gotta check if it actually has write buffers ...
<wpwrak>
sigh. where's the reconfigurable SoC when we need it ? ;-) this would be so much fun if we could mess with the soc architecture.
<larsc>
well, if the cpu would be otherwise idle and dma was running in the background the cpu should go to sleep
<larsc>
not accessing the bus at all
<wpwrak>
yup. when it's really idle, yes
<wpwrak>
with decompression, we'd want NAND DMA to have priority while the cpu uses whatever is left.
<larsc>
i see
<wpwrak>
when nand is done, the interrupt wakes the cpu from sleep. cpu fires off the next transfer and goes to work on page N-1.
<wpwrak>
i suppose you can command the cpu to go to sleep and if an interrupt is pending, it'll just stay awake. so the case where the nand finishes first wouldn't need any special-casing.
<wpwrak>
of course, the code that drives the nand would live somewhere in the "read the next byte" function of the decompressor. but proper layering is for whimps anyway ;-))
<wpwrak>
with such a design, you wouldn't even need a real interrupt handler and things would still run nicely in parallel
<larsc>
hm, i think there is a flag in the dma descriptor which tells the dma engine to take the bus
<larsc>
and not release it until the transfer is done
<larsc>
thought that might not be what we want
<wpwrak>
you mean DCMn.TM, block mode ?
<wpwrak>
yup, must be the one
<larsc>
yes
<larsc>
the problem with nand dma is that it is a mem-to-mem transfer. so there is no fifo or whatever that gets filled up by the nand controller
<larsc>
and we'll simply block the bus while the dma engine waits for the nand
<wpwrak>
yes
<wpwrak>
so i think it should be "single mode"
<wpwrak>
DCNn.RDIL looks like the burst length. so that would be useful.
<wpwrak>
i haven't found the DMA vs. CPU priority yet, though
<wpwrak>
very often, dma is given bus priority over the cpu. so there's hope for this to be the case here as well.
<wpwrak>
there's no mention of write buffers in the dma. this is bad.
<wpwrak>
nor in the NAND controller, for that matter
<wpwrak>
hmm, Jz4740-pm section 3.5.2 says that only 4 kB are loaded by the boot loader
<larsc>
no thats the internal rom?
<larsc>
or maybe it was changed for the jz4760
<larsc>
right
<larsc>
looks like they doubled the size for the jz4760
<wpwrak>
well, we survived with 4 KB on the S3C2442, so it'll be possible here as well :)
<larsc>
if nothing else, we can always load the other 4kb by hand
<wpwrak>
yup
<wpwrak>
a test for dma behaviour would be to initiate a transfer, let the cpu sleep, and measure how long it takes from start to interrupt.
<wpwrak>
then do the same but make the cpu hammer the memory. if they take the same amount of time, excellent. if not, things may need more investigation.
<larsc>
looks forward to a future where don't have to speculate about the internals of the SoCs we use
<wpwrak>
indeed :)
<kristianpaul>
indeed :)
<kristianpaul>
wolfspraul: seems in the backlog for today there is a interesting question for ingenic at 17:02
<kristianpaul>
GMT -5
<kristianpaul>
:p
<wolfspraul>
kristianpaul: what is the question, couldn't find it...
<kristianpaul>
17:02 < wpwrak> that would be a question for ingenic then: how to give DMA higher bus priority than the cpu ? (or give it has much priority as possible)
<kristianpaul>
17:03 < wpwrak> plan B: see if one could insert instructions into the busiest loops that let the cpu release the bus for a while do that the dma can write its buffers. hmm,  gotta check if it actually has write buffers ...
<wolfspraul>
hmm
<kristianpaul>
it was a result of chat in wich uboot was some way kicked out byt the direct loading of linux kernel in order to get faster boot times
<mth>
wpwrak: section 4.5 of the pm says something about how long a DMA transfer will claim the bus
<wolfspraul>
yes I saw that video, nice!
<wolfspraul>
larsc: can I upload this into the qi wiki? may want to include it in the community news...
<larsc>
wolfspraul: sure. but it's not really qi related. except that i borrowed the nanonote rootfs
<wolfspraul>
well it's a nice 4760 video
<wolfspraul>
qi related in the sense of copyleft hardware? no. but qi related since we decided to use Ingenic XBurst for a few years to get us started, yes.
<wolfspraul>
we may very well do some products with 4760.
<wolfspraul>
I doubt Milkymist can replace that chip fast enough :-)
<wolfspraul>
I need to go back kick these people (Ingenic), haven't met with them in a few months.
<wolfspraul>
larsc: thanks for permission, I'll upload it then and mention it as some 4760 related work. I think it's cool. If you want me to hold back until later or not mention it, also no problem. whatever is best for you.
<larsc>
wolfspraul: it's ok. i just wanted to avoid that people might think that qi is activly working on a jz7460 based the next-gen nanonote.
<wolfspraul>
good point, I'll mention that
<wolfspraul>
I think there are only 3 choices for the CPU in the Ya NanoNote: 4740, 4760, Milkymist (spartan-6)
<wolfspraul>
s-6 is a bit crazy, needs a lot of testing, more software, etc. maybe we can make a few boards for experiments, but I cannot imagine this to become real anytime soon.
<wolfspraul>
that leaves 4740 or 4760.
<wolfspraul>
we could do a lot with a 4740-based board that applies everything we learnt
<wolfspraul>
it also depends on whether we can get things like ben-wpan or gps_open_stack to work with the 4740, or whether they depend on some 4760-specific feature
<wolfspraul>
well I think you know all this anyway, but good point if I include the video I'll mention this
<wpwrak>
wolfspraul: 4760 would be nice: 3 MMC controllers. that way, you can have two slots. also, two SPI controllers, like the 4720. (4740 only has one)
<wolfspraul>
well the Ya could have 4720 too of course. I didn't know that 4720 has advantages over 4740 in some features.
<wolfspraul>
4760 would be nice, but it's a lot of work, well luckily larsc seems off to a good start. I will go back to Ingenic to see what's going on.
<wpwrak>
(4720 better than 4740) SPI seems to be the only one
<wpwrak>
well, i haven't collected infos on all details. so there could be others. e.g., my table doesn't have ADC channels.
<larsc>
wpwrak: are you sure?
<larsc>
that there are two spi ports?
<wpwrak>
lemme check ...
<wpwrak>
hmm no. figure 1-1 (page 3/5) of jz4720_ds says there are two SPIs but the rest of the manual only talks about one
<larsc>
the block diagram mentions two spi ports. but if you check the pinout there is only one
<wpwrak>
yes. foolish me to trust in the overview diagram :)
<wolfspraul>
so both 4720 and 4740 have only one SPI?
<wpwrak>
yes
<mth>
compared to 4740, the 4760 has a 50% higher clock, floating point support and a coprocessor that can be used for video decoding or other pipelined operations
<mth>
the coprocessor is an xburst core with a small local RAM, similar to the Cell SPUs I think
<wpwrak>
mth: ah, so the two cores don't both have access to all the memory and peripherals ?
<mth>
wpwrak: all the info I have is a summary of the specs, but it looks like it has only a local RAM that can be DMA-ed to and from
<wolfspraul>
yeah quite a few 4760 related files leaked to baidu
<wpwrak>
yu[, that
<wpwrak>
's the one i meant
<larsc>
and there is also a gpu core
<larsc>
there is no documentation though how to access either the vpu and the gpu.
<wpwrak>
so the 2nd core may not be able to do efficient i/o. that was one of the theories behind the idea of doing gps in software - that one core could be dedicated to gps decoding and (implicitly) would also do all the i/o
<larsc>
and their offical kernel doesn't make use of the fpu either
<wpwrak>
does it even work ? ;-)
<wolfspraul>
larsc: got lost in the acronyms. there is no documentation on vpu, fpu and gpu, right?
<larsc>
well if they exits they are not part of the pm
<larsc>
neither is documentation about the gps unit
<wolfspraul>
my feeling is the gps unit will be a failed project
<wolfspraul>
the way they work is they quickly throw together a lot of stuff
<wolfspraul>
then they see what works, and only those features get marketed
<wolfspraul>
:-)
<wpwrak>
larsc: gps unit ? where ?
<wolfspraul>
so over time the datasheets get lighter and lighter
<wolfspraul>
basically the first one is a wishlist
<wolfspraul>
then it slowly becomes reality, as features are removed
<wpwrak>
wolfspraul: nice approach. so much more efficient than fixing bugs :)
<wolfspraul>
I am still not 100% convinved that the 4760 will even be a 'success', i.e. the improvements over earlier chips (the ones that are actually working) are enough to convince customers to upgrade to it, or start using it
<wolfspraul>
that question can only be answered very late in this game :-)
<wolfspraul>
in fact Lars has one of those potential customers asking him now to help get some stuff to work, that Ingenic cannot get to work (correct me if I'm wrong)
<roh>
wolfspraul if its easy enough to integrate and cheap enough not to get tackled by the earlier ones to much...
<roh>
uh. so integration isnt easy?
<larsc>
wpwrak: iirc the ds mentions the gps unit as well
<larsc>
wolfspraul: it's just boot time optimization
<wolfspraul>
larsc: the last ones I've seen have it removed
<wolfspraul>
I need to ask again.
<wolfspraul>
the GPS front-end RF IC would come from a Shanghai startup
<wolfspraul>
and this is their first IC
<wolfspraul>
well at least they hired an entire American (!) IC design team, so I was told
<wpwrak>
larsc: _ds only has "gps" in one place. and that's the kind of devices it's for, not a subsystem.
<wolfspraul>
it seems they think because the team is American, they must know how to design ICs
<wolfspraul>
in fact Ingenic is the only customer of that Shanghai startup
<wolfspraul>
and the Shanghai startup is funded by someone who made his money in real-estate and has no clue about high-tech.
<larsc>
wolfspraul: i have one from sep. 16 which still mentions the gps module
<roh>
wolfspraul yummi ;)
<wolfspraul>
so there was a lot of let's say 'irritations' when the technology didn't behave like a skyscraper
<wolfspraul>
but whether there is a functioning chip in the end only god knows
<wolfspraul>
so I will ask about FPU, GPU, VPU, gps
<larsc>
ok. have to go to sleep now. need to be at work in 6h...
<wolfspraul>
since I learnt more about the Shanghai startup and their first IC being this GPS front-end IC, I started to work with SiGe instead
<wolfspraul>
(on the GPS front-end RC IC)
<wolfspraul>
I will try to collect some info...
<wolfspraul>
n8
<roh>
i wonder if the the ublox guys would be ready to open their hw. (not meaning their fw for the arm7, just how to replace it with a free one)
<wolfspraul>
I highly doubt that.
<wolfspraul>
u-blox essentially is a software company
<roh>
exactly. but that way they could 'sell more chips'
<wolfspraul>
if our copyleft hardware project succeeds, 100% of what u-blox actually does will be openly documented, if copyrightable licensed under gpl or cc-by-sa
<wolfspraul>
ah no, what's left for them?
<roh>
wolfspraul i doubt that any fre project would get near their results when it comes to performance soon
<wolfspraul>
they use SiGe front-end RF ICs too btw, in some products (forgot which one)
<wolfspraul>
so?
<roh>
means one could develop sw on the same hw others use with their binary the rest of the time. win-win
<wolfspraul>
yes sure
<wolfspraul>
that's why I work with SiGe, same as u-blox
<roh>
we get documented hw, they get chips sold and the users can decide if they want to use all free or most free and some commercial code running
<wolfspraul>
kristianpaul has the evb, he's on it
<roh>
SiGe?
<wolfspraul>
yes true, but all this is already happening
<wolfspraul>
only that you are looking at the wrong partner if you look at u-blox
<wolfspraul>
u-blox is a proprietary software company, like Microsoft, Adobe, etc.
<wolfspraul>
you think they would work with you?
<roh>
sure. but atleast they got proper hw. something on the level of sirfIII i wouldnt even start looking at
<wolfspraul>
I had a great meeting with them, with one of the founders and the VP of marketing there.
<wolfspraul>
wait a sec let me tell you this story
<roh>
i dunno what hw SiGe does. any pointers?
<wolfspraul>
you know I actually try things in reality before I come to my conclusions
<wolfspraul>
one sec
<wolfspraul>
so I went there
<wolfspraul>
very nice office at lake zurich btw
<wolfspraul>
company growing, stock market etc.
<wolfspraul>
it's funny, when Openmoko & u-blox started to work together, Openmoko was twice bigger (in employees) than u-blox
<wolfspraul>
after 2 years, u-blox was 20 times bigger than Openmoko
<wolfspraul>
listed on the stock market, founders were millionaires, etc.
<wolfspraul>
I think the founder of Openmoko would have liked this exactly the other way round.
<wolfspraul>
but back to the meeting
<roh>
heh. they had a working product already then, right?
<wolfspraul>
so it was kind of a 'let's look back at the last 2 years' meeting
<roh>
i mean.. then moko and ublox crossed paths
<roh>
s/then/when
<wolfspraul>
and what they said made total sense to me. I asked whether the collaboration with OM met their expectations.
<wolfspraul>
they said "YES!", and that they always saw the entire Openmoko project as 'extended documentation', and that was exactly what it turned out to be, and why it was 'nice' for them
<wolfspraul>
brought a few customers here and there to them
<wolfspraul>
EXTENDED DOCUMENTATION!
<wolfspraul>
well I thought about it, and realized - THEY ARE RIGHT :-)
<wolfspraul>
all OM created was extended documentation, that brought some random lost souls to u-blox technology
<roh>
well.. thats what linux is when done right and in the spirit of gpl. the best sdk you can get
<wolfspraul>
this extended documentation was very costly to create, but u-blox didn't pay, so why not...
<wolfspraul>
no come on. if you create 'extended documentation' you are lost.
<wolfspraul>
imagine the Linux kernel would not actually solve anybody's problem, but all computer science classes in the world would use it as 'extended documentation'
<roh>
they already got quite cool stuff i i remember right.. layouts, and a really detailed documentation of their fw-api in some *sigh* windows format
<wolfspraul>
sure they believe in open API
<wolfspraul>
they are very open minded, clear and sharp
<roh>
documenting hw isnt anything else. just the level of detail is different
<wolfspraul>
of course that also means they super clearly understand why they are in business, and why their customers are paying them, which is because they are holding proprietary IP, copyrights and patents.
<roh>
their sw would even gain because dual implementation on the same hw exposes more bugs which can be fixed in later revisions
<roh>
also hw-bugs
<wolfspraul>
also they foudn it a bit funny that OM was so happy with u-blox only because accidentally (their own words) their firmware was in ROM not RAM
<roh>
thats why drivers are often so hard
<wolfspraul>
I can see how that much look funny from their side.
<wolfspraul>
but then again, hey, if someone wants to spend x million USD to write extended documentation for our proprietary technology, why not... more power to them! :-)
<wolfspraul>
roh: let's get back to positive things, SiGe
<roh>
wolfspraul well.. i knew that.. yes it is/was a blackbox. but none which shared ram or rom with the app cpu so it is/was fine by my definition of opensource
<wolfspraul>
if you look at what u-blox does in more detail, you realize they outsource all manufacturing/hardware, even RF stuff
<wolfspraul>
roh: yes they laugh at you for that.
<wolfspraul>
of course you can take that :-)
<wolfspraul>
if it provides only 1 penny advantage to them, they will move their proprietary tech from ROM to RAM
<roh>
wolfspraul my definiton of opensource in hw is different from stallmans there ;)
<wolfspraul>
so let's look at u-blox deeper
<roh>
wolfspraul as long as its seperate ram, i dont care
<wolfspraul>
they are a software company
<wolfspraul>
they like open APIs, of course
<wolfspraul>
free SDKs
<roh>
even if i need to load the fw as blob (as long as i can distribute it)
<roh>
see network chips, wifi, etc.. same there all again.
<wolfspraul>
they won't even help you understand how they are making theri stuff, that would be pretty crazy
<roh>
but i need the specs/documentation how to load it and the distribution rights for the fw also then (as well as its api documentation of course)