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
Ayla has quit [Quit: dodo]
phirsch has joined #qi-hardware
phirsch_ has joined #qi-hardware
panda|x201 has joined #qi-hardware
jluis has quit [Ping timeout: 245 seconds]
jluis has joined #qi-hardware
phirsch_ has quit [Remote host closed the connection]
phirsch has quit [Excess Flood]
phirsch has joined #qi-hardware
jluis has quit [Ping timeout: 245 seconds]
jluis has joined #qi-hardware
xwalk has quit [Ping timeout: 252 seconds]
Textmode has quit [Quit: Ex-Chat]
jluis has quit [Ping timeout: 245 seconds]
jluis has joined #qi-hardware
xwalk has joined #qi-hardware
emeb has quit [Quit: Leaving.]
rejon has quit [Ping timeout: 265 seconds]
wolfspraul has quit [Read error: Connection reset by peer]
wolfspraul has joined #qi-hardware
xwalk has quit [Ping timeout: 265 seconds]
xwalk has joined #qi-hardware
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
pabs3 has joined #qi-hardware
<wpwrak> hehe, non sequitur is good today: http://www.gocomics.com/nonsequitur/
jekhor has joined #qi-hardware
Maroni has joined #qi-hardware
Maroni has quit [Ping timeout: 260 seconds]
jurting has joined #qi-hardware
kristoffer has joined #qi-hardware
Ayla has joined #qi-hardware
viric has quit [Read error: Connection reset by peer]
viric has joined #qi-hardware
viric has quit [Changing host]
viric has joined #qi-hardware
rejon has joined #qi-hardware
xwalk has quit [Ping timeout: 252 seconds]
DocScrutinizer has quit [Disconnected by services]
DocScrutinizer has joined #qi-hardware
jekhor has quit [*.net *.split]
wolfspraul has quit [*.net *.split]
phirsch has quit [*.net *.split]
panda|x201 has quit [*.net *.split]
jekhor has joined #qi-hardware
panda|x201 has joined #qi-hardware
rejon has quit [Ping timeout: 245 seconds]
phirsch has joined #qi-hardware
GNUtoo-desktop has joined #qi-hardware
wolfspraul has joined #qi-hardware
phirsch has quit [Read error: Operation timed out]
phirsch_ has joined #qi-hardware
rejon has joined #qi-hardware
xiangfu has joined #qi-hardware
Ayla is now known as AwAyla
Aylax has joined #qi-hardware
Aylax has quit [Quit: Bye]
xiangfu has quit [Remote host closed the connection]
<viric> hm I'm trying to get a serial port to the gp2x and I fail...
<viric> ok got it
phirsch__ has joined #qi-hardware
rejon has quit [Ping timeout: 248 seconds]
kristoffer has quit [Quit: Leaving]
<viric> anyone good on yaffs?
<viric> how can I dump a yaffs into a file so I can mount it with a loop device?
<GNUtoo-desktop> viric, hmmm you need a fake MTD on RAM
<GNUtoo-desktop> to be able to mount a yaffs
<GNUtoo-desktop> else you can just exrtact from it
<GNUtoo-desktop> with some tools
<GNUtoo-desktop> but usually you dump the flash partition with mtd-utils
<viric> ah ok
<viric> thank you
<viric> I've lots of <7>**>>ecc error unfixed on chunk 3844:0
<mth> is the OOM area configuration correct?
<mth> you have to tell Linux where the ECC bytes are
<viric> hm no idea
<mth> and some devices use different layout than others
<viric> it's the stock firmware in the gp2x
<viric> I expect them to have it right
<mth> and you're running their kernel as well?
<viric> yes
<mth> ok, then this should not be the issue
rejon has joined #qi-hardware
<viric> mth: do you use as a serial port terminal emulator?
<mth> minicom
<viric> hm quite horrible.
<mth> if there is something better, please let me know :)
<viric> I'm used to 'cu'
<viric> from uucp
<viric> "cu -l /dev/ttyS1"
<viric> it's very simple, and does not any terminal emulation
<viric> but with this serial port, it gives me: cu: write: Input/output error
<viric> and minicom looks like not able to write now. I don't know what I touched.
<viric> why would a PC UART return 'input/output error' on write?
jekhor has quit [Ping timeout: 248 seconds]
<viric> ha. it was the hw flow control enabled.
<viric> mth: about 'flashing a nand'... usually the image contents are the 'mtdblock' contents, isn't it?
<viric> which is somewhat less bits than raw a mtd access would give.
<mth> you can have images with and without OOB data
<viric> hm ok
<mth> (I wrote OOM before, but that's something different)
<viric> yes, that confused me.
<viric> :)
<viric> you meant OOB area?
<viric> for me OOM means out of memory
kyak has quit [Read error: Operation timed out]
rejon has quit [Ping timeout: 246 seconds]
kyak has joined #qi-hardware
<viric> mth: writing to a mtdblock... it says: Writing data without ECC to NAND-FLASH is not recommended
<viric> wa, got rid of the boot sound of gp2x! mtdblock2 was a RIFF
<mth> replacing the data and not the ECC would be a bad idea
<mth> but I'd expect it to recompute the ECC as part of the write operaton
<mth> not sure if it actually does though
<mth> AwAyla has more experience with this
<viric> ok
<viric> for what I tried with other mtd devices, the write operation did all.
jeremybrown82 has joined #qi-hardware
<jeremybrown82> i have a question about cpu design
LunaVorax has joined #qi-hardware
<LunaVorax> Hey everyone
<mth> jeremybrown82: go ahead and ask the question
<jeremybrown82> can Alternating current of its own form be applied to registers in cpu ad direct currnet voltage by desin there by expanding the capicities of the hardware platform
<jeremybrown82> like multiplexing at the cpu level
<viric> anyone ever programmed an arm920t with arm940t coprocessor?
<jeremybrown82> im thinking about buying an arm laptop and using it for testing software on
<viric> I wonder how to use the coprocessor
<mth> I've never heard of CPUs running on alternating current
<jeremybrown82> not exactly ac persay just a algorythim
LunaVorax has quit [Client Quit]
<mth> viric: afaik it's mostly used for blitting
<viric> mth: as if it were a clever dma controller?
rejon has joined #qi-hardware
<viric> knowing how to blit.
<jeremybrown82> viric dont swear..lol
<viric> I know the gp2x software have the coprocessor used mostly in its libSDL for that
<mth> there is also this, but apparently it's not related to the copro: http://wiki.gp2x.org/wiki/Using_the_upper_32MB_of_memory
<viric> nice
<mth> I might be mistaken about blitting, it might be the hw blitter that wiki talks of, not the copro
<mth> usually weird coprocessors and up being unused
<mth> it seems hw people like them more than sw people ;)
<jeremybrown82> somthing like this i guess
<viric> it has a '2d graphics processor', a 'video processor', and the arm940t
<viric> the usual yuv=>rgb and scaling.
<viric> some idct...
<viric> quite a lot.
<viric> mth: can the ingenic do some idct, to accelerate jpeg decoding?
<mth> there is an IPU component that can do some image operations, like YUV decoding
<viric> and scaling, iirc
<viric> well, I've always been interested in displaying huge jpegs
<viric> using low memory
<viric> a low amount of memory I mean
<mth> in the 4740 it only does YUV conversion and scaling
<viric> ok
<mth> in later procs it can do more
<mth> I guess the trick is to make a decoder that doesn't decode the entire image, but only the sections that actually end up on the screen
<viric> it's a pity all this does not have a unified user-kernel interface
<mth> hw accel won't solve the memory issue
<viric> mth: yes, I did that partly. But libjpeg does not allow enough constraints
<mth> then you'll have to write your own lib or modify libjpeg, I think
<viric> :)
<viric> or do nothing
<mth> ...that's always an option
<viric> attractive.
<mth> I guess a specialize decoder that scales down is useful for generating thumbnails
<viric> mth: isn't there any user-kernel interface about those things? like dri or so
<mth> but that would work very different from a decoder that decodes 1:1 but only part of the image
<viric> mth: libjpeg allows decoding only the baseline (1/64 of resolution, 1/8 for each coordiante)
<viric> coordinate
<mth> I think v4l2 would be the best match for the IPU
<mth> but there is no driver yet
<viric> hm recently I wrote some v4l2 code...
<mth> dvdk accelerated mplayer using the IPU but via /dev/mem poking iirc
<viric> yes I know
<mth> which is fine for a prototype, but not the right way to do it
<viric> right.
<viric> I only used v4l2 for capturing from a webcam
<mth> what I'd like to have is an SDL driver that rotates buffers through v4l2
<viric> I'm not sure it can handle rescaling
<mth> to allow triple buffering
<viric> rotates 90°?
<viric> ahb
<mth> so you acquire a buffer from the kernel, fill it with a video frame, push it back into the kernel
<jeremybrown82> then fold
<viric> ok
<mth> and the kernel displays it at the next vsync
<jeremybrown82> like an overlay
<viric> v4l2 works with enqueuing and dequeuing
<mth> that way, user space doesn't have to mess with vsync at all anymore
<viric> hm treating the screen as a v4l2 output device...
<mth> SDL api allows it
<mth> just call SDL_Flip() when you're done with a frame
<mth> SDL doesn't require there to be just 2 pages for double buffering
<viric> why would triple buffering be better than double buffering?
<viric> mth: v4l2 looks quite good for an IPU. But how to manage when the screen shows /dev/fb0 contents or v4l2 contents? :)
<mth> stop displaying /dev/fb0 when the v4l2 surface is active?
<viric> 'active'.. could be.
<viric> I see mplayer supports v4l2 as output device too
<mth> I don't know the video part of v4l2 well enough to know how 'active' should be defined
<viric> ok
<mth> in theory you could even display multiple surfaces at the same time, vertically aligned
<mth> we want to have an overlay of 20 lines for the power slider daemon at some point
<viric> :)
<mth> to provide visual feedback when changing volume for example
<mth> it can be implemented using chained DMA descriptors
<mth> we're already doing that to add black lines at the top and bottom for TV-out
<viric> brave
<mth> otherwise the last pixel of the screen determines border color
<mth> it's not that hard if you have a static chain
<viric> border color... reminds of old tv-connected computers
<viric> I don't understand that about dma and the overlay
<mth> might be more tricky if you manage the chain dynamically
<viric> 'chained dma descriptors' is linux terminology?
<mth> it's just one DMA descriptor pointing to the next
<mth> it's a feature of Ingenic's DMA controller, but I think many DMA controllers have it
<mth> the daemon can't write in fb0, because an application is already writing there and would overwrite the daemon's gfx
<viric> then it goes on a next dma transfer without the cpu having to schedule a new one?
<mth> so it needs a separate buffer that can still be visible on the screen
<mth> correct
<mth> actually the descriptors are set up in a loop, so the CPU never has the intervene
<viric> but does the cpu get notified of the end of the 1st transfer?
<viric> ah
<mth> you can set a start or end interrupt flag in the descriptor if you have to know where DMA is
<viric> and how do you synchronize this?
<mth> you don't have to synchronize it, you only have to ensure the number of lines DMA-ed matches the number of lines per frame
<viric> but the cpu should not write to the memory the ipu or lcd is reading
<viric> hm maybe I miss details
<mth> ah yes
<mth> the CPU can write there, but the changes will not be picked up until the cache is flushed
rejon has quit [Ping timeout: 265 seconds]
<mth> so either you can make the framebuffer uncached, or you flush the cache regularly
<mth> for example on the start of frame interrupt
<mth> and with double buffering, you flush the cache on the flip
<mth> this is also easier with the v4l2 interface, there you would flush the cache when the kernel takes the buffer back from user space
<mth> which immediately frees up the cache for more useful data
<viric> yes
<mth> it's superior in every way
<mth> but it's not written yet
<viric> :)
<mth> currently double buffering uses vertical panning, which is a good match for ancient hardware, but a poor match for today's hardware
<viric> 'panning'?
<mth> scrolling of the view window
<mth> the fb is 320x480 and the view is either at (0, 0) or (0, 240)
<viric> ah I didn't know
<viric> what's bad in that?
<mth> because the entire fb is memmapped by user space
<mth> so the kernel driver anticipates on the typical usage pattern from SDL
<mth> but still has to support random access too
<mth> it's a bit of a mess
<viric> aha
<viric> ok
<mth> for example, on the Dingoo there is a separate LCD controller and the JZ is in SLCD mode
<mth> we can upload a frame whenever we want, there is no fixed refresh rate
<viric> I don't know SLCD
<mth> so ideally we upload immediately after a flip and not at any other time
<viric> the 'upload' is fast?
<mth> it's "smart LCD", meaning the panel is not an actual bare LCD panel, but something with its own controller and RAM
<mth> no, it takes a significant amount of time, since the memory bandwidth of the Dingoo is quite poor
<mth> AwAyla did some experiments with this and the maximum theoretical frame rate you could get
<viric> and what piece does the upload?
<mth> but I don't remember the result
<mth> the SLCD framebuffer driver
<viric> it's in the ram bus?
<mth> it's done via DMA
jurting has quit [Ping timeout: 252 seconds]
<mth> the SLCD FIFO is a special DMA target
<viric> ok
<mth> similar to how audio is streamed, for example
<viric> hm so much fun
<mth> in any case, we now have double buffering detection in the fb driver
<mth> that determines whether the calls it gets match the pattern from double buffering
<mth> if they do, we upload only on flips, otherwise we upload at a fixed timing (60 Hz)
<viric> ahhh
<viric> nice.
<mth> so if an emulator is running at 40 fps, we refresh only 40 times per second, saving some memory bandwidth
<viric> quite a lot, 60Hz
<viric> why so much?
<mth> historical reasons :)
<viric> you could do 25Hz fixed.
<viric> even faster than this flip trick
<mth> many games are written for 60 Hz
<mth> because of TVs
<viric> well, the games will think it's refreshed at 60Hz
<viric> they do their own counting
<mth> animations look best if you stick to their native freq
<viric> or some multiple...
<viric> ok, 30hz
<viric> :)
<mth> old games use flickering sprites to simulate transparency
<viric> oh good one
<viric> you win.
<mth> so if you drop half the frames consistently, you either see the sprite full or not at all
<mth> I've worked on openMSX for many years, you get nasty surprised like that :)
<mth> s/surprised/surprises
<qi-bot> mth meant: "I've worked on openMSX for many years, you get nasty surprises like that :)"
<viric> but... aren't there enough games that could run just fine uploading to screen at 30fps?
<viric> 'run' in the sense of pleasant playing
<mth> probably
<viric> Isn't it an option of emulators?
<viric> some emulators have so much options...
<mth> you could change the game code to run at a fixed 30 fps double buffered and we'd refresh at 30 fps then
<viric> ok nice
<mth> fixed frame skip is a typical feature for emulators
rejon has joined #qi-hardware
<mth> in openMSX we have a min and max frameskip setting
<jeremybrown82> mth have you heard of open pandora?
<jeremybrown82> or the handheld pandora
<mth> jeremybrown82: I even ordered one, but I'm still waiting for it
<mth> so I got a Dingoo A320 to play around with in the mean time
<jeremybrown82> teheh nice i want one but there so pricy for the specs
<jeremybrown82> dingo is cool but gpwiz is top notch these days no?
<mth> hw wise wiz is better, but Dingoo has an active scene
<mth> and it's cheaper
<jeremybrown82> mth dingoo is open?
<jeremybrown82> for some reason i thought otherwise
<mth> not as you get it from the manufacturer, but we've replaced all the software with open stuff
<jeremybrown82> haha nice does it require any modding
<mth> no, everything can be replaced via USB
<jeremybrown82> sweet soo like... whats good websites to key in on
<mth> although using the internal memory is still very tricky, so the easiest way is to do it via a mini SD card
<mth> dingoonity.org is the main scene site
<jeremybrown82> nice thanks man
<mth> and we've got the #dingoonity channel here on freenode as well
<jeremybrown82> so you recommend the d380?
<mth> not really, the manufacturer doesn't release sources and few developers are interested in it
<jeremybrown82> ohh ok
<mth> and the screen res is not very useful, being larger than 320x240 but not large enough to allow 1.5x or 2x scaling
<jeremybrown82> right
<mth> the A320 is still the best device imo
<mth> the GCW Zero might replace it, but that's still very much in a prototype stage
<jeremybrown82> a320e is any different?
<jeremybrown82> gcw zero hmm..
<mth> A320e is an entirely different machine iirc
<jeremybrown82> oh
<mth> ah no, I'm confused with the models now
<mth> A320e is like the A380
<mth> the Gemei A330 is an entirely different machine (ARM based)
<jeremybrown82> oh
<jeremybrown82> so you recommend which on again?
<viric> mth: understanding those 60Hz requirements for emulators... no wonder some of these machines run duke3d just fine, and can't emulate snes :)
emeb has joined #qi-hardware
<mth> snes is quite hard to emulate accurately
<mth> an emulator author wrote a nice piece about that for Ars Technica a while back
<viric> what is ars technica?
<viric> in this context
<mth> titles something like "why it takes a 3 GHz CPU to emulate SNES"
<mth> a tech news site
<viric> ah thank you, I'll read it
<viric> yes I found it
<viric> (I just also tried pocketsnes, and runs amazingly well in the gp2x compared to the other emulators I saw
<viric> )
<mth> you don't need high accuracy for most games
<viric> ahga
<viric> aha
<mth> and in some cases you'll only notice accuracy problems if you're very familiar with the game on real hw
<mth> I fixed a bug in overscan emulation in openMSX a few weeks ago which fixed exactly 1 game
<mth> since most games don't use overscan on MSX
<viric> ok
rejon has quit [Ping timeout: 240 seconds]
<viric> mth: thank you for that ars technica article, very nice!
Maroni has joined #qi-hardware
jurting has joined #qi-hardware
AwAyla has quit [Ping timeout: 248 seconds]
AwAyla has joined #qi-hardware
<viric> mth: did you try uucp 'cu' for serial? (Reminder: Type ~. to close 'cu'.)
<mth> no, I don't have a serial port on my Dingoo
<viric> ah ok :)
<mth> I've used minicom in the past to connect to the Wii, I think, but I don't really want to set that all up just to test
<viric> sure sure.
<mth> ah, and the very first Dingux kernel, which used serial over USB instead of ethernet over USB
Maroni has quit [Ping timeout: 260 seconds]
<kristianpaul> jow_laptop: hi
<kristianpaul> do you know some device tinier than the tplink 703n than runs owrt of course and have usb host port?
jekhor has joined #qi-hardware
jeremybrown82 has quit [Ping timeout: 240 seconds]
xwalk has joined #qi-hardware
wolfspraul has quit [Ping timeout: 246 seconds]
wolfspraul has joined #qi-hardware
LunaVorax has joined #qi-hardware
jurting_ has joined #qi-hardware
jurting has quit [Read error: Connection reset by peer]
jurting_ is now known as jurting
Textmode has joined #qi-hardware
wej has joined #qi-hardware
<viric> mth: I don't think there are many gaming devices with a v4l2 interface for their image processing units :)
<mth> probably not, but I don't think there are many gaming devices running Linux 3.4 yet either
<viric> ah :) yes
jurting has quit [Ping timeout: 244 seconds]
jekhor has quit [Read error: Operation timed out]
<jow_laptop> kristianpaul: sorry nope, the 703n is currently the smallest one I know personally
<jow_laptop> hm actually, there is one slightly smaller board I recall
AwAyla is now known as Ayla
cxadams has quit [Ping timeout: 260 seconds]
phirsch__ has quit [Remote host closed the connection]
cxadams has joined #qi-hardware