Topic for #qi-hardware is now 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
LunaVorax has quit [Remote host closed the connection]
Ayla has quit [Quit: dodo]
guanucoluis has joined #qi-hardware
xiangfu has joined #qi-hardware
rodgort has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
rodgort has joined #qi-hardware
guanucoluis has quit [Ping timeout: 245 seconds]
panda|x201 has joined #qi-hardware
xwalk has quit [Quit: Leaving]
rejon has joined #qi-hardware
emeb has quit [Ping timeout: 252 seconds]
rejon has quit [Remote host closed the connection]
compcube has quit [Quit: Leaving]
<kristianpaul>
wpwrak: had you survey other people about the same wine effect from that brand? :-)
heberth has joined #qi-hardware
<wpwrak>
only on smaller quantities. still need to do a more extensive study for my paper in Nature.
panda|x201 has quit [Ping timeout: 240 seconds]
rejon has joined #qi-hardware
heberth has quit [Quit: leaving]
emeb has joined #qi-hardware
emeb has quit [Quit: Leaving.]
emeb1 has joined #qi-hardware
<kristianpaul>
bye bye ansi c, welcome posix threads and semaphores
<kristianpaul>
hope this make code more portable between linux and rtems..
<DocScrutinizer05>
hmm
<DocScrutinizer05>
how's ansi c in conflict with posix?
<DocScrutinizer05>
aah wait, threads
<DocScrutinizer05>
I seem to recall sth from 5+ years ago
<DocScrutinizer05>
along lightweight threads or sth
<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 :-(
<wpwrak>
so because of linux enforcing this arbitrary restriction in the usb spec, one can't implement mass storage with a low-speed device :-(
<larsc>
does it work on windows?
<larsc>
or any other OS
<wpwrak>
i 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.
<wpwrak>
of course, if it only doens't work on linux, that would be tolerable. on linux it's easy to use some other mechanism.
LunaVorax has quit [Ping timeout: 246 seconds]
LunaVorax has joined #qi-hardware
jekhor has quit [Ping timeout: 248 seconds]
LunaVorax has quit [Quit: Quitte]
rejon has quit [Ping timeout: 240 seconds]
<viric>
wpwrak: iirc, the gp2x offers a mass storage device at usb 1.1
<viric>
1.1 == low speed? or that is 'full' speed?
pang_ is now known as pang
jurting has quit [Ping timeout: 265 seconds]
jurting has joined #qi-hardware
Ayla has joined #qi-hardware
kuribas has joined #qi-hardware
<larsc>
viric: I think 1.1 offered both full and low speed
<larsc>
low speed for stuff like mouse and keyboards and full speed for storage
xwalk has quit [Read error: Operation timed out]
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
kuribas has joined #qi-hardware
kuribas has quit [Remote host closed the connection]
<viric>
larsc: ah ok
<wpwrak>
yes, 1.1 = { low, full }. 2.0 = { low, full, high }. that's why you also see full-speed "USB 2.0" devices.
<whitequark>
wpwrak: erm, sorry, you are wrong afaik
<whitequark>
the linux behavior actually _allows_ you to use bulk endpoints on low-speed devices, which are indeed prohibited by usb spec
<whitequark>
I know that because I've played with V-USB, a software-defined USB device stack for ATmega processors
<whitequark>
and it obviously only offers low-speed 1.1
<whitequark>
with these software-defined devices, bulk endpoints actually work in Linux and sometimes work on other OSes
<wpwrak>
yes, i'm also experimenting with v-usb
<wpwrak>
did you try mass storage ?
<whitequark>
in 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 it
<whitequark>
iirc yes
<whitequark>
that was some years ago, through
<wpwrak>
what 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_INT
<wpwrak>
usb_endpoint_xfer_bulk() is the test wrapper, from include/linux/usb/ch9.h
xwalk has joined #qi-hardware
<wpwrak>
then 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)
<wpwrak>
since all the bulk EPs have become interrupt now, it then fails the sanity check right after the scan, and returns with -EIO
<whitequark>
hm
<whitequark>
could you just maybe try with .26 kernel?
<whitequark>
because, as I've been saying, that was quite a while ago and an unrelated change to the USB subsystem might have broken it
<wpwrak>
i looked at 2.6.36, and it looks the same there
<whitequark>
I'm pretty sure this used to work, but as this is quite an obscure feature
<wpwrak>
2.6.8.1 doesn't seem to have the "correction"
<whitequark>
too old :)
<whitequark>
I used 2.6.26 these times
<whitequark>
or maybe .22
<larsc>
commit 60aac1ec added it
<whitequark>
can't look at gitweb right now, sorry
<wpwrak>
hmm, when was that ? i don't have any kernel git repo around at the moment
<whitequark>
I'll be back after a few hours
<wpwrak>
ah wait, there's one
<larsc>
2007
<wpwrak>
Fri Jun 8 15:25:02 2007 -0400
guanucoluis has joined #qi-hardware
jekhor has joined #qi-hardware
<wpwrak>
well, 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.
<wpwrak>
the 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.
<viric>
ah this last sentence clarified a lot
<wpwrak>
heh, thought it might :)
<viric>
can't you have something like a keyboard, and send using the status leds ? :)
<viric>
capslock, numlock, ...
<viric>
it'd be nice to see the bandwidth for that
<wpwrak>
maybe. but then i'd need a special application that toggles the leds.
<viric>
and it may toggle the leds in all computer keyboards hehe
<wpwrak>
yeah, that too :)
<wpwrak>
well, 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.
<viric>
dfu?
<wpwrak>
of course, once we accept libusb in the mix, anything goes
<wpwrak>
a tftp-like firmware download protocol
<wpwrak>
pretty popular these days
<wpwrak>
the openmoko phones had it, idbg has it, atusb has it, ...
<wpwrak>
the only risk is that it finds some other device and sends your firmware there. now if that other device has no sanity checks, ...
<wpwrak>
e.g., seems many BT devices are dfu-upgradeable
rejon has joined #qi-hardware
kuribas has joined #qi-hardware
GNUtoo has joined #qi-hardware
emeb has joined #qi-hardware
DocScrutinizer has quit [Disconnected by services]
DocScrutinizer has joined #qi-hardware
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
<whitequark>
wpwrak: WRONG
<wpwrak>
you tried with a recent kernel and it worked ?
<whitequark>
the easiest way of putting something on a low-speed device while writing as fewer drivers as possible isn't mass storage
<whitequark>
it's HID
<whitequark>
quite un-obviously
<wpwrak>
ah
<whitequark>
HID doesn't need a kernel driver on linux nor windows
<wpwrak>
yes, but you still need an application that mangles HID
<whitequark>
and it works perfectly with 1.1 devs
<whitequark>
yep
<whitequark>
but afaik windows won't recognize such an UMS device at all
<whitequark>
so even if it'll work with that hack or without it, it'll only be restricted to linuxen
<wpwrak>
(ls-ums & windows) would need testing to verify
<wpwrak>
well, plan B is "some other protocol"
<whitequark>
sure, don't trust my words alone
<whitequark>
I'm also not sure how would you handle the accesses
<whitequark>
do you want to provide a fake FATFS?
woakas has joined #qi-hardware
<GNUtoo>
hi, there are a lot of gadgets drivers in mainline
<wpwrak>
plan 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 already
<wpwrak>
whitequark: yes, exactly
<wpwrak>
MBR, boot sector, FAT, and root directory provided by software. the clusters would be real flash blocks.
<whitequark>
wpwrak: flash? so you plan to provide your own FTL?
<wpwrak>
well, chunks of flash. much larger than the chip's "block"/"page" or whatever it's called
<wpwrak>
no, it's just for firmware
<whitequark>
erm, blocks and pages are different entities
<whitequark>
a page refers to write resolution, a block refers to erase resolution
<wpwrak>
in MCUs you find both words
<wpwrak>
and the two sizes are usually identical
<whitequark>
i.e. you can write the NAND in 2k or 4k pages (I worked with these chips), and erase them in 128k blocks or so
<wpwrak>
i'm talking about small critters
<whitequark>
maybe you have a different architecture
<whitequark>
hm
<whitequark>
I think I understand what do you want to do
<whitequark>
or maybe not
<wpwrak>
two cluster, 4 kB each. that order.
<whitequark>
can you elaborate?
<wpwrak>
when you plug the device in a pc, it would enumerate as USB storage
<wpwrak>
it would present MBR, boot sector, etc., as if it contained a FAT FS
<whitequark>
ok. what chip do you want to use for that?
<whitequark>
ATmega I guess?
<wpwrak>
MBR and boot sector are sw-generated
<whitequark>
which one?
<wpwrak>
attiny167, maybe attiny87
<whitequark>
hm
<wpwrak>
FAT would be sw-managed - generate on boot, then remember what's written
<wpwrak>
smae for the root directory. two entries :)
<wpwrak>
then the two data clusters. (fw has two separate parts)
<wpwrak>
then all i need to remember in the end is in which cluster which part ended up. and whether it's actually present.
<whitequark>
well, that might work
<whitequark>
you don't have a lot of ram in that chip, but your bootloader doesn't require much either.
<wpwrak>
unless any nasty "sanity checks" get in the way, it should
<wpwrak>
just 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 clusters
<wpwrak>
and the fat and directory cache are also small.
<kristianpaul>
DocScrutinizer05: my conclusion was no try do that my self (threads library) no matter how light or cooperative it could be
<whitequark>
wpwrak: flash write operations can be quite lengthy.
<whitequark>
and CPU is halted during erase/write
<whitequark>
and if the device won't respond to SOF which is issued every 1ms it'll be reset
<wpwrak>
does it have to respond to SOF ?
<whitequark>
yes
<whitequark>
it's how host understands that the device is alive.
<kristianpaul>
whitequark: had you tried fram latelly?
<whitequark>
kristianpaul: definitely not me
<whitequark>
wpwrak: on the other hand, I have used USBasploader successfully
<whitequark>
ah, I know why it can work
mafs has joined #qi-hardware
<whitequark>
it has two separate flash partitions, and the bootloader isn't halted on application flash writes
<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 ...
<mafs>
hey can anyone help me? pleaseee graphic card problems
<larsc>
noooooooooooooooooo
<whitequark>
wpwrak: whether in your device you don't have two separate ones but just one single partition
<kristianpaul>
mafs: sorry not general hardware support channel
<kristianpaul>
at least you mean milkymist one graphic card :)
<whitequark>
judging from the parallel programming characteristics, a chip erase takes 7.5 to 9 ms, and a page write takes 3.7 to 4.5 ms
mafs has quit [Client Quit]
<Ayla>
larsc is the expert of graphic cards, ask him
<whitequark>
wpwrak: there's also another problem
<whitequark>
wpwrak: 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 wants
<whitequark>
I don't quite remember how much one bulk transfer can be, but it's definitely more than 64 words
<whitequark>
you'll have to NAK it the (transfer_size / page_size) times
<whitequark>
kristianpaul: what's your need in a thread library?
<wpwrak>
whitequark: 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 any
<wpwrak>
the bulk transfer will come in many little 8 byte chunks
<whitequark>
hm
<whitequark>
maybe, I don't remember USB spec that good anymore
<whitequark>
probably I'm wrong here
<kristianpaul>
whitequark: portabillity and parallel computing
<wpwrak>
whitequark: let's hope so :)
<wpwrak>
i also wonder if a 48 MHz NXP LPCxxx could be fast enough to do full-speed sw USB ;)
<whitequark>
wpwrak: quite certainly not
<whitequark>
because USB is, you know, 480 Mbit/s :)
<whitequark>
high-speed quite possibly, but I doubt you want to develop a USB stack
kristoffer has joined #qi-hardware
<wpwrak>
full-speed is 12 Mbps
<wpwrak>
and you can do Mass Storage with full-speed ! ;-)
<whitequark>
ah, full- vs high-speed
<whitequark>
I always mix up the two
<wpwrak>
and it wouldn't exectly be the first usb stack i've made :)
<whitequark>
oh :)
<whitequark>
well, good luck then :)
<wpwrak>
well, 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)
<wpwrak>
besides, there's v-usb as a reference. and there's a PIC variant, too
<wpwrak>
now, 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.
<wpwrak>
sw would then just have to move whole bytes/words and watch for EOP
<wpwrak>
then ACK and then figure out what it has actually received :)
emeb has quit [Quit: Leaving.]
guanucoluis has quit [Ping timeout: 255 seconds]
porchao has joined #qi-hardware
xiangfu has quit [Ping timeout: 246 seconds]
<wpwrak>
grmbl. 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.
<viric>
wpwrak: what about a usb serial port or parallel port device? isn't that any standard at all?
<viric>
or usbaudio
<wpwrak>
hmm. 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.
<viric>
printing in linux never worked.
<wpwrak>
audio may be standard .. but the you probably have to reconfigure the system. not nice.
<wpwrak>
oh, printing worked perfectly ... in the days of "lpr"
<wpwrak>
lpr file-our-printer-will-understand
<wpwrak>
add gs to your print filter, for extra comfort (unless your printer already speaks ps natively, which back then only the really expensive ones did)
Ornotermes has quit [*.net *.split]
mth has quit [*.net *.split]
Ornotermes has joined #qi-hardware
mth has joined #qi-hardware
<wpwrak>
how that's funny: NXP put USB drivers in the ROM of some of their (pricier) MCUs. when with goodies like mass-storage and DFU.
Ornotermes has quit [*.net *.split]
mth has quit [*.net *.split]
Ornotermes has joined #qi-hardware
mth has joined #qi-hardware
urandom__ has joined #qi-hardware
<wpwrak>
hah, and is seems that nxp are doing something very similar to what i have in mind. also with emulated mbr, boot sector, fat, directory.
<viric>
wpwrak: but this is the cups era.
<viric>
I remember that I had to touch cups code... it was a big mess, for my taste
<viric>
(I needed it to check certificates for https urls. It doesn't check anything otherwise)
<wpwrak>
cups is a mess, yes. that's why i'm pining for the good old days. the golden age of unix printing.
<viric>
then there was the ghostscript split too
<viric>
gnu ghostscript, vs ghostscript.com
<viric>
one lagging vs the other...
<viric>
both gplv3 :)
kilae has quit [Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347]]
kristoffer has quit [Ping timeout: 252 seconds]
<wpwrak>
that must have been long before glpv3
jekhor has quit [Ping timeout: 240 seconds]
xwalk has quit [Ping timeout: 248 seconds]
wpwrak has quit [Ping timeout: 260 seconds]
wpwrak has joined #qi-hardware
zear has quit [Ping timeout: 260 seconds]
DocScrutinizer has quit [Remote host closed the connection]
xwalk has joined #qi-hardware
DocScrutinizer has joined #qi-hardware
GNUtoo has quit [*.net *.split]
rozzin has quit [*.net *.split]
Jay7 has quit [*.net *.split]
liuqi has quit [*.net *.split]
kanzure has quit [*.net *.split]
GNUtoo has joined #qi-hardware
rozzin has joined #qi-hardware
liuqi has joined #qi-hardware
Jay7 has joined #qi-hardware
kanzure has joined #qi-hardware
zear has joined #qi-hardware
kristoffer has joined #qi-hardware
<viric>
wpwrak: they are still split and gnu updating from the .com. I think the gnu release only changes some docs and source code comments.
<wpwrak>
ah :) didn't hear of the non-gnu one for at least a decade :)
<viric>
the gnu one is the *lagged*
<whitequark>
wasn't it called "GPL Ghostscript"?
<wpwrak>
could be
jekhor has joined #qi-hardware
GNUtoo has quit [Ping timeout: 252 seconds]
GNUtoo|laptop has joined #qi-hardware
kristoffer has quit [Quit: Leaving]
guanucoluis has joined #qi-hardware
freakazoid0223 has joined #qi-hardware
antgreen has joined #qi-hardware
antgreen has quit [Remote host closed the connection]
wej has quit [Ping timeout: 272 seconds]
jow_laptop has quit [Ping timeout: 248 seconds]
wej has joined #qi-hardware
guanucoluis has quit [Ping timeout: 245 seconds]
guanucoluis1 has joined #qi-hardware
GNUtoo|laptop has quit [Quit: Program received signal SIGSEGV, Segmentation fault.]
kuribas has quit [Remote host closed the connection]
urandom__ has quit [Remote host closed the connection]
GeorgeH-Away is now known as GeorgeH
GeorgeH has quit [Quit: Leaving]
GeorgeH has joined #qi-hardware
jekhor has quit [Ping timeout: 268 seconds]
jurting has quit [Read error: Connection reset by peer]
guanucoluis1 has quit [Ping timeout: 245 seconds]
losinggeneration has quit [Ping timeout: 244 seconds]