<kristianpaul>
wpwrak: now i see why still using it :-)
<wpwrak>
kristianpaul: how did grub fail you ?
<kristianpaul>
wpwrak: easy problem about root=something_bad_set here, but was generated automatically so lilo seems not follow that path
<kristianpaul>
was installing voyage linux on his soekris 5501
<wpwrak>
oh dear, double-exotic ;-)
<kristianpaul>
hahah
<wpwrak>
but yes, sometimes lilo's simplicity can save your day. recently, i'm hearing an increasing number of complaints about grub.
<mth>
grub is u-boot for non-embedded systems ;)
<wpwrak>
mth: yeah, a little boot loader that tries so hard to be a big operating system ;-)
<wpwrak>
mth: with u-boot, the fun starts when you add usb, because this gives you *true*concurrency*. all the races, but none of the locking ...
<mth>
I didn't know u-boot had USB support, but I'm not surprised :)
<wpwrak>
mth: i don't know if usb ever made it into u-boot mainline. in openmoko we had it, though
<wpwrak>
mth: and if you think of it, functionality-wise, it makes a lot of sense
<mth>
the Wii homebrew channel accepts USB uploads as well, very useful for testing new programs
<kristianpaul>
mth: You could'nt be so right, actually there is a port of grub as a replacement of pmon bootloader for lemote/yeeloong laptop
<wpwrak>
mth: the only problem is that it drives a borderline design all the way into deepest cuckoo land
<mth>
kexecboot makes more sense then
<kristianpaul>
looks at Jay7
<wpwrak>
totally. and larsc  already has the weapon of u-boot destruction ready for when Jay7 is finishes :)
<wpwrak>
s/is //
<larsc>
i hope so
<wpwrak>
*grin* on cue
<larsc>
It works on the JZ4760
<larsc>
but I think I'm going to start from scratch and write it that way, that it can be used both for the minimal bootloader and as the usbboot firmware
<larsc>
so there is less code duplication in our tools
<wpwrak>
(4760) does this imply that the 4760 wouldn't quite so much of a horrible thing to support anymore ?
<wpwrak>
(usbboot) hmm, never looked into this one so far
<larsc>
wpwrak: i added basic support for it yesterday to our kernel repoi
<wpwrak>
wheee !
<larsc>
so far non of the more advanced peripherals is supported
<wpwrak>
if a ya would happen with the 4760 instead of the 4740, i think that would be hugely better
<kristianpaul>
What device is using the 4760? or is a EVB?
<wpwrak>
rome wasn't built in a day :)
<larsc>
but there is a guy working on a jz4750 port, which is similar to the jz4760 so i'm not the only one working on getting better support
<larsc>
kristianpaul: the evb
<wpwrak>
(4740 vs. 4760) my main concern at the moment is memory. without DDR, you're kinda screwed today ...
<wpwrak>
(ddr) e.g., according to some very superficial studies of mine, for the price of the ben's memory, you could get about twice the amount of SDR today, or four times DDR
<wpwrak>
and that may not even be the end of the story. with "fat" smartphones driving up the demand, quite large memories may become cheaper than smaller ones
<wpwrak>
(well, after the supply catches up :)
<wpwrak>
i also like the huge number of MMC/SD/SDIO in the 4760
<kristianpaul>
Video also may allow higher resolution i guess?
<kristianpaul>
is that the dual cored xburst? or just more speed?
<larsc>
both
<kristianpaul>
how fast?
<larsc>
600 Mhz
<kristianpaul>
oh
<kristianpaul>
thats a laptop :-)
<wpwrak>
ddr is faster than sdr, so you get a lot more memory bandwidth for video
<larsc>
it actually is a tripple core
<kristianpaul>
what?? :O
<larsc>
cpu, vpu, gpu
<kristianpaul>
i see
<larsc>
the gpu is 2d-only though
<wpwrak>
larsc: how useful is the vpu ?
<larsc>
and i've not seen any docs for either the vpu or gpu
<larsc>
wpwrak: without docs not so much
<wpwrak>
okay, that answers it ;-)
<kristianpaul>
ha! :/
<wpwrak>
yeah. with what little i saw, it looked kinda semi-useless
<larsc>
the PM states though:
<larsc>
RealVideo decoding up to 720P 30fps
<larsc>
MPEG-2 decoding up to 720P 30fps
<larsc>
MPEG-4 decoding up to 720P 30fps
<larsc>
VC-1 decoding up to 720P 30fps
<larsc>
H.264 decoding up to 720P 30fps
<larsc>
MPEG-4 encoding up to VGA 20fps
<wpwrak>
oh, for video it's probably cool. dvdk ought to be happy :)
<wpwrak>
i was thinking more of a "real" 2nd core
<larsc>
VÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â PU
<kristianpaul>
larsc: usb on-the-go?
<larsc>
includes an XBurst® CPU with 48kB TCSM and without CACHE, MMU, CP0, DBG and FPU.
<mth>
larsc: tonight we found the cause for the SD errors after resume from suspend: it turns out the cpufreq driver triggers it
<larsc>
ah
<mth>
this also explains why the NanoNote does not have this problem
<larsc>
yep
<wpwrak>
larsc: btw, do you deal with ingenic directly or does this go via wolfgang ? (or maybe even someone else ?)
<larsc>
wpwrak: i got the evb through an third party
<wpwrak>
interesting .. the 4740 is not recommended for new designs
<larsc>
it's 5 years old
<wpwrak>
ah yes, and they don't even mention the 4720 :)
<wpwrak>
good. that settles this question. 4760b looks very likeable, even if it should have 2 out of 3 cores unusable
<larsc>
wpwrak: I told wolfgang that Ingenic has a news item on their page mentioning that the linux kernel now has jz4740
<larsc>
wpwrak: And he answered that it might be time for a visit again
<wpwrak>
good :)
<wpwrak>
larsc: (3rd party) so they would be sort of the first ones to have a linux-based device with the 4760(b) ?
<larsc>
i've never seen the real device, but i guess yes
<wpwrak>
hmm, seems that wolfgang really ought to visit ingenic ...
<larsc>
btw. i got that board back in october
<larsc>
so it's very likley that the product is already on the market
<wpwrak>
so it should be a B by now :)
<wpwrak>
hmm. you added basic support just recently ? so the product doesn't use linux ?
<larsc>
it does
<larsc>
but is based on ingenics sources
<wpwrak>
ah, dead-end then ;-)
<wpwrak>
i'm asking because i'm wondering if there may be an opportunity to have ingenic finance the making of the ya. sort of as showcasing the 4760b. the more open the design, the more reproducibility.
<wpwrak>
kinda like ti is behind the various "1st" omap boards
<wpwrak>
not sure if ingenic think this way, though
<larsc>
hm
<larsc>
they do have their evb which showcases the jz4760, while the ya would probably only expose a subset of the jz4760 functionality
<larsc>
and i'm not sure if they are interested in building a community yet
<larsc>
though it is worth a try
<wpwrak>
evbs are kinda strange devices. a ya could be a lot more convincing. like companies going crazy with trying to clone the iphone/ipad, but very few hot for the (probably) underlying reference designs.
<wpwrak>
sharism/qi-hw ought to have earned a few credentials by now. they must have expected it to be long dead already ;-)
<larsc>
hehe
<larsc>
they signed a licensing agreement with MIPS, so I guess they are targeting the non-chinese market now too.
<wpwrak>
larsc: that would be very much in our favour
<larsc>
maybe they could be convinced that it is in their interest to have something like the Ya as a reference design
<wpwrak>
larsc: yup. now, where's wolfgang when we need him ? :)
<larsc>
espcially when beeing told that companies like TI and Freescale do the same
<larsc>
wpwrak: probably asleep for another two hours
<wpwrak>
larsc: oh yes, sometimes reminding companies of their competitors works wonders ;-)
<wpwrak>
larsc: (wolfgang) until ~1 pm, beijing time ? did he do some particularly hard partying last night ? ;-)
<kristianpaul>
wpwrak: wolfgang have a meeting with a robotic company i remenber
<wpwrak>
probably skynet inc.
<larsc>
btw. as far as i can see the JZ47XX SoC family chips are among the few MIPS based SoCs(If not the only ones) that are competetive in the embedded mobile market.
<kristianpaul>
wpwrak: ucrobotics.com
<larsc>
so it might as well has been in MIPS Inc.
<wpwrak>
kristianpaul: cute :)
<kristianpaul>
wpwrak: yeah
<larsc>
so it might as well has been in MIPS Inc.' interest to have them expand to a global market
<wpwrak>
larsc: ah yes, that would make sense. mips' role is kinda obscure anyway
<larsc>
ARM has become omnipresent while the same can't be said about MIPS
<larsc>
they are still used in quite a lot of routers and such
<wpwrak>
yeah, you have a point there ;-)
<larsc>
but i've yet have to see a MIPS based mobile phone
<wpwrak>
basically arm became the intel of embedded while mips became the via
<qi-bot>
[commit] Jo-Philipp Wich: The cxxtools static library is not built anymore after autoreconf, do not attempt to package it http://qi-hw.com/p/openwrt-packages/61c62b6
<qi-bot>
[commit] Jo-Philipp Wich: Rely on standard autoreconf facility, remove manual autoreconf all, define prereq on host guile http://qi-hw.com/p/openwrt-packages/b14002b
<wpwrak>
wolfspraul: have you seen the discussion with lars about the 4760/4760b in the irc log ?
<panda|x201>
wolfspraul, ah, nice talk with you but with bad coffee :-(
<wpwrak>
rjeffries: heh, "do everything just like in the kernel but avoid actually *using* the kernel at any price". sometimes you really have to wonder :)
<larsc>
wpwrak: it's the kernel without userland support
<larsc>
single-user linux
<wpwrak>
larsc: how much of a difference would user space notice, once the kernel has the necessary drivers in place ? should be pretty much the same, no ? except for things that explicitly touch the hardware (evil-menu2x, bit-banging, ...)
<larsc>
wpwrak: what do you mean?
<larsc>
difference compared to what?
<larsc>
you mean for a jz4760 based board compared to the nanonote?
<wpwrak>
larsc: changes required in user space, compared to what we have for the ben
<wpwrak>
larsc: yes
<larsc>
wpwrak: i was able to boot the nanonote userland without problems on the jz4760 evb
<wpwrak>
oooh ... sorry, i got confused about the threads ;-)
<larsc>
ah...
<larsc>
now it makes sense
<wpwrak>
thought you were referring to the 4760 discussion but instead you meant barebox :)
<wpwrak>
so barebox is a patched kernel ?
<larsc>
it's more of a light-weight api compatible reimplementation
<larsc>
i think the idea was to be able to reuse kernel drivers
<larsc>
but i must admit that i haven't actually looked at the code
<wpwrak>
sounds a bit like u-boot. there are also copies of kernel code in there. of course, in heavily modified permanent forks ...
<larsc>
barebox is u-boot v2
<wpwrak>
yeah. new shinier outfit, all the same design flaws ;-)
<wpwrak>
high time for kexecboot. let's stop all the nonsense :)
<larsc>
i wonder if people realize that you can boot a linux kernel with a minimal initrd in about the same time as uboot
<larsc>
yup
<wpwrak>
quite obviously they don't ;-)
<qi-bot>
[commit] Werner Almesberger: usrp/sps/20110306: examine sidebands ("spikes") and try to reduce them http://qi-hw.com/p/ben-wpan/a60fb1e
<wolfspraul>
wpwrak: no did not see the discussion.
<wpwrak>
wolfspraul: the highlights: lars is getting the 4760 to boot with "proper" linux. 4720/4740 is not recommended for new designs http://en.ingenic.cn/product.aspx?CID=11
<wpwrak>
wolfspraul: so all this suggests that the 4760 may be a better choice for a ya than the 4740, and also that this choice may be more viable than previous discussion suggested
<wpwrak>
wolfspraul: i also brought up the idea that ingenic may perhaps be interested in sponsoring (all or a part of) ya development, in order to a) mainline 4760 support, and b) have a real-life reference device
<wpwrak>
wolfspraul: ah, and 4760 has been replaced by 4760b, with many cute little changes: ftp://ftp.ingenic.cn/2soc/4760/JZ4760B_an01_vs4760.pdf
<wpwrak>
wolfspraul: maybe you want to visit ingenic some day :)
<wolfspraul>
ha yes, that's a funny page (Ingenic's)
<wolfspraul>
4730 is indeed bad, but putting 4740 on the list of 'not recommended' just shows how much trouble they have getting people off of 4740.
<wolfspraul>
4750 and 4755 were never a commercial success, and they won't become one anymore this late in the game.
<wolfspraul>
I hope 4760 will be a big hit for Ingenic, because otherwise the slowly shrinking 4740 margins may squeeze them badly.
<wpwrak>
ah, political EOL :)
<wpwrak>
well, then they should like the idea of sponsoring a shiny device with an open design even better ;-)
<wolfspraul>
I highly doubt that will happen either. You don't understand how much and how long they are holding on to every last penny.
<wolfspraul>
expecting such kind of sponsorship beyond kind words is most likely unsuccessful.
<wpwrak>
i guess it depends on how desperate they are to make people "get" the 4760
<wpwrak>
and of course your sweettalking skills ;-)
<wolfspraul>
no way, this is a business.
<wolfspraul>
no 'sweettalking'
<wolfspraul>
they are not desperate, hopefully 4760 is a great product.
<wolfspraul>
you cannot bribe your own customers...
<wolfspraul>
Lars mentioned that they put some full programmers' manuals on the ftp server now?
<wpwrak>
have you seen siemens lately ? ;-)))
<wolfspraul>
I have to check which ones are there actually, this would be great news.
<wpwrak>
_ds is there. board design guide as well
<wpwrak>
haven't seen _pm
<wpwrak>
(business/sweettalking) marketing is also part of business ...
<wpwrak>
in a way, trying to get vendors to sponsor development work would be a much more honest model than your favoured earn-by-selling devices approach. there's a lot of free publicity and long-term value that's being created in this project that has no relation to short-term revenues. it would only be fair to remind those who derive a strong benefit from this of this fact, and to have them help with the effort
<wpwrak>
earn-by-selling has its place, but that works a lot better once you've made it past this grossly inefficient long-term investment period
<wolfspraul>
this is called 'technical marketing' and long and aggressively being done already, with strong metrics in place to make sure there is good payback.
<larsc>
wpwrak, wolfspraul: all of the _pm.pdf are on their ftp
<wpwrak>
also, if ingenic are trying hard to get people to accept the 4760, this may be a short window of opportunity. there is nothing to be won by just waiting for it to close
<wpwrak>
larsc: where ?
<wolfspraul>
I would need to learn a lot of technical marketing tricks first before daring to go into this business - not interested.
<larsc>
wpwrak: ftp://ftp.ingenic.cn/2soc/
<wpwrak>
wolfspraul: what would be the downside of asking ?
<wolfspraul>
wpwrak: relax, I have been discussing this with Ingenic many times, and many months ago, and I will continue to do so.
<wolfspraul>
but Ingenic is a business and they have been setup to make money (sell), not to spend money.
<wolfspraul>
maybe something can be worked out in conjunction with one of their customers.
<wpwrak>
(docs) wow. this is wonderful !
<wolfspraul>
yes, I agree. that's great news!
<wolfspraul>
wpwrak: hmm. looks like they screwed up otg on the 4760?
<wolfspraul>
so the 4760b fixes that
<wolfspraul>
I just quickly glanced over the 4760b pdf.
<wolfspraul>
you need to read this the Chinese way. those docs are super euphemistic.
<wolfspraul>
basically every new 'design' is like a big gamble
<wolfspraul>
because they work with totally under-qualified employees
<wolfspraul>
will it work? which bugs do we have?
<wolfspraul>
only after some time you see whether this thing actually works, and how many features have to be 'removed' :-)
<larsc>
just like software
<wolfspraul>
of course their customers know this as well, and work with similar staff. quickly turn aroudn the product, throw to the market, see whether it sells (i.e. whether it works)
<wolfspraul>
I mean if a non-working product would sell they would of course love this business too, but it's rather unlikely...
<wolfspraul>
since I started working with Ingenic, all their staff has changed, except for the top level management which is far removed from technical reality.
<wpwrak>
yeah, revisions are usually mainly admissions of prior screw-ups. nothing new there :)
<wolfspraul>
:-)
<wpwrak>
oh dear
<wpwrak>
do you still consider them a viable source then ?
<wpwrak>
wonders if this could be used to our advantage when discussing sponsorship. "given that all the engineering has changed [which i haven't told so many people yet] we would like to help strengthen the design-credibility of the 4760" ... sometimes, a little polite blackmail can go a long way ;-)
<wpwrak>
and even more so if it's actually true :)
<wolfspraul>
wpwrak: of course all is fine with them. If the pm's are open now that's great.
<wolfspraul>
they are a chip supplier, that's all. I need to check how good the 4760 really is, and whether we take unnecessary design risks or whether it's safe.
<wolfspraul>
about 'sponsorship', I already said - if a lot of smiles and nice words is good, that's possible
<wolfspraul>
also some free lunches
<wolfspraul>
and declarations of eternal friendship, new era of whatever
<wpwrak>
;-)
<wolfspraul>
but rest assured they will hold onto every penny of cold hard cash like their life is on the line
<wpwrak>
so you're saying they don't believe technical marketing is worth the effort
<wolfspraul>
Chinese companies are not that advanced yet, I think.
<wolfspraul>
plus the best company to propose technical marketing to them would be a successful existing technical marketing company.
<wolfspraul>
I don't even know by what metrics they work, report their results, etc.
<wolfspraul>
I'm just a product guy.
<wpwrak>
well, maybe you can share some reactions with them. ask a few people what they think of the 4760b. mention how much changed since the 4760. mention that it's a new team, not the one that made the - proven - 4740 and friends
<wolfspraul>
I just need to ask how it's selling, and how 4740 is selling.
<wolfspraul>
I've heard that supposedly there is a 'xburst android phone already shipping in Europe'
<wolfspraul>
that sounds like the uber-version of wishful thinking, all combined into the least amount of words
<wpwrak>
sure, you may not be the best advisor on this. but then, you're someone who does have something that could help, namely a product where everyone can look under the hood as much and as long as they want
<wolfspraul>
but I can look into it, say by trying to buy one of those 'android xburst phones already selling in europe'
<wpwrak>
yeah, a bit of extra information can't hurt
<wolfspraul>
wow nice, just checking on ingenic ftp server
<wolfspraul>
the pms are indeed all there
<wolfspraul>
I'd say that alone puts them into a rare category, no? I haven't checked what Marvell, Freescale, Qualcomm, TI and the others are doing, but full documentation without NDA is at good as it gets. Probably redistribution rights are still missing, simply because they just cannot understand what that thing could possible be.
<wolfspraul>
even in several meetings, I was unable to convince them that this strange additional paragraph I ask them to add isn't some kind of trap that they just don't understand :-)
<wolfspraul>
so whatever, screw the redistribution rights
<wpwrak>
we have dsv to work around these ;-)
<wolfspraul>
I get a phenomenal 2 KiB / second from their FTP server, that hasn't changed a bit in the last 2 years.
<wolfspraul>
can wget do a recursive retrieve on a whole ftp tree?
<wolfspraul>
I think I will backup everything just in case.
<wpwrak>
wget -r seems to work just fine ;-)
<wpwrak>
BOOKSHELF will be next
<wpwrak>
and indeed, this little move makes them quite a lot better for our purposes
<wpwrak>
wolfspraul: you should send them flowers or whatever is appropriate :)
<wpwrak>
2.14 kB/s here
<wpwrak>
interesting. there's now a jz4720_pm
<wolfspraul>
I'd say 50% or more of the reason they open the pms is because of Lars work and the kernel.org inclusion
<wolfspraul>
the other 50% is the MIPS license they finally had to take, and start paying money to MIPS (in other words, their 'patent-free' strategy failed)
<wpwrak>
so they no longer have to be afraid
<wolfspraul>
so they think
<wpwrak>
another item for your next visit: find out what made them change their mind
<wolfspraul>
thay haven't heard about freelancing patent trolls yet, and I will not enlighten them
<wpwrak>
!censor enlighten
<wpwrak>
(i hope qi-bot got the hint ;-)
<wpwrak>
the deal with mips may also provide some protection in this regard
<wolfspraul>
not sure the patent trolls care, and it would be hard for MIPS to find a reason for them to stop
<wolfspraul>
I will let a wget -r run over the 2soc tree now... (or the next days, it seems :-))
<wolfspraul>
maybe I can get permission to mirror it at downloads.qi-hardware.com
<wpwrak>
well, mips could challenge their patents. look at google fighting patents [potentially] used against android
<wpwrak>
oh yes. intermittent 2 kB/s be gone :)
<wpwrak>
but let's finish the wget -r first, then the dsv setup, ...
<wolfspraul>
did David already succeed in getting XBurst hardware acceleration into mplayer?
<wolfspraul>
his mail sounds terrific to me...
<wpwrak>
he seems to be partially there. yes, amazing stuff
<wpwrak>
all the people clamoring for their iWhatever-grade multimedia nanonote may still get their wish :)
<wpwrak>
my wget is struggling. connection stalls all the time :-(
<wolfspraul>
yep
<wolfspraul>
:-)
<wolfspraul>
actually I may demo milkymist one to Ingenic next time
<wolfspraul>
we have a whole list as usual, and surely 4760 is there as well. but I will demo m1 and see what they think.
<xiangfu>
wpwrak: mine is 116Kb/s.
<wpwrak>
xiangfu: so you're the one snatching all the bandwidth !!! :)
<wpwrak>
wolfspraul: sounds cool. you never know what may interest them. when do you think of meeting them ?
<xiangfu>
wpwrak: then I can try to send them to you. if we can put those file in our server??
<wolfspraul>
no fixed plan, maybe in a few weeks. I have some urgent things to settle first, like an upgrade of our payment gateway.
<wpwrak>
xiangfu: we can't put them there officially ...
<xiangfu>
wpwrak: ok. you can try to download in my blog server. if my blog is faster then ingenic's server.
<wolfspraul>
xiangfu: unless they added a redistribution clause, let's wait until we get an official 'ok' in a meeting with Liu Qiang.
<xiangfu>
wolfspraul: ok.
<wolfspraul>
it will be hard to even explain this question, but I gladly go through this inter-cultural experience :-)
<wpwrak>
wolfspraul: the technical argument alone may be sufficient :)
<wolfspraul>
correct. I will offer to donate bandwidth to them.
<wolfspraul>
they count every penny (literally), and the ftp server is so slow because it's the cheapest they could find.
<wolfspraul>
I am not kidding.
<xMff>
heh
<wolfspraul>
if you think about that for a while you realize that your idea of 'sponsorship' (where you actually think about thousands or tens of thousands of USD at least), may not work all that well :-)
<xMff>
maybe they should offer to send CDs for a fee
<wolfspraul>
don't give them that idea
<xMff>
I won't :)
<wolfspraul>
they will hire some people and maybe can make a few cents on it.
<wpwrak>
wolfspraul: ever heard "pennywise smart, poundwise foolish" ? ;-) you should thank them for saving all the pennies so that they can pay you many pounds :)
<wpwrak>
xiangfu: thanks ! i like the bandwidth of your server ;-)
<wolfspraul>
nice try. they have much more money than me, and I am not just trying to get some of that? None of this will work.
<wolfspraul>
ah yes, xiangfu just did the Chinese solution
<wolfspraul>
just finished downloading the 4760 pm, and yes, it looks like it's all complete and all public
<wolfspraul>
perfect
<wolfspraul>
917 pages, soon they are in the 1k+ pages datasheet club
<wpwrak>
wolfspraul: (none of this will work) and only certain way of failing is to never try :)
<wpwrak>
ftp.ingenic.cn actually picked up quite a bit of speed now. 80 kB/s !
<wpwrak>
100 kB/s.
<El-Aurian>
hey, hows everyone doing?
<El-Aurian>
i'm a linux user, and i've got my hp printer to work, using foo2hp... but i'm having trouble getting the printer to work on a windows computer
<El-Aurian>
i'm wondering if its possible to use the linux driver... since i think its a PostScript driver, on a windows machine?
<El-Aurian>
i don't think PostScript is a compiled binary, but rather an answer file, so i hoped it was possible... does anyone have any experience with this?
<jow_laptop>
El-Aurian: wrong channel, sorry
<El-Aurian>
jow_laptop: kk, which channel should i ask on?
<jow_laptop>
El-Aurian: afair there is a general #hardware channel
<El-Aurian>
jow_laptop: yeh, its ##hardware, thanks :)
<jow_laptop>
np
<kyak>
jow_laptop: there is a problem. libopcodes.so is not built anymore by binutils (only libopcodes.la). It is a part of this problem: https://dev.openwrt.org/ticket/8603. It was addressed in gcc-mips by cp $(STAGING_DIR)/usr/lib/libopcodes*.so $(1)/usr/lib
<kyak>
i'm trying now if --enable-shared would work
<jow_laptop>
kyak: there's some libtool heisenbug that, depending on the used autoreconf version (wtf?), randomly disabled or enables shared/static library building
<kyak>
heh. does it mean we should always provide --enable-shared or --enable-static?
<jow_laptop>
no, thats the default
<jow_laptop>
at least its opposed to be
<jow_laptop>
if the wheather conditions are okay, and there's no solar maximum etc.
<kyak>
jow_laptop: ok, the --enable-shared made libopcodes.so build
<jow_laptop>
kyak: ok good, anything to fix on the openwrt side?
<kyak>
jow_laptop: just a minute, i'm going to put together the --enable-shared and installation of libopcodes
<jow_laptop>
allright
<dvdk>
don't migrate to the jz4760 yet, the jz47xx_vid might need a complete rewrite (different IPU used, afaics) :)
<kyak>
dvdk: tested your driver for mplayer, it worked fine! However, the video was still very slow (no different from -vo sdl)
<kyak>
dvdk: and fbdev output always has these horizontal lines on top and bottom of screen.
<kyak>
i.e. i can see the console in background
<dvdk>
kyak: nice to hear it works
<dvdk>
about your complaints: just details easiy fix.
<dvdk>
s/easiy/easy to/
<dvdk>
kyak: when the scaler works we can use slightly smaller video and zoom up to full-screen.
<dvdk>
this should get us proper 30FPS video
<kyak>
slightly smaller, why?
<dvdk>
theora full-screen decode at 30FPS is too slow for me currently
<dvdk>
but 240x180 or something should work.  and scaling is practically for free
<kyak>
ah, ok
<dvdk>
maybe ffmpeg-theora is going to be fast enough, though
<kyak>
jow_laptop: apparently, installation of libbfd*.so is also necessary.. Otherwise binutils complain that it missing (guess it is due to --enable-shared)
<kyak>
jow_laptop: thanks a lot for your support :) moving on, jfbterm is the next failure
<kuribas>
Hi, if the nanonote processor supports USB 1.1 host, why doesn't the nanonote support it?
<dvdk>
kuribas: because nobody cared to implement it?  maybe no 5V USB bus-power available to create a host port?
<kuribas>
Implement in hardware you mean?
<wpwrak>
kuribas: the main obstacle is that the USB host signals are not "exported" from the chip (the chip is bonded directly to the board)
<kuribas>
I see.
<wpwrak>
kuribas: why that happened, i have no idea. maybe it was an oversight. maybe there were technical reasons.
<kuribas>
Host mode is something I would find very useful.
<wpwrak>
dvdk: and yes, you'd need 5 V, too. if you feel sneaky, you could just run a cable from USB device VBUS to USB host VBUS ;-)
<wpwrak>
kuribas: you're not alone ;-)
<kuribas>
I would like to connect a USB audio interface to the nanonote, and have a portable audio recorder!
<kuribas>
The zipit has a hack to make usb host mode possible.
<wpwrak>
kuribas: you could try to remove the black stuff that covers the chip and add your own bond wires. you may need a few bens before you get this right, but i'm sure wolfgang won't mind selling you a bunch of ten-packs or so :)
<kuribas>
No thanks...
<kuribas>
I wanted to make an open source recording solution (open hardware), but it shouldn't be hack.
<dvdk>
kuribas: people are working at adding hardware add-on cards to the Ben's micro-sd slot.  adding a A/D converter plus buffer might not be too dificult if you have some hw experience
<kuribas>
dvdk: Yeah, I am considering an external power supply.
<kuribas>
It would be for a professional audio applications.
<kuribas>
There are some nice atmel chips that support SD cards, high speed USB 2.0, FAT, SSC, LCD... Maybe it would be easier no make a simple linux recording device.
<kuribas>
Rather than trying to connect it...
<kuribas>
It would also reduce usb overhead.
<kyak>
jow_laptop: the next failure is kexec-tools (from openwrt base packages). The error is strange: ./configure: line 5923: syntax error: unexpected end of file. Since there is a newer kexec-tools in openwrt-trunk, and it builds fine (i just checked), could it be backported to backfire?
<kyak>
jow_laptop: i think it makes more sense then poking the older kexec-tools...
<dvdk>
kyak (jz47xx_vid is as slow as sdl): maybe you should redirect debug output to dev/null to speed it up a bit
<kyak>
xiangfu: hey :) could you please merge the latest backfire? It would fix kexec-tools compilation issue..
<xiangfu>
kyak: sure.
<xiangfu>
kyak: I will work on that tomorrow morning. now is 00:12 here. I don't want mess up the git. :)Â Â I am working on build the RTEMS crosschain. try to write a Makefile. automatic a little. :)
<kyak>
so it's basically what we were discussing the other day, UBB+hardware IC that implements UART?
<wpwrak>
yup
<kyak>
cool :)
<wpwrak>
i posted about it on the mailing list already one month ago (feb 6), subject "a bevy of boards"
<wpwrak>
nobody reads my walls of text. sneef :(
<kyak>
my bad, i'm reading the mailing list with "one eye"
<kyak>
as opposed to IRC
<kristianpaul>
i read it wpwrak
<kristianpaul>
but i'm not interested in uart for now
<wpwrak>
kristianpaul: ah, i have at least one true fan who follows my writings. thanks :-)
<wpwrak>
kristianpaul: (interested) also for me, the host interface is a lot more interesting than the actual uart ;-)
<wpwrak>
lfuse set to 0x60. and nxuart no longer responds. yes ! just as it should ;) now let's add that clock output ...
<rjeffries>
wpwrak I read every word, every slight nuance of your screeds on mail list and here
<wpwrak>
rjeffries: aha, that would make you a member of the secret police then :)
<rjeffries>
wpwrak what feedback if ANY DO YOU HAVE FROM EARLY USERS OF ATBEN ATusb ETC
<rjeffries>
WPWRAK YOU CAN RUN, BUT YOU CAN not HIDE. We are everywhere and nowhere.
<rjeffries>
sorry of caps lock
<rjeffries>
s/of/for
<wpwrak>
so far, i'm the only early user. there's one early carrier and one early storer, though, but i haven't heard from these yet. in fact, the less i hear from them, the better ;-)
<wpwrak>
rjeffries: for your .xmodmap: remove Lock    = Caps_Lock
<rjeffries>
what data transfer if any owrks between atben and atUSB?
<rjeffries>
s/owrks/works
<wpwrak>
(early carrier) i.e., fedex. now somewhere between memphis and anchorage. the early storer would be correo argentino, who apparently still have the parcel sitting in the post office, a few blocks away
<wpwrak>
i have some experimental communication programs, but nothing really useful
<rjeffries>
as a matter of suriosity what portions of communication stack do you have so far? I assume very minimal
<wpwrak>
of the "real" stack ? nothing
<wpwrak>
my tools are for design verification
<rjeffries>
fair enough
<rjeffries>
I m wondering what quantity wolfspraul may produce in first run of those two boards. likewise the uart 8:10 for Ben (which may be the bigger seller near term)
<wpwrak>
there are a few bits and pieces of an ieee 802.15.4 and ipv6 stack (6lowpan) that will be reusable
<wpwrak>
i don't think wolfgang plans to make any nxuart
<rjeffries>
oh really?  because?
<wpwrak>
for wpan, he mentioned something like 100 kits (atben plus atusb)
<wpwrak>
no use case
<rjeffries>
n=100 sounds about right or maybe 100 atBen and more atUSB
<rjeffries>
no use case? wtf??
<wpwrak>
but maybe tuxbrain is interested ? after the ubb success story, that would be a nice progression
<wpwrak>
or you could make them. have to find a less expensive pcb source, though :)
<rjeffries>
I gave up on that first outfit, and frankly do not wish to compete with Tuxbrain or tuxbrain_away
<wpwrak>
i doesn't have to be competition - it could be a complement
<rjeffries>
a less elegant way to get serial functionality would be a little pcb that uses UBB as connection to Ben, then a piece of flat ribbon cable to a small pcb
<rjeffries>
would heve more room that way
<wpwrak>
producing things takes time and some investment. everyone has only so much of each. so if wolfgang isn't interested and tuxbrain is busy, there would be no conflict if you picked up that production
<rjeffries>
one thing I do not understand (among many...) supposedly there are as many as 400 Ben NN owners in USA
<rjeffries>
I see ZERO feedback on the list or in irc from USA besides my own ranting and raving. makes me wonder wtf?
<rjeffries>
are all of those Bens "drawer computers" ???
<wpwrak>
(ubb to cable) kinda like the femtoduino. why not. there are many possible ways to approach this.
<rjeffries>
googles "femtoduino"
<wpwrak>
rjeffries: it may be a somewhat cultural thing. we also saw this in openmoko. about as many people in the us and in germany, but you saw comparably little activity from the ones in the us
<wpwrak>
heh, i'm so cool. clock output worked on the very first try ;-)
<wpwrak>
hmm. now i just have to figure out why ... :)
<rjeffries>
wpwrak the femtoduino guy tells me: I get all my PCBs from http://dorkbotpdx.org/wiki/pcb_order .. cheap, great quality, ROHS compliant and made in USA!\
<wpwrak>
rjeffries: yeah, no setup fee is great for prototypes. doesn't say if he can do 0.8 mm boards, though
<rjeffries>
I doubt he can handle the thinner PCBs. does atUSB require 0.8 mm? also if we have UBBs via tuxbrain, then attaching femtoduino via s short cable will be ok/fine
<rjeffries>
challenge if design stays as is will be how to attach ribbon cable to femtoduino I guess
<wpwrak>
atusb and atben are both 0.8 mm, yes. didn't want to introduce yet another variable.
<dvdk>
kyak: investigating the gforth build problem you reported.
<dvdk>
very strange new behaviour introduced by last openwrt changes
<dvdk>
after ./configure, somewhere before make, somebody calls ./config.status regenerating a file from .in that i previously patched
<dvdk>
solution is probably to patch the .in file instead
<xMff>
dvdk: the joy of autoconf ;)
<xMff>
dvdk: patching generated files is a no-go by now, I briefly looked at the gforth issue but couldn't figure it out
<dvdk>
loves autoconf/automake and would never complain and call it autocrap or autofail :)
<dvdk>
xMff: not patching per se, it justs overwrites it via echo from the configure rule.
<xMff>
dvdk: hm
<dvdk>
gforth is probably the most ugly makefile in openwrt-xburst.git
<dvdk>
but the upstream makefile isn't much better anyways :)
<dvdk>
btw just realizing that libtheora is compiled with -Os.  this may not be good for performance.
<xMff>
yeah, iirc it yeels about it too
<xMff>
*yells
<xMff>
but that -Os is from the global arch flags afaik
<xMff>
for the NN you could think about switching to -O2 in general
<xMff>
by supplying CONFIG_TARGET_OPTIMIZATION="..."
<dvdk>
xMff: i already override -Os to O2 for the gforth engine (which otherwise looses its dynamic code copying/generation capabilities)
<dvdk>
maybe we should patch libtheora Makefile only?
<dvdk>
-Os is otherwise certainly a good idea for most of the code, given the tiny cache and the slow TLB lookups of Xburst?
<xMff>
probably yes
<dvdk>
arggh, libtheora not part of openwrt-packages.git
<dvdk>
ok, gotta go
<dvdk>
cu
<xMff>
ciao
<kyak>
xMff: did you have a chance to look into flite's Makefile? Here's the version from xiangfu, slightly changed: http://dpaste.com/481700/. It uses the latest version of flite (1.4), alsa-lib and builds the static binary (i'm not sure libflite is used by someone)