DocScrutinizer05 changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
arielenter has quit [Ping timeout: 264 seconds]
dos1 has quit [Ping timeout: 246 seconds]
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #qi-hardware
jurting_ has quit [Ping timeout: 260 seconds]
viric has quit [Ping timeout: 240 seconds]
viric has joined #qi-hardware
arielenter has joined #qi-hardware
arielenter has quit [Quit: Leaving.]
pcercuei_ has quit [Quit: dodo]
<wpwrak> nicksydney: and, is it time for the Victory Gin yet ?
<nicksydney> wpwrak: nah....will go back and fight with it tongih
xiangfu_ has quit [Ping timeout: 245 seconds]
<nicksydney> wpwrak: another good news i got ...someone from local hackerspace is going to give me 1 of those blue peel paper..so going to pick it up either tonight or tomorrow
xiangfu has joined #qi-hardware
xiangfu has quit [Ping timeout: 240 seconds]
xiangfu has joined #qi-hardware
<wpwrak> great ! that that's one variable less to worry about
ffio has quit [Ping timeout: 246 seconds]
ffio has joined #qi-hardware
wej has quit [Ping timeout: 252 seconds]
<nicksydney> wpwrak, DocScrutinizer05 : i'm sure you have heard about this https://github.com/Kwamecorp/Fairphone ?
<DocScrutinizer05> yep
<nicksydney> DocScrutinizer05: what are your thoughts ?
<DocScrutinizer05> much hype about nithing. The phone itself is basically a hoax, the ideology and the pushing they do on political layer is great
<DocScrutinizer05> fairphone can't use fairer chips than e.g Neo900 does
<DocScrutinizer05> they offer repair instructions and spare parts. OK so do we
<DocScrutinizer05> They claim they got "fair Coltan" but how do they make chip manufacturers use that fair rare earths they claim to have sources?
<DocScrutinizer05> they maybe use recycled plastic for their new case. We recycle the case ;-D
<DocScrutinizer05> they don't manufacture in FoxCon China. We manufacture in Bavaria
<nicksydney> :)....fair argument.....when it comes to business in China..anything to please the customer they will do even though they don't do it at the back room :)
<wpwrak> i think they're not trying to be "fair" on the rare earths. there's only about three things where they actually selected a "fair" supplier.
<nicksydney> will be interesting if MediaTek is willing to release the source to them and thus to the public
<DocScrutinizer05> haha
<wpwrak> sourced of what ?
<nicksydney> kernel
<wpwrak> okay, more likely than other sources :)
<nicksydney> they won't release the video or graphic :)
<nicksydney> it's set in stone
<DocScrutinizer05> I think it's a featurephone with a nice DSDS MTK chipset that also runs the complete GUI. Not checked, just guess
<wpwrak> naw, it's a smartphone
<wpwrak> "Fairphone | A seriously cool smartphone. Putting social values first."
<nicksydney> DocScrutinizer05: stupid question....neo900 could run Android for that matter right since you will have all the different drivers ?
* nicksydney duck behind desk because talking about Android in a non-Android channel :)
<DocScrutinizer05> I think the replicant project will pick up on Neo900 as soon as they get their hands on it. AIUI they already ported replicant to GTA04
<DocScrutinizer05> see neo900.org
<wpwrak> how the component hunt going by the way ?
<DocScrutinizer05> http://neo900.org/#about >>Most importantly, the Neo900 is an open platform, carrying on in the tradition of the Openmoko project. Neo900 will support all operating systems available for GTA04 (QtMoko, SHR, Debian, Replicant, ...)...<<
<nicksydney> DM3730 is the same used in BeagleBoard
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #qi-hardware
<nicksydney> "price of motherboard w/o case expected to be in the 500-700 EUR range" --> wow.... I'm out of cash :( ... maybe one day
<DocScrutinizer05> chicken/egg problem: low quantities to build cause low qty of components to source and high fraction of fixed costs per device thus causing high price/unit. High price per unit -> low number of customers, thus low qty of devices to build
<nicksydney> economy of scale in play
<nicksydney> :)
<DocScrutinizer05> and you know about the margins that players like Samsung and even Apple are making their money from?
<DocScrutinizer05> we CANNOT compete with them, not even same league
<nicksydney> DocScrutinizer05: true...wonder if can create the pcb with my toner transfer :)
<DocScrutinizer05> we can't get the components for the amount they ask for a complete unit to sell
<nicksydney> wpwrak: i can't even get anelok to toner transfer properly and now i'm thinking of toner transferring neo9000.......now that's ambitious :)
<wpwrak> the likes of us are happy enough if we can get all the components ...
<DocScrutinizer05> heck we are happy when we can get the components at all that they simply get built to order for their product
<wpwrak> great minds things alike :)
<wpwrak> s/things/think/
<qi-bot> wpwrak meant: "great minds think alike :)"
<nicksydney> DocScrutinizer05: how you solder the BGA chip ?
<DocScrutinizer05> vapor phase
<wpwrak> nicksydney: yeah, toner-transferring a 6 (?) layer board would be a bit of a challenge ;-)
<nicksydney> DocScrutinizer05: it's hard enough soldering smd component can't imagine BGA
<nicksydney> wpwrak: crap...it's 6 layers ? ...damn !
<DocScrutinizer05> you can't solder the modem any other way
<nicksydney> DocScrutinizer05: vapor phase ? now that's something i need to learn from you oh great jedi :)
<DocScrutinizer05> Neo900? is 8 layer at least
<DocScrutinizer05> iirc
<nicksydney> 1 layer is hard enough for me :)
<DocScrutinizer05> nicksydney: it's really nice - just use a pot with a boiling liquid that has a boiling temperature of 235°C
<DocScrutinizer05> then dump the PCB with components into the vapor
<nicksydney> doesn't the liquid vapor interfere with the solder ?
<DocScrutinizer05> simple theory, expensive and complicated to do in real life
<nicksydney> i meant with the solder paste
<DocScrutinizer05> no, it's a special hydrocarbon-halogenide afaik
<DocScrutinizer05> it even serves as inert gas, so no need to flood the reflow oven with nitrogen
<DocScrutinizer05> reflow temperature profiles are a major problem with vapor phase
<DocScrutinizer05> you know, the whole process doesn't like too steep temperature gradients
<DocScrutinizer05> and of course you don't want to make that expensive reflow-liquid evaporate into the air all the time, so the actual "machine" is quite complicated compared to e.g. ar "simple" IR radiation reflow line
<DocScrutinizer05> IR & hot air
<nicksydney> sounds like not an easy setup
<DocScrutinizer05> funny detail: the liquid is also used as blood-substitute
<DocScrutinizer05> yeah, it#s not exactly easy. So we let solder ;-)
<DocScrutinizer05> there are companies that do nothing but vapor phase soldering the whole day long
<DocScrutinizer05> ;-)
<nicksydney> thanks...will read that
<DocScrutinizer05> actually I think VP and particularly SVP is the smartest thing since sliced bread
wej has joined #qi-hardware
lekernel has joined #qi-hardware
jekhor has joined #qi-hardware
<larsc_> apelete: I think jz4740_musb_set_vbus() tries to do too much
<DocScrutinizer05> no surprise
<DocScrutinizer05> *_set_vbus() is pretty specific for the particular circuit/platform
<DocScrutinizer05> and I don't know if ben can do it at all
<larsc_> apelete: what am I missing? Why are things working even tough we do not provide a musb_hdrc_config?
<larsc_> DocScrutinizer05: since we only have gadget mode the function will only ever be called with vbus_enable = false
<larsc_> so there is actually nothing to do in there
<apelete> larsc_: musb_hdrc_config is provided in platform.c, that's why I didn't thought at first about writing the fix the way balbi suggested
<larsc_> ah, ok
<apelete> larsc_: I was also thinking about the usefulness of jz4740_musb_set_vbus(), not sure if we actually need it
<larsc_> I'm going to make a couple of minor changes to the driver if that is ok with you
<apelete> sure, no problem.
<apelete> larsc_: was going to define musb_hdrc_config in glue layer code to add a quirk flag as balbi advised, but you'll certainly come up with a better way to fix this
<DocScrutinizer05> larsc_: right
<DocScrutinizer05> larsc_: anyway I wonder how upstream gonna handle the extreme platform dependency in *_set_vbus(). I don't see how to implement that in a platform-agnostic way, not even with the most evolved devicetree you could think of
porchao has quit [Quit: Leaving...]
porchao has joined #qi-hardware
ffio has quit [Quit: WeeChat 0.4.1]
<lekernel> whitequark, http://irclog.whitequark.org/ is 502 Bad Gateway
<whitequark> uh oh
<whitequark> lekernel: fixed. unattended-upgrades decided to upgrade mysql, and irclogger doesn't like when "server goes away"
<whitequark> thankfully the logger bot is protected from that
<larsc_> apelete: do you have a datasheet for a device with a full blown musb controller?
<larsc_> DocScrutinizer05: your nova thor thingy also has a musb controller
<apelete> larsc_: only have jz4740 datasheet, why ?
<larsc_> I want to lookup the meaning of the devctrl bits
<larsc_> there are a couple of other places where it is read
<larsc_> and I think we should fake the value as it would look like if the device is in gadget mode
<DocScrutinizer05> MY nova thor thingy?? :-o
<DocScrutinizer05> I know what's in (Nova)Thor, I had the pleasure to debug the sources
jekhor has quit [Ping timeout: 248 seconds]
<apelete> larsc_: tried something like that yesterday night, that's why I was thinking about modifying musb_regs.h: didn't find any reg in jz4740 that might be read as devctl
<apelete> but maybe I overlooked something then :-/
<DocScrutinizer05> the closed sources, I may add
<larsc_> apelete: we should not have any #ifdef CONFIG_JZ4740 anywhere
<larsc_> that's really bad style
<larsc_> DocScrutinizer05: 'your's' because you worked with it
rz2k has joined #qi-hardware
<apelete> larsc_: agreed, #ifdef makes the code hard to maintain, just didn't think about using platform_data at first
<apelete> anyway, I want to add the quirk flag by using "board_data" member of struct musb_hdrc_platform_data -> http://lxr.free-electrons.com/source/include/linux/usb/musb.h#L98
<apelete> but I can't firgure out how to access the member from within the musb_gadget.c code
<apelete> larsc_: any idea ?
pcercuei has joined #qi-hardware
<qi-bot> [commit] Lars-Peter Clausen: usb: musb-jz4740: Don't manually free device managed resources (jz-3.12) http://qi-hw.com/p/qi-kernel/ee7dcba
<qi-bot> [commit] Lars-Peter Clausen: usb: musb-jz4740: Move musb_hdrc_config to the glue driver (jz-3.12) http://qi-hw.com/p/qi-kernel/65b33a2
<qi-bot> [commit] Lars-Peter Clausen: usb: musb-jz4740: Move jz4740 specific fifo config to the jz4740 glue (jz-3.12) http://qi-hw.com/p/qi-kernel/8187ff7
<qi-bot> [commit] Lars-Peter Clausen: usb: musb-jz4740: Mask host mode only IRQ bits (jz-3.12) http://qi-hw.com/p/qi-kernel/fbeaeeb
<qi-bot> [commit] Lars-Peter Clausen: usb: musb-jz4740: Remove set_vbus callback (jz-3.12) http://qi-hw.com/p/qi-kernel/af3548b
<larsc_> apelete: so the gadget itself has this is_otg flag
<larsc_> which is currently always set to 1
<larsc_> I think we should set that to either 1 or 0 depending on the config
<larsc_> and then use the is_otg flag to check whether we should access the devctl register
<apelete> larsc_: you mean fix musb_gadget.c to access devctl depending on is_otg flag ?
<apelete> (rephrasing it just to be sure I get it correctly, hope you don't mind)
<larsc_> yes
<larsc_> more or less
<apelete> okay great, will do that on top of the changes you just pushed and submit the patches again
<apelete> larsc_: thanks for cleaning up the code, looks much better with everything isolated from the musb driver code
<larsc_> hm, just for fun enabled dma, seems to work
<apelete> wow
<larsc_> just netcat'ed /dev/zero and I get 1MB/s at 50% cpu usage
<larsc_> is this good or bad?
<pcercuei> that's rather high
<larsc_> lets see how much I can get in pio mode
DocScrutinizer05 has quit [Quit: Konversation terminated!]
<larsc_> the same actually
DocScrutinizer05 has joined #qi-hardware
wej has quit [Ping timeout: 245 seconds]
<apelete> no improvement using dma then ?
<larsc_> it is probably not using dma
wej has joined #qi-hardware
<larsc_> ah "musb-hdrc musb-hdrc.0.auto: No DMA interrupt line"
<larsc_> the problem though is that the controller uses the same IRQ line for both
<pcercuei> both what?
<larsc_> dma and controller
<larsc_> even with that fixed still no dma
porchaso0 has joined #qi-hardware
<larsc_> the driver never seems to call usb_gadget_map_request
porchao has quit [Ping timeout: 245 seconds]
jekhor has joined #qi-hardware
<larsc_> hm, it's trying to do dma, but the buffers are all unaligend ...
<larsc_> argh...
<larsc_> skb_reserve(skb, NET_IP_ALIGN);
<larsc_> and IP_ALIGN is 2
wolfspraul has quit [Ping timeout: 260 seconds]
wolfspraul has joined #qi-hardware
<larsc_> so with dma cpu usage is down to almost idle, while I still get 1MB/s
<larsc_> hm or maybe not
<wpwrak> 1 MB/s for high-speed device ?
valhalla has quit [Ping timeout: 260 seconds]
<larsc_> I guess
<larsc_> the problem really is that the dma address has to be 32bit aligned
<larsc_> this does not mix well with networking
<pcercuei> larsc_, I have a crash on jz-3.12: http://pastebin.com/W5GBmAwX
<pcercuei> but I get spammed with this so I can't see the kernel panic info
<larsc_> enable CONFIG_KALLSYMS
<wpwrak> larsc_: you should still be able to at least speed up inbound.
ffio has joined #qi-hardware
<pcercuei> allright
<larsc_> wpwrak: that NET_IP_ALIGN is on the receive path
<pcercuei> here's with CONFIG_KALLSYMS enabled: http://pastebin.com/BH6nANJe
<pcercuei> this time I did save the whole log so I have the beginning of the crash log too
<wpwrak> larsc_: well, the choice would depend on what is worse: PIO or copying. right ?
valhalla has joined #qi-hardware
<larsc_> pcercuei: looks like a problem with your input driver
<larsc_> wpwrak: well pio is copying
<larsc_> the buffers are quite large I think
<larsc_> and the bus is not that slow
<pcercuei> larsc_, not really "my" input driver, the driver is gpio-keys, present in mainline Linux for ages
<wpwrak> PIO is copying but different from DMA + memcpy. maybe better, maybe worse. i no idea which :)
<pcercuei> I did report it on the mailing list
<larsc_> wpwrak: I'd assume there is not much difference on the jz4740 between the two
<larsc_> pcercuei: the report was not very complete
<larsc_> I mean the snippet you posted doesn't even compile
<pcercuei> of course it doesn't compile, it's an example
<pcercuei> also, it's kinda hard to include a crash trace when you don't have a serial line :/
<pcercuei> thanksfully I could reproduce it on a device that has one
<larsc_> the bug looks like a NULL pointer deref though
<larsc_> its not clear where though
ffio has quit [Quit: WeeChat 0.4.1]
Mistah_Darcy_ has joined #qi-hardware
Mistah_Darcy has quit [Ping timeout: 260 seconds]
Mistah_Darcy_ has quit [Read error: Connection reset by peer]
Mistah_Darcy_ has joined #qi-hardware
arielenter has joined #qi-hardware
wej_ has joined #qi-hardware
wej has quit [Ping timeout: 260 seconds]
panda|w530 has quit [Ping timeout: 260 seconds]
dos1 has joined #qi-hardware
ffio has joined #qi-hardware
panda|w530 has joined #qi-hardware
dandon_ has joined #qi-hardware
dandon has quit [Ping timeout: 260 seconds]
dandon_ is now known as dandon
arielenter has quit [Quit: Leaving.]
arielenter has joined #qi-hardware
wej_ has quit [Ping timeout: 252 seconds]
wej has joined #qi-hardware
ffio has quit [Read error: Connection reset by peer]
_whitelogger has joined #qi-hardware
rz2k has quit []
<nicksydney> morning all
<nicksydney> wpwrak: what's new >
<wpwrak> surprisingly little. even more surprisingly, i still have power, unlike about half of the rest of the city.
<nicksydney> wpwrak: is there a strike or something in power plant ?
mirko_ has quit [Quit: leaving]
mirko has joined #qi-hardware
mirko_ has joined #qi-hardware
<wpwrak> "something". like a decade of not investing into the infrastructure. and then something completely unexpected happens. a rare meteorological phenomeneon called "summer"
mirko_ has quit [Client Quit]
mirko has quit [Client Quit]
mirko has joined #qi-hardware
mirko has quit [Client Quit]
mirko has joined #qi-hardware
odsvirov has joined #qi-hardware
<wpwrak> nickoe: maybe we should take this here ?
<wpwrak> nickoe: e.g., the scripting that depends on eeschema i can recall without looking is schhist and the schematics symbol catalog of kicad-libs
<nickoe> wpwrak: yes, I understand, and that I guess, is because the pcb is what specefies more or less everything we are interrested in exporting to other formats
<nickoe> wpwrak: but the schhist is a nice thing for sometimes
<wpwrak> nickoe: while pcbnew is in: printing the layout for toner transfer, cnc-milling boards, "photo-realistic" layout preview, component positions for CAD and case
<wpwrak> maybe we could still open schematics made with today's kicad with an older eeschema, one that has the command-line patches ?
<wpwrak> pcbnew has changed a lot, especially when it comes to the file format, but i think eeschema is pretty much the same (so far)
odsvirov has quit [Ping timeout: 248 seconds]
<nickoe> sounds possible for some time in to the future yes
arielenter has quit [Ping timeout: 264 seconds]
arielenter has joined #qi-hardware
<qi-bot> [commit] Apelete Seketeli: usb: musb_gadget: use is_otg flag to set gadget peripheral mode on reset (jz-3.12) http://qi-hw.com/p/qi-kernel/f715ea4
<apelete> larsc_: fix is working thanks to this previous one:
<apelete> larsc_: what do you think about it ? (tested already, I'm squashing all the commits including yours to send a patch v2)
ysionneau has quit [Ping timeout: 245 seconds]
ysionneau has joined #qi-hardware
lekernel has quit [Ping timeout: 250 seconds]