#qi-hardware IRC log for Wednesday, 2012-08-08

kristianpaulwpwrak: had you survey other people about the same wine effect from that brand? :-)03:05
wpwrakonly on smaller quantities. still need to do a more extensive study for my paper in Nature.03:13
kristianpaulbye bye ansi c, welcome posix threads and semaphores04:35
kristianpaulhope this make code more portable between linux and rtems.. 04:36
DocScrutinizer05hmm04:37
DocScrutinizer05how's ansi c in conflict with posix?04:37
DocScrutinizer05aah wait, threads04:38
DocScrutinizer05I seem to recall sth from 5+ years ago04:39
DocScrutinizer05along lightweight threads or sth04:39
rjeffriesthese speakers are rather cool. and open. http://web.media.mit.edu/~mellis/speakers/05:33
LunaVoraxHello05:59
wpwrak@%$#*! when a usb low-speed device tries to register bulk EPs (which for some obscure reason isn't allowed by the usb spec), linux helpfully converts them to interrupt. this is of course breaks any use of them as bulk with protocols that do require bulk and that won't be satisfied with interrupt. such as mass storage :-(06:40
wpwrakso because of linux enforcing this arbitrary restriction in the usb spec, one can't implement mass storage with a low-speed device :-(06:44
larscdoes it work on windows?06:45
larscor any other OS06:46
wpwraki don't have any windows around here, but someone who made such a device claimed "it usually works". and his files are full of \r\n. so i would suspect he tried it there.06:47
wpwrakof course, if it only doens't work on linux, that would be tolerable. on linux it's easy to use some other mechanism.06:50
viricwpwrak: iirc, the gp2x offers a mass storage device at usb 1.109:51
viric1.1 == low speed? or that is 'full' speed?09:52
larscviric: I think 1.1 offered both full and low speed10:59
larsclow speed for stuff like mouse and keyboards and full speed for storage11:00
viriclarsc: ah ok11:38
wpwrakyes, 1.1 = { low, full }. 2.0 = { low, full, high }. that's why you also see full-speed "USB 2.0" devices.11:48
whitequarkwpwrak: erm, sorry, you are wrong afaik11:57
whitequarkthe linux behavior actually _allows_ you to use bulk endpoints on low-speed devices, which are indeed prohibited by usb spec11:58
whitequarkI know that because I've played with V-USB, a software-defined USB device stack for ATmega processors11:58
whitequarkand it obviously only offers low-speed 1.111:58
whitequarkwith these software-defined devices, bulk endpoints actually work in Linux and sometimes work on other OSes11:59
wpwrakyes, i'm also experimenting with v-usb11:59
wpwrakdid you try mass storage ?11:59
whitequarkin fact, that hack was added almost specifically for v-usb, because otherwise bulk polling was overloading the device. it's not there to break v-usb, it's there to fix it12:01
whitequarkiirc yes12:01
whitequarkthat was some years ago, through12:02
wpwrakwhat i see is this: drivers/usb/core/config.c:usb_parse_endpoint converts all usb_endpoint_xfer_bulk() endpoints on low-speed devices to USB_ENDPOINT_XFER_INT12:05
wpwrakusb_endpoint_xfer_bulk() is the test wrapper, from include/linux/usb/ch9.h12:05
wpwrakthen drivers/usb/storage/usb.c:get_pipes searches the list of EPs for bulk EPs and remembers them. it also remembers an usb_endpoint_is_int_in() EP, if it fonds one (for a different protocol variant)12:07
wpwraksince all the bulk EPs have become interrupt now, it then fails the sanity check right after the scan, and returns with -EIO12:07
whitequarkhm12:07
whitequarkcould you just maybe try with .26 kernel?12:07
whitequarkbecause, as I've been saying, that was quite a while ago and an unrelated change to the USB subsystem might have broken it12:08
wpwraki looked at 2.6.36, and it looks the same there12:08
whitequarkI'm pretty sure this used to work, but as this is quite an obscure feature12:08
wpwrak2.6.8.1 doesn't seem to have the "correction"12:09
whitequarktoo old :)12:10
whitequarkI used 2.6.26 these times12:10
whitequarkor maybe .2212:10
larsccommit 60aac1ec added it12:11
whitequarkcan't look at gitweb right now, sorry12:13
wpwrakhmm, when was that ? i don't have any kernel git repo around at the moment12:13
whitequarkI'll be back after a few hours12:13
wpwrakah wait, there's one12:14
larsc200712:14
wpwrakFri Jun 8 15:25:02 2007 -040012:14
wpwrakwell, i'll return to this issue. then i'll disable the "fix" and see if this makes things work. that way, i could make something that can be tested with legacy operating systems.12:28
wpwrakthe objective of the whole exercise is to find a way to put data (a few kB) on a USB device without needing drivers for windows and such. seems that storage is the only way to do this.12:30
viricah this last sentence clarified a lot12:47
wpwrakheh, thought it might :)12:49
viriccan't you have something like a keyboard, and send using the status leds ? :)12:51
viriccapslock, numlock, ...12:51
viricit'd be nice to see the bandwidth for that12:51
wpwrakmaybe. but then i'd need a special application that toggles the leds.12:52
viricand it may toggle the leds in all computer keyboards hehe12:52
wpwrakyeah, that too :)12:52
wpwrakwell, one option would be DFU. that seems to be taken care of, even though the installation seems to be a bit on the ugly side.12:53
viricdfu?12:54
wpwrakof course, once we accept libusb in the mix, anything goes12:54
wpwraka tftp-like firmware download protocol12:54
wpwrakpretty popular these days12:54
wpwrakthe openmoko phones had it, idbg has it, atusb has it, ...12:55
wpwrakthe only risk is that it finds some other device and sends your firmware there. now if that other device has no sanity checks, ...12:55
wpwrake.g., seems many BT devices are dfu-upgradeable12:56
whitequarkwpwrak: WRONG14:21
wpwrakyou tried with a recent kernel and it worked ?14:21
whitequarkthe easiest way of putting something on a low-speed device while writing as fewer drivers as possible isn't mass storage14:22
whitequarkit's HID14:22
whitequarkquite un-obviously14:22
wpwrakah14:22
whitequarkHID doesn't need a kernel driver on linux nor windows14:22
wpwrakyes, but you still need an application that mangles HID14:22
whitequarkand it works perfectly with 1.1 devs14:22
whitequarkyep14:22
whitequarkbut afaik windows won't recognize such an UMS device at all14:22
whitequarkso even if it'll work with that hack or without it, it'll only be restricted to linuxen14:23
wpwrak(ls-ums & windows) would need testing to verify14:23
wpwrakwell, plan B is "some other protocol"14:24
whitequarksure, don't trust my words alone14:24
whitequarkI'm also not sure how would you handle the accesses14:24
whitequarkdo you want to provide a fake FATFS?14:24
GNUtoohi, there are a lot of gadgets drivers in mainline14:25
wpwrakplan C is to find a chip that can do full-speed. unfortunately, this is tricky. NXP may have one ... LPC11U12FHN33/201. but that needs further examinations. has a few quirks, i can tell that already14:25
wpwrakwhitequark: yes, exactly14:25
wpwrakMBR, boot sector, FAT, and root directory provided by software. the clusters would be real flash blocks.14:26
whitequarkwpwrak: flash? so you plan to provide your own FTL?14:26
wpwrakwell, chunks of flash. much larger than the chip's "block"/"page" or whatever it's called14:26
wpwrakno, it's just for firmware14:26
whitequarkerm, blocks and pages are different entities14:27
whitequarka page refers to write resolution, a block refers to erase resolution14:27
wpwrakin MCUs you find both words14:27
wpwrakand the two sizes are usually identical14:27
whitequarki.e. you can write the NAND in 2k or 4k pages (I worked with these chips), and erase them in 128k blocks or so14:27
wpwraki'm talking about small critters14:27
whitequarkmaybe you have a different architecture14:27
whitequarkhm14:27
whitequarkI think I understand what do you want to do14:28
whitequarkor maybe not14:28
wpwraktwo cluster, 4 kB each. that order.14:28
whitequarkcan you elaborate?14:28
wpwrakwhen you plug the device in a pc, it would enumerate as USB storage14:28
wpwrakit would present MBR, boot sector, etc., as if it contained a FAT FS14:29
whitequarkok. what chip do you want to use for that?14:29
whitequarkATmega I guess?14:29
wpwrakMBR and boot sector are sw-generated14:29
whitequarkwhich one?14:29
wpwrakattiny167, maybe attiny8714:29
whitequarkhm14:30
wpwrakFAT would be sw-managed - generate on boot, then remember what's written14:30
wpwraksmae for the root directory. two entries :)14:30
wpwrakthen the two data clusters. (fw has two separate parts)14:30
wpwrakthen all i need to remember in the end is in which cluster which part ended up. and whether it's actually present.14:31
whitequarkwell, that might work14:32
whitequarkyou don't have a lot of ram in that chip, but your bootloader doesn't require much either.14:32
wpwrakunless any nasty "sanity checks" get in the way, it should14:32
wpwrakjust a few bytes. buffer the usb/scsi bureaucracy. flash data can be written as we go. so there's no need to buffer entire sectors or even clusters14:33
wpwrakand the fat and directory cache are also small.14:33
kristianpaulDocScrutinizer05: my conclusion was no try do that my self (threads library) no matter how light or cooperative it could be14:34
whitequarkwpwrak: flash write operations can be quite lengthy.14:34
whitequarkand CPU is halted during erase/write14:34
whitequarkand if the device won't respond to SOF which is issued every 1ms it'll be reset14:34
wpwrakdoes it have to respond to SOF ?14:35
whitequarkyes14:35
whitequarkit's how host understands that the device is alive.14:35
kristianpaulwhitequark: had you tried fram latelly?14:35
whitequarkkristianpaul: definitely not me14:35
whitequarkwpwrak: on the other hand, I have used USBasploader successfully14:37
whitequarkah, I know why it can work14:37
whitequarkit has two separate flash partitions, and the bootloader isn't halted on application flash writes14:37
wpwrak"The SOF token does not cause any receiving function to generate a return packet;". so at least in full-speed and above, there is no response. checking low-speed, which uses different SOF signaling ...14:37
mafshey can anyone help me? pleaseee graphic card problems14:37
larscnoooooooooooooooooo14:38
whitequarkwpwrak: whether in your device you don't have two separate ones but just one single partition14:38
kristianpaulmafs: sorry not general hardware support channel14:38
kristianpaulat least you mean milkymist one graphic card :)14:38
whitequarkjudging from the parallel programming characteristics, a chip erase takes 7.5 to 9 ms, and a page write takes 3.7 to 4.5 ms14:39
Aylalarsc is the expert of graphic cards, ask him14:39
whitequarkwpwrak: there's also another problem14:39
whitequarkwpwrak: you can only write one page at a time and then you have to wait, but the host would happily send you data in whatever quantity it wants14:39
whitequarkI don't quite remember how much one bulk transfer can be, but it's definitely more than 64 words14:40
whitequarkyou'll have to NAK it the (transfer_size / page_size) times14:40
whitequarkkristianpaul: what's your need in a thread library?14:41
wpwrakwhitequark: i don't see anything that suggests the device needs to take action on a keep-alive (SOF for full-speed and above, EOP for low-speed), except that it should suspend if it doesn't receive any14:43
wpwrakthe bulk transfer will come in many little 8 byte chunks14:44
whitequarkhm14:45
whitequarkmaybe, I don't remember USB spec that good anymore14:45
whitequarkprobably I'm wrong here14:46
kristianpaulwhitequark: portabillity and parallel computing14:46
wpwrakwhitequark: let's hope so :)14:46
wpwraki also wonder if a 48 MHz NXP LPCxxx could be fast enough to do full-speed sw USB ;)14:53
whitequarkwpwrak: quite certainly not14:58
whitequarkbecause USB is, you know, 480 Mbit/s :)14:58
whitequarkhigh-speed quite possibly, but I doubt you want to develop a USB stack14:58
wpwrakfull-speed is 12 Mbps14:58
wpwrakand you can do Mass Storage with full-speed ! ;-)14:59
whitequarkah, full- vs high-speed14:59
whitequarkI always mix up the two14:59
wpwrakand it wouldn't exectly be the first usb stack i've made :)14:59
whitequarkoh :)14:59
whitequarkwell, good luck then :)14:59
wpwrakwell, so far the "stacks" had sat on hardware handling the bit-level stuff. i've written a bit-level decoder, though (for something like a logic analyzer)15:00
wpwrakbesides, there's v-usb as a reference. and there's a PIC variant, too15:00
wpwraknow, a CPU clock of 48 MHz may not quite be enough, but perhaps the CPU could send/receive the data over 1/2 SPI links, with the appropriate trickery.15:02
wpwraksw would then just have to move whole bytes/words and watch for EOP15:02
wpwrakthen ACK and then figure out what it has actually received :)15:03
wpwrakgrmbl. the critter is so slow writing to its flash that the usb stack thinks the device is dead and gives up. even if defer the flashing until after usbPoll returns.16:23
viricwpwrak: what about a usb serial port or parallel port device? isn't that any standard at all?16:25
viricor usbaudio16:25
wpwrakhmm. printer. there's probably a massive software stack between a file and the printer. it's even bad on linux, with cups, printer-specific profiles, and so on.16:27
viricprinting in linux never worked.16:27
wpwrakaudio may be standard .. but the you probably have to reconfigure the system. not nice.16:28
wpwrakoh, printing worked perfectly ... in the days of "lpr"16:28
wpwraklpr file-our-printer-will-understand16:28
wpwrakadd gs to your print filter, for extra comfort (unless your printer already speaks ps natively, which back then only the really expensive ones did)16:29
wpwrakhow that's funny: NXP put USB drivers in the ROM of some of their (pricier) MCUs. when with goodies like mass-storage and DFU.16:44
wpwrakhah, and is seems that nxp are doing something very similar to what i have in mind. also with emulated mbr, boot sector, fat, directory.16:49
viricwpwrak: but this is the cups era.16:50
viricI remember that I had to touch cups code... it was a big mess, for my taste16:51
viric(I needed it to check certificates for https urls. It doesn't check anything otherwise)16:51
wpwrakcups is a mess, yes. that's why i'm pining for the good old days. the golden age of unix printing.16:52
viricthen there was the ghostscript split too16:52
viricgnu ghostscript, vs ghostscript.com16:52
viricone lagging vs the other...16:52
viricboth gplv3 :)16:53
wpwrakthat must have been long before glpv317:10
viricwpwrak: they are still split and gnu updating from the .com. I think the gnu release only changes some docs and source code comments.18:26
wpwrakah :) didn't hear of the non-gnu one for at least a decade :)18:31
viricthe gnu one is the *lagged*18:35
whitequarkwasn't it called "GPL Ghostscript"?18:36
wpwrakcould be18:48
--- Thu Aug 9 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!