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