<wolfspraul>
the 4760-based hardware we can get now has way too many closed parts embedded to be fun to work with
<wolfspraul>
and they were not put there by accident, but on purpose. makes no sense to me to work against that somehow, let them do what they want to do...
<wolfspraul>
I'm wondering what the mechanical of the Ya NanoNote will look like, and how it's made
<wolfspraul>
we ended up doing nothing for the ben-wpan mechanical, and I think that's a little sad. as an open pcb they are very vulnerable.
<roh>
oh.. what parts are closed? some 3rd party gpu?
<kristianpaul>
SIMD :-)
<kristianpaul>
i remenber...
<wolfspraul>
I meant the entire product. schematics, layout, bom, datasheets of all chips, mechanical, etc.
<kristianpaul>
oh sure...
<kristianpaul>
atben case, i did some tests in the past actually, i still having the prototypes with me.. but a 3d printed case is not the best quality in the short term of use..
<kristianpaul>
well there are other steps that can improve that but not my interest right now..
<wolfspraul>
oh sure, just saying which 'todo' parts I'm thinking about
<wolfspraul>
finding the shortest way to a 4760 product is not my thinking. if it's easy somewhere and helps, we take it.
<roh>
true. there is a lot to optimize. but anyhow, we need a working, not too expensive soc which is faster and can do more than the old one in the ben
<roh>
atleast thats my pov
<wolfspraul>
all just opinions anyway. when designing a product, the strength and flexibility of free software can overcome the advantage of a new piece of closed hardware, imho. at least sometimes, and I am looking for those kinds of opportunities.
<wolfspraul>
kristianpaul: any namuru / tracking news?
<kristianpaul>
not yet
<kristianpaul>
i have some to do actually...
<roh>
so we can concentrate on stuff like mechanics and not reinvent the soc also in the next product
<kristianpaul>
it seems so..
<wolfspraul>
roh: thinking about anti-vendor just now, look how the Palm Pre ended up
<wolfspraul>
all that passion was wasted again
<roh>
i dont get the anti-vendor part
<wolfspraul>
we need to get smarter in how to build a lasting foundation
<roh>
i mean.. would you rather like to use something like a freescale cpu?
<wolfspraul>
no I just meant in general, same as your references to '4760 products in the open market'
<wolfspraul>
if there are vendors we buy from, they should support the openess
<wolfspraul>
email the vendor who makes that 4760 hardware, ask them to publish or at least send you schematics, layout, bom, all datasheets, mechanical design files, etc. if they don't reply, don't use that stuff :-)
<wolfspraul>
in the few cases I tried since (like Hanvon e-readers), I failed, predictably. Waste of time.
<wolfspraul>
so I'm trying to find more companies and partners that share our vision on the power of open parts.
<wolfspraul>
where I believe we make nice progress
<wolfspraul>
roh: how do you like the Freescale chips? anything that stands out, is interesting?
<wolfspraul>
just reading about Freescale on Wikipedia - wow they have interesting stuff!
<wolfspraul>
and what a history. first two-way mobile radio etc.
<roh>
wolfspraul: well.. the chips seem to have solid linux support done by people who know what they are doing
<roh>
specs and datasheets are open to anyone without registration..  from my pov pretty much as good as it gets
<roh>
especially since support is mainline already mostly afaik
<roh>
pengutronix is doing the kernel stuff as far as i know
<wolfspraul>
the only problem is the price
<roh>
you think?
<wolfspraul>
just checking at digikey a bit. they have about 20 Freescale i.mx in stock.
<wolfspraul>
the cheapest costs 9 USD, i.mx 23
<wolfspraul>
then it quickly goes up to 20, 30, more
<wolfspraul>
the cheapst i.mx51 costs 38 USD
<roh>
sure. checked the specs?
<wolfspraul>
the cheapest i.mx 50 23 USD
<wolfspraul>
oh I can imagine the specs. but those prices pretty much destroy any hope to make powerful cheap devices, ever.
<roh>
also... people are happy to pay 20-30% of the product price (compared to single unit prices) on desktop and notebook cpus. so why should that be a problem for other devices?
<wolfspraul>
because the new chips will be priced as high or even higher, and the old ones discontinued to not cannibalize sales of the new chips too much
<wolfspraul>
wait wait
<wolfspraul>
there's so many things that go in there
<wolfspraul>
there is _zero_, but really _zero_ innovation in the desktop and notebook space
<wolfspraul>
those companies have collectively let go anybody who could innovate
<wolfspraul>
so yes, the percentage of the cost of the main CPU in a typical notebook is amazing
<roh>
imx 50 is 800mhz and ddr2 ram
<wolfspraul>
the i.mx chips would only be the central part of any interesting product
<wolfspraul>
yes but look at the price structure. 10-40 usd basically. that price structure will be kept, it may even go up.
<wolfspraul>
that's what gets you the nice kernel and pegutronix and all :-)
<wolfspraul>
I'm not in favor or opposed or anything, just trying to get an overview over data points.
<wolfspraul>
but that kind of pricing for 'just' the cpu of your device will, like I said, destroy any hope of making cheap mass-market thingies
<wolfspraul>
it works for a lot of more specialized vertical markets though
<roh>
sure. i am just thinking loudly how we can reduce work on nasty stuff and focus on stuff we can 'gain' some new knowledge and pull it into the open.
<wolfspraul>
the good stuff I see now is kicad, schhist/brdhist, boom, dsv, openerp (still learning)
<roh>
and if we need time and energy to focus on process and mechanics, i guess its ok to 'outsource' some of the time consuming development work of doing platform support to somebody else trustworthy.. i guess pengutronix and mainline is as good as that can get right know
<wolfspraul>
not switching to a freescale i.mx (I just speak for myself of course)
<wolfspraul>
but the Ben NanoNote works, it's already designed, produced, etc.
<wolfspraul>
and I will go back to Ingenic, just needs the right reason.
<roh>
true. still keeping the soc is a gurantee to fail in my eyes.
<wolfspraul>
Freescale and Ingenic are not comparable I think, 2 totally different companies.
<roh>
going to the next soc from them is not so much less work than going to a working platform with linux port.
<wolfspraul>
I think the kernel we have on the Ben is outstanding.
<roh>
from my pov Ingenic only HAS a working linux port because of the ben.
<roh>
so all nasty, time consuming work has been done here. and that will happen again with a new soc where that has not happend before (new ingenic soc)
<wolfspraul>
wait wait
<wolfspraul>
first there is quite a bit of 4760 support already
<wolfspraul>
second - I am not actively working on a 4760 product now, so I don't have that problem :-)
<wolfspraul>
third - I can go back to Ingenic at any time and demand things from them, whether they do them or not is another question
<roh>
sure. the whole thinking only comes into place then anyhow.
<roh>
my point is: neither freescale NOR ingenic are capable of doing a proper linux port.
<roh>
else it would be there already.
<roh>
specialist companies who know how linux works do such things. for > 1 vendor.
<wolfspraul>
I described the low hanging fruits to you above. kicad and tool family, fped, boom, openerp, the entire mechanical toolchain and process
<roh>
vendor ports are always _crap_
<wolfspraul>
we have to get the cost of small runs of interesting products down
<roh>
ack.
<wolfspraul>
a small run of a qfp chip on a breakout board is always easy
<wolfspraul>
so that's not what I mean
<wolfspraul>
but if we can effectively do small runs of medium or higher complexity anything (like the m1), then we have a real chance in the market.
<roh>
all valid points. i just dont want to make the same stupid errors like on openmoko, where keeping a shitty, not fitting chipset together with a overused base design made things stall way to much and delayed everything.
<wolfspraul>
and then we can pick the hardware suppliers that help us make our products work, which can include Ingenic, or Freescale, or others.
<wolfspraul>
if we could time travel back there we would probably do everything differently
<wolfspraul>
it would start with not adding all those new chips on gta02 ;-)
<wolfspraul>
and moving gta01 production to taiwan. and spending much more time on the process, sourcing, tools, production testing, etc.
<roh>
i think mm1 is already our current limit of complexity. we see that on all kinds of things.. layout problems (emv, etc) manufacturing precision, sourcing...
<wolfspraul>
getting the yield under control and getting knowledge of yield problems to more people.
<wolfspraul>
anyway, hindsight thinking
<wolfspraul>
yes, mm1 is nice
<wolfspraul>
just the right level. we can grow without dying :-)
<wolfspraul>
dieing?
<wolfspraul>
near death maybe...
<roh>
in hindsight.. gta01 should never have been sold. and gta2 been developed learning and revising stuff , not adding complexity without testing all things first (prototypes and real tests)
<wolfspraul>
yes
<wolfspraul>
gta01 was a run of 3000, it has to be sold
<wolfspraul>
or a run of that size was premature
<roh>
i know. much too many
<wolfspraul>
you can accept the first 'few hundred' as part of the ramp-up process, but not more than that
<wolfspraul>
even a few hundred only works for cheap consumer electronics
<wolfspraul>
otherwise you need to slow down the ramp-up and learn more first. no point in producing more and more electronic garbage.
<roh>
i think we need to find new levels and process steps for the pvt and dvt series
<roh>
if we go too low, we will not find bugs (sample size too low). if we go too high, we waste money.
<wolfspraul>
correct :-)
<roh>
but i think we are on a good way there.
<wolfspraul>
I'm wondering how some of those ARM chipmakers continue
<wolfspraul>
I wouldn't want to be an ARM chip designer. Like TI for example - will they sell OMAP? To whom?
<roh>
they do sell.
<wolfspraul>
Marvell will become a company just designing chips for their largest customers, they will get out of the general arm chip designer market.
<roh>
i mean.. just watch the asian market and sales for android devices
<wolfspraul>
what chips are in them? I cannot imagine many OMAP designs.
<roh>
all that iOS vs android stats are basically bullshit because they neglect the inner-asian markets completely
<roh>
e.g. there are ONLY 3 vendors selling android3 devices now. samsung, toshiba and acer. and all are nvidia tegra2
<wolfspraul>
how does nvidia design and sell their chips? don't know either. argh. the market is so big.
<roh>
the only one not using tegra announced on omap4 and is some company from china? ive never heard from
<wolfspraul>
yes nvidia must be doing something right.
<roh>
well.. yes and no. nvidia is closed source. period. will not change (they cant, too much licensed 3rd party afaik). i dont buy stuff from them.
<kristianpaul>
what about motorola, they ship android 3 too
<roh>
they do?
<roh>
well.. they got bought by google, didnt they?
<kristianpaul>
and?
<kristianpaul>
:)
<wolfspraul>
I cannot find nvidia tegra on digikey or octopart.com at all
<kristianpaul>
s/motorola/google
<roh>
mostly for patents afaik, but we will know soon enough if they will continue
<roh>
wolfspraul: heh. no chance.
<kristianpaul>
bbl :)
<wolfspraul>
ok so most likely they do designs in close collaboriation with their top-3/4 customers then
<roh>
wolfspraul: they are even too closed to name a price. nvidia has nothing to do with a 'open market'
<wolfspraul>
well I understand that.
<wolfspraul>
you may simply misunderstand their business model
<wolfspraul>
if you go to Apple to buy (eatable) apples, they will also turn you away friendly :-)
<roh>
ack. thats why i named freescale. their businesscase is long term hw like embedded and industrial stuff. much more diverse than the '10-20 devices/vendors' max we see from nvidia or so
<wolfspraul>
look at freescale's entire range (I just read their wikipedia page)
<roh>
so they are used to small customers
<wolfspraul>
then you will see that digital cpus are just a small, very small, part of their business
<roh>
atleast for the imx stuff
<wolfspraul>
which is not bad, that's how they fit in there
<wolfspraul>
they need them so they can have a full range of chips for their customers
<roh>
ack. and i trust them not to flip around policy too often since it would hurt their businesscase and confuse their long term customers.
<wolfspraul>
so yes, I agree, it looks like Freescale will continue to design general market arm chips
<wolfspraul>
sure, they cannot. look at their other chips.
<wolfspraul>
it's almost as if Analog Devices would start making some arm designs, to better integrate with their data converters (they may even do just, I'm just picking an example out of the air)
<wolfspraul>
with TI I'm not so sure, I can imagine them selling OMAP
<roh>
ack. or flip policy around next chip and closing everything up again
<wolfspraul>
they are too big to do what Marvell and nvidia are doing. and taking on Intel directly with "the fastest arm in the world" is too risky.
<wolfspraul>
who else is left in arm land?
<wolfspraul>
#1 freescale, we agree
<roh>
nxp
<wolfspraul>
nvidia, marvell, samsung - no
<wolfspraul>
ti - not sure, don't feel comfortable on their strategy
<roh>
but different scale (small mcu, fighting for parts of the avr market)
<wolfspraul>
only freescale, phew
<wolfspraul>
and then prices are high. you cannot build a competitive smartphone (for example) around a freescale i.mx
<roh>
if you ask for big names, yes. there are hundredts of small companies as ingenic i guess (and which i cannot name)
<wolfspraul>
hundreds maybe a bit too much
<wolfspraul>
in China I know 5-10
<roh>
wolfspraul: even if you would ADD the price of the cpu to a free product it wouldnt sell that worse.
<roh>
stop fighting for a cheaper devices. make a better one. thats the only way to suceed.
<wolfspraul>
yes and no. price is an important part of 'better'.
<wolfspraul>
I am not fighting for cheaper devices, I am fighting for a cheaper process.
<wolfspraul>
big difference
<roh>
it cannot not to be twice as expensive as the nonfree stuff, but it can have some decent (10-20% up-pricing) which people will happily pay for some more freedom
<wolfspraul>
the process has a lot of potential for optimization
<wolfspraul>
10-20% up from a 30 USD Android smartphone? :-)
<wolfspraul>
enough for a coffee at Starbucks
<roh>
ack. so don't frown on a cpu which is 10E instread of 5.. these 5E i guess every customer made happy will pay gladly (i am and would)
<wolfspraul>
let's get the process optimized with free tools, then we can make winning products. I hope mm1 is a start, and the Ben has potential too, in its current form or its successor.
<wolfspraul>
the mechanical is as important as the cpu
<kyak>
mth: (on button fast) yeah, i know it is already addressed in 3.x kernel. But we need it now, in 2.6.37 :)
<mth>
kyak: the commit should be easy to port to an older kernel
<mth>
the only reason it was added in 3.0 and not before is that I wasn't aware of the issue before
<mth>
I think it was zear who told me about it
<zear>
mth, i told you about what now? :)
<mth>
that the Dingoo took a lot of time to power on
<kyak>
--)
<kyak>
mth: do you see any consequences of doing it at boot time via poke?
<mth>
as long as the registers are initialized some time it shoudl work, I think
<kyak>
because this is just faster than porting back even trivial patches.. And already working :)
<mth>
ah, if it's already working then it's fine
<mth>
I didn't read the entire discussion; I thought you might still be looking for a solution
<kyak>
yep, it does work like this
<kyak>
mth: btw, do you have an intention to add screen-blank functionality to gmenu2x?
<kyak>
most of the time, i just go to console from gmenu2x so the screen would go blank
<mth>
it's already present, but there is a problem with SDL where a thread still exits after exec-ing the selected application
<mth>
see Settings > Screen Timeout
<mth>
it was added a few months ago
<mth>
AwAyla has been looking for the cause of the extra thread and did get some clues, but hasn't found it yet
<mth>
*exists, not exits
<kyak>
oh, it's been set to 0
<kyak>
let's see if it works now
<kyak>
all right, it's working from gmenu2x itself!
<kyak>
now, should i start some GUI application form gmenu2x and see if screen goes blank?
<mth>
it only applies to gmenu2x itself
<kyak>
so it works fine
<kyak>
hm, now i wonder where is it controlled for console.. setterm -blank 30 doesn't seems to affect it
<kyak>
seems that mocp fails to build with updated ffmpeg
<kyak>
according to google, the next failure will be mediatomb
<kyak>
jow_laptop: do you think jumping from ffmpeg 0.5.4 to 0.8.2 was a good idea? At least this should have been tested first against dependant packages...
<jow_laptop>
kyak: no I don't think so
<kyak>
ffmpeg has deprecated an older API, so expect a lot of breakage..
<jow_laptop>
I mean I don't think it was a good idea but honestly I only care for backfire atm
<jow_laptop>
which has a forked packageset
<jow_laptop>
but I'll talk to the committer
<kyak>
a forked packageset? this is interesting
<jow_laptop>
well I froze packages/ beginning with rc5
<kyak>
because it was always a fight to keep packages compilable for backfire :)
<jow_laptop>
I now only backport fixes
<jow_laptop>
it will remain this way until final
<kyak>
cool. I didn't think there going to be a backfore-based release
<jow_laptop>
apparently it has bad karma .)
<jow_laptop>
every release manager so far disappeared sooner or later
<jow_laptop>
now I overtook and promplty got swamped by paid work :P
<kyak>
are you the release manager?
<kyak>
heh :)
<kyak>
maybe being a release manager for backfire is a good karma only for the release manager himself? :)
<wpwrak>
"poke" is part of the boot process ? now i really have to catch up with that thread ;-)
<kyak>
wpwrak: did you catch up?
<wpwrak_>
kyak: just with IRC so far ;)
<ignatius->
Is it possible to "fsck" the Ben remotely? I have some UBI errors that need to be fixed, which don't allow me to boot into the system.
<larsc>
you could boot from mmc
<ignatius->
I tried. Didn't work. :( F1/F4/U/M/S)
<ignatius->
I think I may have an older version of the boot loader.
<ignatius->
Someone in here said there was a "bad" version of it. I tried compiling an earlier version of the XBurst tools... same problems.
<ignatius->
As well as the newest branch.
<larsc>
:/
<ignatius->
Any idea where I can get the newest u-boot image?