<DocScrutinizer05>
may I guess? the driver is written so it works on different platforms and it finds out about fifo size of current platform by reading a register of musb-core IP block. Now when that register isn't existing on jz4740 then you probably need to get that info from elsewhere, worst case you need to hardcode it, according to what the datasheet/TRM says is the fifo size the musb-core is using per default
<DocScrutinizer05>
mere guessing, a shot into the dark
<wpwrak>
that's what it sounds like. but a bit of A/B testing should reveal such things. maybe not immediately, but apelete has been at this for weeks, so i'd imagine that pretty much every line of code has been surrounded by debugging printks by now ...
<larsc>
apelete: ram_bits is just something you need to specify in the config in your glue driver
jekhor has joined #qi-hardware
lekernel has joined #qi-hardware
wolfspraul has joined #qi-hardware
kilae has joined #qi-hardware
viric has joined #qi-hardware
viric has joined #qi-hardware
viric has quit [Changing host]
<viric>
i
<viric>
kyak: bad aur src for filegive...
unclouded has joined #qi-hardware
pcercueiS2 has joined #qi-hardware
pcercueiS2 has quit [Ping timeout: 264 seconds]
wej has quit [Ping timeout: 245 seconds]
wej has joined #qi-hardware
<apelete>
larsc: does ram_bits should be specified in glue driver or platform data ?
<apelete>
was thinking about reading the ram_bits register (raminfo actually) from within glue driver and store it in the musb driver structure
wej has quit [Ping timeout: 260 seconds]
<larsc>
is there a ram_bits register on the jz4740 core?
<apelete>
larsc: yes, there is a ram_bits field in the raminfo register
<wpwrak>
whitequark: bah, lame. direct thermal plasma printing would be so much more fun.
<larsc>
apelete: ah ok good
<larsc>
oh, there is even one that tells you about the number of eps
<apelete>
yeah, that's epinfo I guess. need to find out how to use these to setup endpoints with ep_config_fom_table()
<apelete>
the jz4740_udc driver hardcodes 4 endpoints, and that's what I specified in platform data but it does not help much at this point
<larsc>
it looks a bit as if the config is static
<larsc>
or the fifo config registers are just not documented
<larsc>
"/* NOTE: for RTL versions >= 1.400 EPINFO and RAMINFO would be better than static musb->config->num_eps and DYN_FIFO_SIZE */"
pcercueiS2 has joined #qi-hardware
pcercueiS2 has quit [Ping timeout: 265 seconds]
<DocScrutinizer05>
hello hw hackers! :-) I have a design problem I'd ask you to suggest solutions for. I hope you might help me out
<DocScrutinizer05>
on Neo900 we can't find 1GByte PoP-168pin LPDDR(1) chip to place on top of the DM3730 CPU. Either you know of any chip that would offer 1GB and is supposed work with DM3730 or alternatives like using DDR2 outside the specs, or a piggyback mini-PCB to solder 2 PoP chips a 512MB on top of the CPU. Or I'd need a suggestion how to attach *fast* storage to the system, to serve as swap (hint: flash is usually NOT fast, particularly on
<DocScrutinizer05>
writes).
<wpwrak>
using PoP means you just made sourcing about ten times harder. i guess the first question would be if you could put the RAM somewhere on the side or below the CPU
<DocScrutinizer05>
annoying detail: Nokia N9 *has* a 1GB PoP, but that's unobtainium and not from this world
<wpwrak>
if you need to move something else away to make room, maybe that could go on some daughterboard
<DocScrutinizer05>
wpwrak: alas that formfactor isn't available for OMAP3 SoCs
<wpwrak>
(unobtainium) yes, of course. we learned that sort of lessons at openmoko ;-) (not that we actually failed to get chips in the end. it was just a LOT harder than one may imagine)
<wpwrak>
maybe find a list where disgruntled ex-nokia or soon-to-be-ex-nokia hw folks hang out. and ask there ?
<DocScrutinizer05>
AM/DM37x - PoP and Discrete :: DRAM - PoP only. SDRC signals occur only on top balls
<wpwrak>
so yours is a CBC, not CBB
<DocScrutinizer05>
already did
<wpwrak>
could you source a CBB or CUS instead ?
<DocScrutinizer05>
wpwrak: we got 37xx
<wpwrak>
ok, CBO or CUS :)
<wpwrak>
s/CBO/CBP/
<qi-bot>
wpwrak meant: "ok, CBP or CUS :)"
<DocScrutinizer05>
ooh, CUS
<wpwrak>
yes, CUS. according to the table, CBP still would need PoP
<DocScrutinizer05>
yeah, I have to check if CUS is available, I simply didn't see (literally) this line
<DocScrutinizer05>
thanks a megaton
<wpwrak>
actually, i wonder if people would really buy PoP without memory. didn't the chinese number stations turn up anything ?
<DocScrutinizer05>
sometimes it just needs a second pair of eyes to look at some pretty clear info ;-D
<wpwrak>
hehe :)
<DocScrutinizer05>
PoP been an agony since 2 months now
<DocScrutinizer05>
literally nobody seems to have bothered to build 1GB 168p PoP
<wpwrak>
yeah, i've witnessed plenty of PoP hell at OM :)
<DocScrutinizer05>
except that mythical N9 chip
<wpwrak>
ah, that's where the swap idea comes from
<DocScrutinizer05>
yes
<wpwrak>
actually, if you have slow writes, that may still work: most applications are bursty, so you may be able to get away by simply keeping - on average - a large enough pool of spare pages
<wpwrak>
but then, swapping to flash sounds evil
<DocScrutinizer05>
grrr, now again back to CUS formfactor specs, digging up all the annoyinaces this comes with. I guess Nikolaus will kill me for asking him to route RAM as well on that gordian knot of traces under the SoC
<DocScrutinizer05>
(swap) Maemo already has swappiness=100
<DocScrutinizer05>
this doesn't help in the end
<DocScrutinizer05>
(evil) yes, that too
<wpwrak>
(swap) ah, pity. get people to write better code ;-) i still remember the days when 16 kB meant that you'd never have to worry about running out of memory ever again.
<wpwrak>
so, instead of Flash, maybe add a ROM BASIC ;-)
<larsc>
or SliverLight
<mth>
DocScrutinizer05: recent Linux kernels can swap to compressed memory (ZSWAP)
<DocScrutinizer05>
yes, I know
<DocScrutinizer05>
afaik it's already implemented in fremantle, at least with powerkernel
<mth>
it helped us on Dingoo A320 (32MB)
<mth>
but probably not a substitute for having enough RAM chips
<DocScrutinizer05>
yep
wej has joined #qi-hardware
<DocScrutinizer05>
Nikolaus said we basically can use CUS, but it has some interfaces missing compared to CBP
<DocScrutinizer05>
:-(
<DocScrutinizer05>
we have to check if we can get away with one UART, one McBSP and a few GPIOs missing
<DocScrutinizer05>
sounds nasty
<DocScrutinizer05>
the alternative (720MHz OMAP3530CBB) sounds like a regression even worse than 1GHz DM3730 with only 512MB RAM
<wpwrak>
just a few things missing doesn't sound too bad. making do with few resources than you need is part of the game ;-)
<DocScrutinizer05>
we'd lose all selling points of Neo900 basically
<DocScrutinizer05>
well, we planned for the UART3 (formerly "unused" on N900: console on testpoints) to become proper IrDA/CIR/console_over_SIR
<wpwrak>
and if you really just gpio-starved, you can always toss in a little helper mcu as io expander
<DocScrutinizer05>
GPIO are not my concern
<DocScrutinizer05>
McBSP and - to a lesser extent - UART are
<wpwrak>
everything else can be reduced to gpio ;-)
<DocScrutinizer05>
haha :-D
<DocScrutinizer05>
DAMN friggin PoP!
<DocScrutinizer05>
I seriously ponder if a piggyback PCB would be feasible
<wpwrak>
regarding PoP, heed the wise advice of nancy reagan, "just say no" :)
<wpwrak>
if you want an unending yield nightmare, then you're on the right track :)
<wpwrak>
in the old days, it used to be the japanese who were the world leaders in batshit crazy but admittedly very creative abuses of technology. now it seems that china is catching up there, too: http://www.youtube.com/watch?v=d3CWLCoQu7c
<DocScrutinizer05>
no, *I* am the king in this discipline ;-P
<wpwrak>
now we know what you need those extra interfaces for :)
<wpwrak>
hey, you just crossed 150. almost there !
<DocScrutinizer05>
well, I probably should've watched the video *before* answering ;-P
<DocScrutinizer05>
actually?
<DocScrutinizer05>
WOW
<DocScrutinizer05>
DUH 500
<DocScrutinizer05>
btw same old horseshit about patents on WCDMA calls, with royalties and whatnot. Luckily Nikolaus knows the Cinterion guys \o/
<DocScrutinizer05>
GOD! Please kill all patent trolls with fire from heaven
<DocScrutinizer05>
or like we use to say here "soll sie alle der blitz beim scheissen erschlagen!" ;-)
<wpwrak>
i'd opt for them getting arthritis and st vitus' dance at the same time
<DocScrutinizer05>
only if it's severe enough to stop them from pursuing their patent trolling
<DocScrutinizer05>
but then it's even better, yeah
<DocScrutinizer05>
and a long life to them then
<wpwrak>
that's the spirit (-:C
<larsc>
live forever but continue ageing as normal
<wpwrak>
after about 120 years, putrefaction inevitably sets in. so there'd be a zombie stage. after that, "life" would continue as a moving skeleton. with the right choice of clothing, nobody would have to notice
<DocScrutinizer05>
now going for soldering the domes to the PCB and placing a lightgiude plastic foil above it
<DocScrutinizer05>
guide*
<wpwrak>
are domes really soldered ? i thought they were generally glued
<DocScrutinizer05>
dunno, Nikolaus found some that aiui are soldered
<wpwrak>
i'd double-check that ;) the ones i found look at first sight as if they were for soldering ... but they aren't
<DocScrutinizer05>
makes sense when the "solderposts" move while pressing the switch
<wpwrak>
digi-key has some in a, as far as i remember, 5x7 mm grid. need fancy vias or solder mask, though. so not so easy for everything-DIY-ers like myself
<DocScrutinizer05>
lemme find the mail where Nikolaus told me about the Panasonic domes he found
<DocScrutinizer05>
can't spot it, but they are Panasonic and in a plastic frame where the dome can "move"
<DocScrutinizer05>
other problem: B2B connector similar to Hirose DF30FB-60DS-0.4V but with 64 pins. Anybody able to share any helpful info bit or pointer?
<DocScrutinizer05>
Location Function Component Family Component Type Qty Manufacturer Part Number Component Description Markings Form IO / Pin Count IO Pitch Diameter (mm) Length (mm) Width (mm) Height (mm)
<DocScrutinizer05>
Main PCB, Top Mechanical / Electro-Mechanical Electro-Mechanical Connector 1 Board to Board - Receptacle, Gold Plated Contacts 64 0.40 15.70 5.00 0.80
<DocScrutinizer05>
it's pretty unfortunate since the other end of this B2B is on a re-use component and this fixed
<wpwrak>
if all else fails, you could use two BM14C(0.8)-64DS-0.4V(51)-ND ;-)
<DocScrutinizer05>
I already tried to unsolder one of the 64p headers on the flex cable, but it's glued, so rework for 200 devices is most likely a PITA
<kyak>
viric: thanks, and i fixed the pkgbuild
<DocScrutinizer05>
wpwrak: I have ~5 B2B here to inspect them closely, and I think they look different than those panasonic
<viric>
thank you! I created all the misunderstanding :)
<DocScrutinizer05>
wpwrak: I dunno if the plug is a standard and only the build details differ to make them look like they are not matching
<kyak>
viric: i think you ping timeouted couple of days ago and missed my message (i don't display joins/parts/quits)
<DocScrutinizer05>
but since none of the manufs seems to specify any standard the connectors adhere to, I suspect it's "proprietary"
<viric>
ahh
<viric>
maybe
<viric>
I can't know
<kyak>
viric: and so i implemented temporary fix, which proved to be wrong :)
<viric>
what was wrong?
<wpwrak>
DocScrutinizer05: yeah, i think you need get a few that look similar enough and then just try if anything fits
<DocScrutinizer05>
Nokia is notorious to not publish ANY real part numbers of *anything*
<viric>
:) well seen
<viric>
noone noticed it. hehe
<kyak>
viric: if possible, you should get rid of the second version number in download url.. Also, you web server for some reason sends filegive-0.7.1.tar.gz?uuid=v0.7 file name, which is just not nice
<DocScrutinizer05>
wpwrak: however I wonder where from all those "second source" flex builders got theirs from - ok it's the M-part and we need the F-part for mainboard, but...
<viric>
kyak: although I got a column in a german magazine!
<DocScrutinizer05>
there must exist some secret knowledge inside China
<kyak>
viric: oh, it's interesting! what do you write about?
<viric>
kyak: no. Someone wrote about filegive, simply. Not me :)
<kyak>
ah, ok :)
<DocScrutinizer05>
viric: OOOOH!
<kyak>
viric: with recent news and such, filegive is an interesting thing..
<viric>
It's the bee's knees!
<viric>
I plan to add ngrok support, which should help poor people behind cgNAT
<viric>
(more integrated that what you can do manually though)
<viric>
DocScrutinizer05: ? do you know that magazine? I don't.
<DocScrutinizer05>
sure! :-D
<DocScrutinizer05>
it's THE european computer mag
<kyak>
Das Kommandozeilen-Tool Filegive veröffentlicht Dateien im Internet oder nimmt sie entgegen. Es erspart Umwege über Dienste wie Dropbox.
<viric>
ah :D
<DocScrutinizer05>
on same level like US Byte mag
<DocScrutinizer05>
Byte is a tad older
<viric>
I also don't know that
<kyak>
viric: have you already noticed increased downloads?
<viric>
hm I didn't check
<kyak>
be prepared :)
<viric>
214 downloads of the windows prebuilt
<DocScrutinizer05>
c't is sold in every gas station and every supermarket now
<viric>
vs zero of the previous month :)
<DocScrutinizer05>
I guess 10% of german population read it
<viric>
auhm
<kyak>
cool, so it increased infinite times :)
<viric>
:)
<viric>
but filegive uses nist curves. Not for the überparanoid
<wpwrak>
viric: better offer alternatives
<viric>
I should, rsa at least. next version.
<wpwrak>
and make sure it doesn't do things like switching to RC4, or silently dropping encryption altogether
<kyak>
first thing is to make sure your users downloaded what you actually uploaded (i mean the tarball)
<kyak>
maybe for some users this binary will be substituted by another one
<kyak>
(überparanoid)
<wpwrak>
DocScrutinizer05: you should measure the real connector (especially the plug side) with a caliper. then you'd have at least correct reference dimensions.
<wpwrak>
that doesn't tell you the width of the actual plug
<wpwrak>
ah, and it's the plug you need, not the receptacle
rz2k has joined #qi-hardware
<DocScrutinizer05>
the plug is 14.50mm
<DocScrutinizer05>
on my caliper
<DocScrutinizer05>
total outer dimension
<DocScrutinizer05>
we need the receptacle as shown on the scans I linked 4 above
<DocScrutinizer05>
the plug I just netered is on the flax cable and is fixed and given
<DocScrutinizer05>
metered*
<wpwrak>
you need the exact dimensions of the "oval" part that goes into the receptacle
<wpwrak>
i.e., "penis diameter", not "width of the hips"
<DocScrutinizer05>
14.50mm
<wpwrak>
14.50 mm x ?
<DocScrutinizer05>
which makes for 1,2mm for the "hips" on both sides of the F-part
<DocScrutinizer05>
which looks about right
<wpwrak>
you mean 2 * 0.6 mm "hips" (or walls) for the length
<wpwrak>
but you still don't have the width. the length is more or less give by the pitch, for the width there seem to be a lot of choices
<DocScrutinizer05>
yes
<DocScrutinizer05>
x 2.92mm (depending on how hard I squeeze the contact springs with caliper)
<DocScrutinizer05>
s/(depending on how hard I squeeze the contact springs with caliper)/(the springs are inside yet another "F" part of this "M" part)/
<qi-bot>
DocScrutinizer05 meant: "x 2.92mm ((the springs are inside yet another "F" part of this "M" part))"
<DocScrutinizer05>
so actually you could call the mainboard larger one the M part and the flex side one the M part
<DocScrutinizer05>
so actually you could call the mainboard larger one the M part and the flex side one the F part
<wpwrak>
oh, i see. then you should measure the cable side
<DocScrutinizer05>
basically the mainboard one works like a cinch plug
<DocScrutinizer05>
and the flec side like a cinch receptacle
<DocScrutinizer05>
the distance of those golden contacts is ~1.60mm (hard to probe)
<DocScrutinizer05>
also there actually the springs would move in when I apply force
<DocScrutinizer05>
(and out when I probed the 1.60mm on flex)
<wpwrak>
1.6 mm sounds about right. measuring in your high-res image, i got 1.56 mm (with a bit of guesswork, so 1.6 mm is well within error tolerances)
<DocScrutinizer05>
yes, absolutely
<DocScrutinizer05>
my 1.60 thend to err to the larger numbers
<DocScrutinizer05>
tend*
dos1 has joined #qi-hardware
<wpwrak>
hmm, nothing that looks similar on digi-key
<wpwrak>
you may have to go through the catalogs of hirose, molex, jae, panasonic, etc.
<DocScrutinizer05>
yeah
<DocScrutinizer05>
if only there were proper catalogs
<DocScrutinizer05>
I guess somewhere on this planet there must be a special shop that's only selling connectors and knows every damn connector existing. Only I not yet found that shop :-/
<DocScrutinizer05>
component sourcing, a never ending nightmare
<wpwrak>
or maybe there are tens of thousands of shops, each having bags full of connectors, and when you go there and bring your device, they will try until they find one that fits :)
<DocScrutinizer05>
no such shop in my town. wouldn't know any in Germany at large either
<DocScrutinizer05>
I probably should check out aliexpress.com if they got some wishlist function
<DocScrutinizer05>
this silly connector kills our project :-/
<wpwrak>
maybe make a drawing that clearly shows what it has to be like, then ask around
<wpwrak>
yeah, there are several places that have it. you just need to ask, no published prices, etc.
<DocScrutinizer05>
0.13..0.55$ good enough
<wpwrak>
ah yes, MOQ 100. perfect.
<DocScrutinizer05>
though often those companies can't ship what they advertise
<wpwrak>
or give you the "made in china" 100% compatible replacement :)
<DocScrutinizer05>
sophisticated form of spamming
<DocScrutinizer05>
I had one "Christine" nagging me for weeks trying to sell me DM3730 since she(?) learned it's this SoC we need the RAM chip I asked a quote for
<DocScrutinizer05>
of course they were not able to deliver the RAM chip I asked for, but they didn't stop pestering me with their friendly kind chinese mails
<DocScrutinizer05>
ignoring my answers that I'm not interested
<apelete>
hardcoded a musb fifo table corresponding to the 4 endpoints avaible on the udc chip, it seems to be read correctly by musb core
<apelete>
ram_bits data is read quick and dirty for now, I needed to know if it would work at all
<apelete>
now that it seems to work, will add a function to musb_regs.h to read from raminfo reg and update ram_bits field in the corresponding struct musb_hdrc_config properly