<nitin_gupta>
how much memory SD card can be supported by NN ?
<wpwrak>
kristianpaul, rafa: bbl from ben-blinkenlights ?
<wolfspraul>
wpwrak: I'm trying to standardize schematics values in the jtag-serial cable a little
<wolfspraul>
I'm not so sure though I get it all right :-)
<wpwrak>
lets see ...
<wpwrak>
you're using 47p but 4.7uF. gta02-core style would be 47p. i have to admit that i'm torn between the two myself. i tend to prefer the ...F variant. that's also i used in (all ?) my schematics on qi-hw.
<wpwrak>
and your multiplier for resistors is upper-cased, Kelvin instead of kilo :)
<nitin_gupta>
how much memory SD card can be supported by NN ?
<wpwrak>
would be nice if the filters had some sort of value/specification
<wpwrak>
nitin_gupta: i think linux is happy with a big a card as you can get, but the boot loader may start to exhibit problems if you want to boot from anything larger than ~4 GB
<wolfspraul>
wpwrak: I'm already on some of those things, following what I see in other projects of yours.
<wolfspraul>
to it's 27pF now, and 10kR
<wpwrak>
then, gta02-style would be 2k2 instead of 2.2k
<wolfspraul>
yes I know
<wpwrak>
ah, i find the 10kR a little ugly :)
<wolfspraul>
didn't you just write yourself that it should be like that?
<wpwrak>
for C and L. for R, I stick with the gta02-core style :)
<wolfspraul>
do the leds need a voltage?
<wolfspraul>
let's just settle on something for now, even if we change again later
<wolfspraul>
in CHARACTERISTICS, it says to always use R for Ohm
<wpwrak>
(leds) first, i would give them a color :) voltage can be nice to have, too, but it's not so critical
<wpwrak>
(CHAR...) i think that refers to the internal convention inside BOOM. there you also have dots, not 2k2 and such
<wolfspraul>
what should we do now in the schematics?
<wolfspraul>
10kR = ?
<wpwrak>
"internal convention" = what the .chr files have and what .sub eventually generates
<wpwrak>
just "10k" ?
<wolfspraul>
no R?
<wpwrak>
no R
<nitin_gupta>
that means I can extend the SD card upto 4GB only
<wolfspraul>
also for all other resistors, leave out the R?
<wpwrak>
except if you need it as a decimal point. 1R5 or such. (not the case here, i think)
<wolfspraul>
R2 is 2.2k
<wolfspraul>
so you would say 2k2?
<wpwrak>
nitin_gupta: if it has to be bootable now. if you can boot from NAND for now, then your SD can be as big as you wish
<wpwrak>
2k2, correct
<nitin_gupta>
well SD card will be used for storage only
<wpwrak>
then, gta02-core style would be to normalize things like 0.1uF -> 100nF
<nitin_gupta>
NAND will be used for booting NN
<wolfspraul>
wpwrak: I just did that (see my last commit)
<wpwrak>
nitin_gupta: then i don't know of any limit
<wolfspraul>
what additional values would be good to specify for the filters and the crystal?
<wolfspraul>
what is the default precision/tolerance for capacitors, resistors, if nothing is said (like 1% or so)
<nitin_gupta>
ok fine
<wpwrak>
resistors: 5%
<nitin_gupta>
how can I stop the GUI to pop up on booting NN
<wpwrak>
caps: something like 10% i think.
<wpwrak>
(one of my screens is still trying to turn on ... backlight is dying :-( )
<wolfspraul>
maybe we should specify a default in the boom documentation somewhere
<wpwrak>
the default is a convention you set in the .sub :)
<wolfspraul>
which values should typically be given in schematics, and what typical defaults would be
<wolfspraul>
yes sure, the system is good/flexible
<wolfspraul>
but a good 'default' can still help people
<wolfspraul>
I noticed a weird thing in eeschema - it just created the -cache.lib file at some point, and added it to the LIBS in the .sch file
<wpwrak>
in fact, with caps, a more common way of specifying their characteristics is to name the dielectric
<wolfspraul>
don't know what triggered the creation of the -cache.lib file
<wpwrak>
for example, X5R is a common choice
<wolfspraul>
it included copies of the components used in the schematics
<wolfspraul>
that's very annoying of course
<wpwrak>
yeah, it does that ...
<wolfspraul>
because now that -cache.lib file is linked from the .sch, and the .sch with the -cache.lib pointer will be committed
<wpwrak>
schhist will weed it out :)
<wolfspraul>
so either you always commit the -cache.lib with it, creating redundancy and confusion, or you need to manually rip it out before commits
<wpwrak>
not sure myself when it does this. did you add a library through the GUI ?
<wolfspraul>
at the very least a cache should be transparent and not have a pointer inserted to it in the .sch file
<wolfspraul>
oh no
<wolfspraul>
only fixing those values
<wpwrak>
hmm, odd. maybe some new "feature" then :)
<wolfspraul>
can you help me identify under-specified components in the schematics?
<wpwrak>
it hasn't done that to me lately. but then, your version is a bit newer than mine
<wolfspraul>
we already said: led color
<wolfspraul>
newer? I thought I have exactly your version now, bzr2448 + your patches
<wolfspraul>
what's missing for the filters and crystal?
<wpwrak>
(version) ah, okay. i just thought you had something newer
<wpwrak>
(filters) are they beads ?
<wpwrak>
or some other kind of filter ?
<wpwrak>
for the crystal, the capacitance could be nice. it's a bit of an annoyance parameter, though, because it's not something you design in but something that the component gives you. and you need to adjust the design for it.
<wpwrak>
so if you specify the capacitance, then you
<wpwrak>
're not saying "this should be XXX pF" but you're saying "the part I selected has XXX pF"
<wpwrak>
for the caps, it should be fun to see what happens with them as they are. without specifying anything else, BOOM is allowed to pick the cheapest crap it can find. i'm kinda curious what will turn up. it now has a fairly wide selection of capacitors ;-)
<wpwrak>
one problem with specifying dielectrics is that the technology changes over time. e.g., you now sometimes see X5R getting replaced with the better X7R.
<wpwrak>
so if you specify X5R, you may exclude some manufacturers or you may make BOOM pick a less common part. there's currently no mechanism for BOOM to automatically accept X7R as a replacement for X5R.
<wpwrak>
(with purely numeric values, you can do this. e.g., you could specify a tolerance of 5% it better, a voltage of 10V or more, etc.)
<wpwrak>
(X5R vs. X7R) it's not a big problem for now, but i think it may get worse with time
<wpwrak>
also, some of the smaller values are more common as NP0 then X5R. very small ones (just a few pF) only exist as NP0
<wpwrak>
so you have to be a bit careful not to over-specify
<wpwrak>
again, NP0 could replace X5R or X7R, but BOOM doesn't know this
<wpwrak>
not quite sure how to teach Boom such tricks. hmm, should i call is BOOM or Boom ? :)
<wolfspraul>
same to me. maybe I like Boom a bit better, in many cases I would lowercase it anyway
<wolfspraul>
I will follow whatever the official name is :-)
<wpwrak>
in the documentation, i carefully avoided calling it anything, but "BOM processor" or "BOM processing system" is a bit long :)
<wpwrak>
wolfspraul: btw, the 47nF/250V syntax is something the current .subs don't recognize. they look for a the value to just say 47nF and some other field to say 250V. supporting 47nF/250V is left as an exercise to the reader ;-)
<qbject>
zear: does your suggestion that I should play nethack-newt on jlime mean that you
<B_Lizzard>
larsc, are you interested in feedback, then?
<qbject>
're not going to bother making it go on OWrt?
<B_Lizzard>
I "ported" that, I can give you the source if you want
<B_Lizzard>
SDL is dynamically linked, but it should run on OpenWRT
<B_Lizzard>
hahaha, it beeps!
<B_Lizzard>
In any case, the screen colors are completely borked
<B_Lizzard>
I like the terminal beep, though.
<B_Lizzard>
Nice touch
<qbject>
B_Lizzard: I tried running the mipsel.ipk you posted in here a few days ago and got :Packages ... found, but incompatible with the architectures configured.
<B_Lizzard>
Maybe you can try extracting it without opkg
<B_Lizzard>
You know, the directory structrure
<rafa>
B_Lizzard: maybe CONFIG_SOUND=y is okey.. you can have the alsa drivers as modules after that.
<B_Lizzard>
Tell larsc
<B_Lizzard>
It doesn't matter to me.
<qbject>
B_Lizzard: what type of compression am I trying to unpack?
<B_Lizzard>
I think ipks are unpacked with ar
<qbject>
Thanks.
<B_Lizzard>
So, larsc, some things I noticed: No output on the screen other than the initial kernel messages. Not sure if that's normal. Some things under /sys do not exist, namely /sys/class/power_supply.
<B_Lizzard>
Checking out the screen color issue.
<B_Lizzard>
Well, that spi_3wires thing didn't fix the color issue.
<B_Lizzard>
I suspect you could add the whole CONFIG_SOUND thing too, in case we're counting.
<larsc>
B_Lizzard: for the color issue you need both the 3 wire patch and the display driver patch
<B_Lizzard>
Ah, sorry bout that
<larsc>
it's strange thought that power_supply is missing from /sys
<B_Lizzard>
Maybe I'm missing some patch or something
<B_Lizzard>
Is everything listed there an addition to mainline?
<B_Lizzard>
Cause some stuff says 5 months old and whatnot
<B_Lizzard>
I didn't add the gpio-charger thing, maybe that's what's wrong?
<B_Lizzard>
Sorry for all the hand-holding, I just don't want to apply stuff I don't need
<larsc>
well, you don't need every patch. but i would recommend them for a fully functional system
<B_Lizzard>
Ah, so even though the jz4740 UDC thing is over 5 months old it's not in?
<larsc>
the udc driver is in a bad shape. not ready for mainline merging
<B_Lizzard>
OK, so I'll add the cache quirks thing, the gpio-charger thing, the i2c thing and the dma thing
<larsc>
skip the dma and the i2c patches
<B_Lizzard>
OK
<kyak>
larsc: do you have an idea why "red arrow + BackSpace" don't act like "Delete" on Ben (as it should)?
<B_Lizzard>
You can fix that with xmodmap
<B_Lizzard>
Um, under X that is
<larsc>
kyak: i have no idea
<kyak>
i mean in terminal
<kyak>
well, ok...
<kyak>
i think, target/linux/xburst/patches-2.6.32/500-modifier-keys.patch, line 31, should be "+      altgr  keycode  14 = Remove"
<kyak>
this way it works
<larsc>
can you make a patch out of it and send it to the mailinglist?
<kyak>
i can commit to openwrt-xburst if it's ok with you
<larsc>
thats ok too
<kyak>
just going to re-build and run the final check...
<B_Lizzard>
larsc, last question, I swear :D
<B_Lizzard>
Would copying the relevant CONFIG_SOUND stuff from the 2.6.32 config work for 2.6.36?
<B_Lizzard>
Or were there driver changes/
<larsc>
i think the codec driver config symbol got renamed from JZCODEC TO JZ474_CODEC
<B_Lizzard>
OK
<B_Lizzard>
LCD fixed, thanks
<B_Lizzard>
No battery under power_supply though
<B_Lizzard>
I see a new entry, usb, though.
<larsc>
hm, for some reason i had "CONFIG_BATTERY_JZ4740 is not set" in the defconfig
<larsc>
i'll fix it
<B_Lizzard>
OK
<B_Lizzard>
Add the sound stuff too, if you can please
<B_Lizzard>
Else I can do it and give you a diff
<larsc>
i'll do it
<B_Lizzard>
You are a very helpful and kind person, thanks.
<larsc>
but it might take util tomorrow, i'm rather busy right now
<B_Lizzard>
Usually people just tell me to fuck off
<B_Lizzard>
No problem, thanks again.
<kyak>
larsc: what's the reason for build_dir/linux-xburst_qi_lb60/linux-2.6.32.16/drivers/char/defkeymap.c_shipped? i think it overwrites defkeymap.c instead of creating it from defkeymap.map
<kyak>
oh, i mean target/linux/xburst/files-2.6.32/drivers/char/defkeymap.c_shipped
<larsc>
kyak: iirc there is some makefile rule which generates defkeymap.c from defkeymap.c_shipped
<kyak>
these files are the same..
<kyak>
but ok, i will just modify defkeymap.c_shipped, too
<zear>
qbject, about me porting to owrt. Never got owrt toolchain to work properly. The fact it's divided into two different dirs makes the whole porting process complicated
<zear>
because you have to modify Makefiles, set custom lib/include pathes, etc
<zear>
i just gave up
<zear>
and as for jlime, nanonote is not the first device i use it on
<zear>
so i'm more familiar with it
<larsc>
kyak: yes. they are both the same because during the build defkeymap.c_shipped is copied to defkeymap.c. So if you modify defkeymap.c your change will be overwritten during the build process
<zear>
and just the fact they have a standalone toolchain i can just put on my hdd and use makes it more attractive
<larsc>
you should only modify defkeymap.c_shipped
<kyak>
larsc: i'll modify defkeymap.c_shipped and the 500-modifier-keys.patch (though the latter seems pointless, but this way it at least reflects the changes in defkeymap.c_shipped)
<qbject>
zear: thanks for filling me in. I can see why you'd choose that path.
<larsc>
kyak: hm, i think if 500-modifier-keys.patch does nothing put patching defkeymap.c it can be deleted
<kyak>
seems so..
<zear>
qbject, before i was just using dingux toolchain and statically linking the binaries against it
<zear>
so it was working in owrt
<zear>
but that wasn't too sane
<kyak>
i'd leave it though, it makes keymap more obvious, looking into C-file is not very helpfull
<zear>
qbject, well, current jlime toolchain is still somewhat buggy, as in, it does not work for me, but it works for rafa. I'd say it still has some pathes that point to his system if i didn't know him better. The thing is it works for him, it doesn't for me
<zear>
so i usually work on the port, and once it's done, i send him the code so he can compile it
<zear>
we've ported commander genius like that today
<kyak>
mirko: is it possible to push upstream vim/Makefile that has "--enable-multibyte" instead of "--disable-multibyte"?
<kyak>
mirko: this is the only way to make utf-8 work in vim, and it doesn't affect non-utf-8 users :)
<kyak>
also, i assume that those who want minimal vi, are satisfied with the one provided by busybox.. when they install vim-full they should expect multibye support
<qbject>
zear: why do you say that your static-linking method wasn't sane?
<qbject>
oops.
<larsc>
hm, is qi-hw.com down?
<Ornotermes>
larsc: works fine for me
<qbject>
larsc: fine here as well.
<larsc>
hm. something is wrong with my internet connection... this connection is still alive, but i can't seem to open new ones
<wpwrak>
larsc: NAT connection tracking table full ?
<larsc>
well, no idea. i've only got a e-mail client, webbrowser and an ssh connection open. but anyway, it seems to work again
<wpwrak>
/proc/sys/net/netfilter/nf_conntrack_count has the number of active entries, /proc/sys/net/netfilter/nf_conntrack_max the limit
<wpwrak>
if you don't have a donkey or torrent, and no neighbour borrowing your wifi, conntrack seems unlikely, though
<mirko>
kyak: should be, yeah
<mirko>
kyak: will take a look and ask the previous/initial committer
<rafa>
mirko: hey man, long time.. how is the life?
<kyak>
mirko: ok!
<mirko>
rafa: fine - was in holiday and good ill afterwards, so i got a bit busy with non-technical stuff :)
<rafa>
mirko: well... maybe you re charged batteries ;)
<mirko>
rafa: hope so :)
<rafa>
mirko: haha.. well, no a lot of changes on software side I guess, just a lot of nice work on kernel from lars, but no from main rootfs I would say. Well, you know better than me surely. So it is a great that you are around ;)
<kyak>
mirko: tested the patch with vim-full, works as expected!
<mirko>
hehe.. spend some time on buildroot changes, the picture frame - indeed there's still lot's of work to be done regarding the actual nn rootfs
<mirko>
kyak: great
<kyak>
mirko: should i test vim or it's good to commit?
<wolfspraul>
wpwrak: if the current design (mmone-jtag-serial-cable) uses a crystal with 12pF load capacitance, can I switch to one with 8pF ? or do I need to adjust some other values in the design too?
<wolfspraul>
I find crystals with 8 pF or 18 pF, but the only one with 12 pF is from EPSON and quite expensive
<wpwrak>
ingeneral, you should be able to do this. let's see what the ftdi data sheet has to say about it ...
<wpwrak>
c1 and c3 look a little suspicious for 12 pF
<wpwrak>
in general, higher capacitance means more stable but also more power-hungry. in this case, you probably prefer stability. so all other things being similar, 18 pF is better than 8 pF
<wpwrak>
for C1 and C3, i'd suggest to make them twice the crystal's value specified for the load capacitance
<wpwrak>
(round to the nearest E12 value, slightly favouring rounding down over rounding up)
<wpwrak>
2 * 18 pF = 36 pF may not be a common value. so 33 pF then
<wpwrak>
if you pick XTAL = 8 pF, that would be 15 pF for the caps
<wolfspraul>
Yanjun Luo gave me a formula (was just looking it up), but I have no idea how to apply it :-) (cl=cg*cd/(cg+cd)+a)
<wolfspraul>
so if I adjust C1 and C3 in the way you describe, I can pick any any load capacitance for the crystal?
<wolfspraul>
what are the different variables in the formula? cl, cg, cd and a
<wpwrak>
good question :) only C_L is more or less a "standard" name (using TeX syntax here)
<wolfspraul>
wpwrak: how do you feel about the BOOKSHELF file? (looking at the one in ben-wpan)
<wpwrak>
hmm, good in general :)
<wolfspraul>
he
<wolfspraul>
with that kind of confidence, already from the author, I doubt the success story will go very far ;-)
<kristianpaul>
lol :)
<wolfspraul>
seems there are three fields, N: A: D:
<wolfspraul>
what are the aliases (A:) used for?
<wolfspraul>
it the idea that the N: field should match the bom reference in the kicad schematics?
<wpwrak>
N is the "main" name of the data sheet. A are convenience names. e.g., N could be the application note (AN1234) and A could be what it is, e.g., mcu (not necessarily a great name, but ...)
<wpwrak>
the comonent link is in components/INFO :)
<wpwrak>
comPonent
<wolfspraul>
hmm
<wolfspraul>
can you tell us a bit more about components/INFO :-)
<wolfspraul>
there's another 3 fields there, S:, M:, N:
<wpwrak>
yup. S is the symbol name, as used in eeschema
<wolfspraul>
is that the same as the 'reference' in the bom .lst eeschema generates?
<wpwrak>
N links to the data sheet. if S already has the right name, you don't need N
<wpwrak>
hmm no, the only reference eeschema generates is Rxxx, Uxxx, etc. and the footprint. but that's modules/*
<wolfspraul>
hmm, yes. just realized :-)
<wolfspraul>
so how can you link the bom to the datasheets?
<wolfspraul>
not at all I guess. good thing KiCad files are text format...
<wpwrak>
you'd have to go search for the link in the .sch file(s)
<wpwrak>
or you link via the component that's selected at the end. eventually, we should have a link manufacturer-part/orderable-part -> data sheet as well
<wpwrak>
but that doesn't exist yet
<wolfspraul>
hmm
<wolfspraul>
true actually, the datasheet is for an orderable part, not for something that is only spec'd in the schematics
<wolfspraul>
but then components/INFO is even in the wrong folder, it should be in bom/
<wolfspraul>
you need another extension in boom, .dsl data sheet links
<wolfspraul>
#DSL
<wolfspraul>
namespace part-number url
<wpwrak>
naw, many parts have a unique schematic symbol. that's what components/INFO is about
<wpwrak>
yeah, something like this :)
<wolfspraul>
but that symbol, no matter how unique it is, has to be mapped to an orderable part at some point, via .sub etc.
<wolfspraul>
so components/INFO looks a little parallel/redundant to boom
<wolfspraul>
it establishes a relationship between schematic symbol and manufacturer part-number / datasheet
<wpwrak>
ther emay be some redundancy, yes
<wpwrak>
components/INFO basically tells you what information to use for the design
<wpwrak>
at that time you don't have to know any orderable part
<wolfspraul>
you are jumping ahead, making assumptions about a specific manufacturer's part-number that may not even be orderable
<wolfspraul>
so either your design is actually tied to that manufacturer's part number, or you shouldn't be making those assumptions
<wpwrak>
well, for many parts this is the case. e.g., you pick the jz4720 even if you don't know yet where you'll buy it
<wolfspraul>
of course. so the design is tied to that manufacturer/part-number.
<wolfspraul>
if you cannot get that part anymore, you cannot manufacture the design.
<wpwrak>
you may also skip the task of making the link at the BOM end if it's too messy. e.g., if you'd have to find and link the data sheet manually.
<wpwrak>
correct
<wpwrak>
or some equivalent part. but for that, you also need to compare with the original spec.
<wolfspraul>
I think what components/INFO is doing right now should just be another extension in boom
<wpwrak>
it all depends on what sort of part you have.
<wolfspraul>
and dsv could parse from there
<wolfspraul>
BOOKSHELF could be merged in there as well
<wpwrak>
dunno. i don't want to overload boom. there are some integrity checks that could exist outside all this.
<wolfspraul>
there's a bit too many names for my taste in BOOKSHELF and components/INFO (S: M: N: A:)
<wpwrak>
the aliases for the things you can remember :)
<wpwrak>
s/for/are/
<wolfspraul>
can BOOKSHELF and components/INFO be merged?
<wpwrak>
not cleanly. there's stuff in BOOKSHELF that doesn't have a symbol. there are symbols that don't have a data sheet. also, footprints can point to data sheets.
<wolfspraul>
you could use KiCad user fields for the data that is currently in components/INFO
<wolfspraul>
who uses components/INFO?
<wpwrak>
the INFO files are currently just accessed manually
<wolfspraul>
it seems to me that the comment lines in components/INFO actually carry a lot of information too
<wpwrak>
yes, i could hide a great many things in kicad. but why ? :)
<wpwrak>
indeed, the comments are useful :)
<wpwrak>
there's a lot of stuff that doesn't have a "nice" place to go
<wolfspraul>
no reason, I just ping your brain to understand design decisions
<wolfspraul>
of course the text file is much easier to edit
<wpwrak>
yup
<wpwrak>
and you can read it easily, too
<wolfspraul>
but sometimes systems can be over-engineered, and cause more harm than good
<wpwrak>
that's why i keep things nicely separated :)
<wolfspraul>
I keep this big 'free hardware design style guide' in my mind
<wolfspraul>
we need to be able to describe how it all fits together, one day
<wolfspraul>
so nobody uses the fact that the S: field in components/INFO matches the KiCad schematics symbols?
<wolfspraul>
and if you edit the schematics symbol, you have to edit components/INFO manually to keep them in sync?
<wolfspraul>
does anybody use the 'package marking' M: field?
<wolfspraul>
or the connection to the data sheet name N: ?
<wpwrak>
as i said, these files are currently only for manual use. i look at them from time to time :)
<wpwrak>
if you rename the symbol, you need to edit INFO as well, correct
<wpwrak>
i haven't bothered to maintain the package markings so far. i should, though. things can get confusing.
<wolfspraul>
what do you mean with package marking?
<wpwrak>
the stuff that's printed on the package. e.g., SOTxxx components can have something cryptic like MJ5
<wpwrak>
and then you need to decode this to the real part number, which can be totally different. XP1021, for example
<wolfspraul>
hmm
<wolfspraul>
what is the plan there? you mean write down any text/characters you see on the component?
<wolfspraul>
or focus on some specific meaning, like datecode? (I don't think there is a datecode formatting standard, unfortunately)
<wolfspraul>
and why would you want to write this down? (into components/INFO) - when are you using it and for what reason?
<wpwrak>
i would write down characters found in the data sheet
<wpwrak>
the idea is to be able to identify items quickly. you may have many with identical or similar packages.
<wolfspraul>
you mean you look at an image in the datasheet, and what is written on the chip there?
<wolfspraul>
do most datasheets have such a 'marking symbol' documented?
<wolfspraul>
it means something that is printed (visible) on the actual component, right?
<wolfspraul>
so it helps when you are dealing with the actual physical components in front of you, say you are fixing or manually mounting something, correct?
<wpwrak>
they usually do, yes
<wpwrak>
correct. it's laser-printed on the component.
<wpwrak>
and yes, it's for finding/identifying a real comonent
<wolfspraul>
so you open components/INFO, and you have that one piece of information extracted there, so you don't have to go through datasheets...
<wolfspraul>
ok I got it
<kristianpaul>
wpwrak: do you remener if TP24 is avaliable for use
<wolfspraul>
ok I think I'm clear on BOOKSHELF and components/INFO now, thank you!
<kristianpaul>
?
<wolfspraul>
he, speaking about testpoints, could components/INFO also have entries for testpoints? just to document what they are hooked up to?
<kristianpaul>
i have in my texpad like free TP35,36,25,75
<kristianpaul>
text*
<kristianpaul>
but i soldered TP24 too lol
<wpwrak>
(tps) naw, put them elsewhere ;-) components/INFO describes components in general, unrelated to specific projects
<kristianpaul>
just because was next TP25, but i dont see in the schmatics..
<wpwrak>
kristianpaul: so your question is "what does TP24 do ?" ? :)
<kristianpaul>
wpwrak: right
<kristianpaul>
i have my 4 gpio for the GPS EVB board but one pin more is wellcome just i case
<kristianpaul>
actually atena signal detection may be a candidate
<kristianpaul>
i really complain kicad psd are not searchable..
<kristianpaul>
s/psd/exported data as pdf
<wpwrak>
TP24 is an audio enable signal. POP. page 6
<wpwrak>
yeah, non-searchable pdf sucks :-(
<kristianpaul>
hmm better no touch
<kristianpaul>
thanks wpwrak
<kristianpaul>
juan64bits: hey dude :)
<juan64bits>
tell me :)
<wolfspraul>
wpwrak: oh. components/INFO is not meant to be project specific?
<wolfspraul>
well that's an important piece of information. I would have thought it is.
<kristianpaul>
juan64bits: just to save me some diff reading, wha u did in UNAL with SIE uboot?
<kristianpaul>
you also get support for uSD and i2c in linux?
<wolfspraul>
in ben-wpan, it says for the antenna "Generic antenna with ground on pin 1, feed on pin 2". Isn't that project specific?
<wolfspraul>
for the crystal, it says "Fairly generic crystal package with 4 pins (crystal connects pins 1 and 3, the rest is ground"
<juan64bits>
in uboot, only uSD
<kristianpaul>
and you verifed you can boot by uSD too?