| 00:00:01 | | Nick bruges|afk is now known as bruges (n=bruges@e178039202.adsl.alicedsl.de) |
| 00:00:26 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
| 00:00:48 | | Quit sneeze ("Leaving") |
| 00:01:07 | | Join fyrestorm [0] (n=fyre@cpe-68-173-163-201.nyc.res.rr.com) |
| 00:01:11 | toffe82 | jhMikeS: : found the reset of the usb chip of the S : pin k24 of the imx |
| 00:01:16 | amiconn | Hmm, full rebuild didn't help... |
| 00:01:30 | toffe82 | theport is the usbotg one |
| 00:01:56 | | Join CyBergRind|w [0] (n=cbr@212.98.160.130) |
| 00:02:50 | jhMikeS | amiconn: yes, flush + invalidate |
| 00:03:09 | amiconn | Hmm, not on cop though, right? |
| 00:03:19 | amiconn | But that shouldn't matter at all here |
| 00:03:27 | jhMikeS | amiconn: every thread created gets a flush + invalidate |
| 00:03:43 | amiconn | The greylib creates no thread at all |
| 00:03:53 | amiconn | It just puts an isr on cop (if requested) |
| 00:04:19 | jhMikeS | yeah, interrupt code will not which could present a problem. |
| 00:04:32 | amiconn | Yeah, but not here |
| 00:04:50 | amiconn | The cop will only see uncached addresses which are first written by the cpu |
| 00:04:57 | jhMikeS | toffee82: usb chip? I wasn't aware there was a usb chip (other than the bit with the mc13783) |
| 00:05:25 | gevaerts | Is there a reason that ftruncate in rockbox can't extend a file ? The normal POSIX ftruncate can |
| 00:05:54 | jhMikeS | gevaerts: noone felt like doing it? :) |
| 00:06:48 | gevaerts | The problem is of course that by now some code might depend on getting an error in that case.. |
| 00:07:46 | amiconn | Nothing in rockbox uses it apart from file.c itself |
| 00:08:20 | gevaerts | OK, so we're safe there. Thanks |
| 00:08:27 | * | jhMikeS wonders why something named "...truncate" would ever extend anything |
| 00:08:53 | * | amiconn did a quick grep |
| 00:09:14 | amiconn | jhMikeS: indeed. |
| 00:10:05 | gevaerts | It's often used to reserve disk space, to be written later |
| 00:10:09 | Bagder | gevaerts: I think that simply nobody ever needed it |
| 00:11:24 | toffe82 | gevaerts: jhMikeS : the chip select of the usb is C10 of the cpu |
| 00:11:42 | toffe82 | do you need something else ? |
| 00:12:34 | Nico_P | amiconn: uisimulator/common/io.c and /firmware/test/fat/main.c use it too |
| 00:12:43 | amiconn | no |
| 00:12:55 | amiconn | uisimulatr/common/io.c *provides* it for the sims |
| 00:13:04 | Nico_P | ah |
| 00:13:04 | jhMikeS | toffee82: what usb chip is there? I thought we always needed the SW stack. |
| 00:13:12 | amiconn | And the test code uses it, yes. But that wasn't touched in ages... |
| 00:13:33 | toffe82 | philips isp1504, do you want the datasheet ? |
| 00:14:04 | gevaerts | It uses the isp1504 ? |
| 00:14:07 | * | gevaerts is confused |
| 00:14:11 | toffe82 | if you look the block diagram , the usb is not direct from the cpu |
| 00:14:12 | jhMikeS | toffee82: yeah (/me wonders how he missed this) |
| 00:14:30 | toffe82 | gevaerts: ?? |
| 00:14:34 | * | jhMikeS has it already :p |
| 00:15:03 | gevaerts | Wasn't this imx31 with built-in USB ? |
| 00:15:07 | toffe82 | it the tipical application for the imx |
| 00:15:26 | toffe82 | yes but toshiba do it this way |
| 00:15:28 | jhMikeS | gigabeat S has alot of redundancy in the HW |
| 00:15:42 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 00:15:44 | toffe82 | yes with the mc 13... |
| 00:15:52 | | Join sourcemaker [0] (n=sourcema@p5B2DFB6F.dip.t-dialin.net) |
| 00:16:02 | sourcemaker | does rockbox work with IPOD 4gen |
| 00:16:15 | bluebrother | sourcemaker: have you read the front page? |
| 00:16:15 | n1s | sourcemaker: yes |
| 00:17:00 | * | amiconn wonders what the explicit 'nocommon' is for, and tries without |
| 00:17:01 | toffe82 | jhMikeS: they fix it in the t400, no more redundancy :) |
| 00:17:19 | amiconn | We don't use 'nocommon' for the I*_ATTR either |
| 00:17:48 | bluebrother | hmm, this progress looks weird -- processEvents isn't called often enough :( |
| 00:18:49 | | Quit cbr|w (Read error: 110 (Connection timed out)) |
| 00:19:10 | | Join ddalton [0] (n=ddalton@124-168-53-116.dyn.iinet.net.au) |
| 00:19:23 | domonoky | bluebrother: a clean way for this processEvents mess, would be to use worker threads :-) |
| 00:19:39 | ddalton | hey what tool do I use for patching the h300 firmware under linux? so to patch a 1.28 K version to included rockbox support? |
| 00:19:43 | sourcemaker | which device do I use to install rockbox /dev/sdd or /dev/sdd1/2 |
| 00:20:04 | domonoky | ddalton: try rbutil :-) |
| 00:20:20 | ddalton | domonoky: No gui sorry. |
| 00:20:24 | | Nick bruges is now known as bruganit (n=bruges@e178039202.adsl.alicedsl.de) |
| 00:20:25 | bluebrother | well, I'm trying to make the zip class tell us about the current file (i.e. emit the actual count) |
| 00:20:29 | ddalton | Im blind and qt is not accessible... |
| 00:20:37 | gevaerts | toffe82, jhMikeS : it looks to me like the isp1504 is "just" the transceiver, which might not be provided by the imx31 (not clear to me) |
| 00:20:50 | bluebrother | ddalton: there is a cli patch in the tracker. I've updated it some days ago, so it should compile. |
| 00:21:05 | bluebrother | no idea if patching of the iriver fw is already implemented. |
| 00:21:07 | ddalton | sourcemaker: mount sdd1, you need to install to a partition... |
| 00:21:10 | jhMikeS | gevaerts, toffee82: I don't see how it bridges the ATA or anything from the logic block diagram |
| 00:21:25 | bluebrother | sourcemaker: try rbutil :) |
| 00:21:25 | domonoky | bluebrother: should be implemented.. |
| 00:21:48 | amiconn | ddalton: on ipods, the bootloader installation needs the *device* |
| 00:21:51 | bluebrother | my update was only to catch up with internal changes. |
| 00:21:57 | gevaerts | jhMikeS: It probably doesn't. From what I see the imx31 provides the usb device controller, the isp1504 provides the transceiver |
| 00:22:03 | | Nick bruganit is now known as borges (n=bruges@e178039202.adsl.alicedsl.de) |
| 00:22:08 | * | gevaerts could be wrong of course |
| 00:22:21 | | Quit davina ("GNU/Linux the free alternative to Windows") |
| 00:22:31 | bluebrother | sourcemaker: the bootloader goes to the partition (i.e. sdd) while the install goes to the data partition of the Ipod (sdd2) |
| 00:22:43 | ddalton | oh ill check it out ok. so there is no manual way I can use? like a separate cli tool or shell script in /tools? |
| 00:22:48 | bluebrother | but you can simply mount the player and let rbutil do the rest. |
| 00:23:16 | bluebrother | ddalton: sure, you can use scramble. IIRC that was documented in the IriverBoot page. |
| 00:23:29 | sourcemaker | bluebrother: configuration invalid... |
| 00:23:33 | bluebrother | you need to do a few steps manually though. |
| 00:23:38 | bluebrother | sourcemaker: then correct it ... |
| 00:23:39 | amiconn | bluebrother: for patching an iriver fw?? |
| 00:23:43 | ddalton | in the manual it doesn't really explain to linux users? do you just assume we know? Or do you just assume everyone can run qt apps these days? |
| 00:23:47 | jhMikeS | toffee82: are you adding the various pinouts to the wiki or do I have to make note before it's lost in the logs forever? :) |
| 00:24:01 | toffe82 | gevaerts: jhMikeS : you have a signal usb detect which goes to the mc13783 |
| 00:24:05 | saratoga | http://www.sacg.com.tw/sacweb/marcom/epaper/images/ISP1504,%20ISP1505,%20ISP1606%20Literature.pdf |
| 00:24:15 | saratoga | looks like its just the physical layer interface, not hte controller |
| 00:24:16 | bluebrother | ddalton: the manual way of patching the hex file was never in the manual |
| 00:24:17 | toffe82 | take note :) for the moment |
| 00:24:24 | gevaerts | saratoga: exactly |
| 00:24:58 | bluebrother | ddalton: http://www.rockbox.org/twiki/bin/view/Main/IriverBoot#Patching_the_iriver_firmware |
| 00:25:36 | ddalton | thanks! |
| 00:25:38 | | Quit ddalton ("leaving") |
| 00:25:47 | | Join BITCH [0] (n=USERNAME@c-75-68-29-188.hsd1.nh.comcast.net) |
| 00:25:48 | sourcemaker | bluebrother: installation is in progress.... I how this works |
| 00:25:51 | domonoky | ddalton: and make sure you check the md5sum of the manually created firmware file, if it wrong the players is broken.. |
| 00:25:52 | n1s | ddalton: what you need to do is descramble the firmware with scramble, patch with mkboot and scramble it again |
| 00:25:56 | BITCH | HI |
| 00:26:02 | BITCH | IM NEW |
| 00:26:09 | bluebrother | and your caps lock is broken |
| 00:26:18 | BITCH | NOT MINE |
| 00:26:21 | BITCH | XD |
| 00:26:31 | BITCH | IM UR B**** |
| 00:26:32 | BigBambi | BITCH: Turn off, caps lock, and stay on topic |
| 00:26:39 | BITCH | y |
| 00:26:43 | Mode | "#rockbox +o Bagder " by ChanServ (ChanServ@services.) |
| 00:26:54 | * | n1s holds breath |
| 00:27:07 | | Nick BITCH is now known as IM (n=USERNAME@c-75-68-29-188.hsd1.nh.comcast.net) |
| 00:27:19 | | Nick IM is now known as IMYOURBITCH (n=USERNAME@c-75-68-29-188.hsd1.nh.comcast.net) |
| 00:27:28 | * | bluebrother goes for popcorn |
| 00:27:35 | IMYOURBITCH | y should i |
| 00:27:39 | BigBambi | IMYOURBITCH: bye |
| 00:27:46 | Kick | (#rockbox IMYOURBITCH :Bagder) by Bagder!n=daniel@rockbox/developer/bagder |
| 00:28:24 | ali_as | Prank by a regular maybe? |
| 00:28:42 | bluebrother | that was quick |
| 00:29:21 | jhMikeS | USB DETECT seems to go straight to the mc13783 |
| 00:29:22 | BigBambi | ali_as: Doubt it. It wasn't funny, and the regulars will know that it can only annoy and result in a kick |
| 00:29:24 | | Quit merbanan (Remote closed the connection) |
| 00:29:57 | ali_as | Caps lock, constantly changing nick, like someone read the rules and did it deliberatly. |
| 00:30:07 | BigBambi | Well, anyway |
| 00:30:39 | sourcemaker | installation complete |
| 00:31:31 | toffe82 | jhMikeS: so you need more things to find how the usb works ? |
| 00:33:42 | gevaerts | So usb_detect() should be easy. Then you need usb_init_device() and usb_enable(). Those are basically just turning on and resetting the hardware. |
| 00:33:43 | toffe82 | the pin for usb detect on the mc13783 ? |
| 00:34:02 | | Join qwock [0] (n=4fd3f20a@gateway/web/cgi-irc/labb.contactor.se/x-d4c4146c919b1554) |
| 00:34:55 | sourcemaker | how can i restart my ipod? |
| 00:34:57 | jhMikeS | toffee82: I think that's in the register definitions unless it's wired differently. The ULPI pins are the ones used by the OTG controller I take it? |
| 00:35:04 | bluebrother | sourcemaker: check the manual ... |
| 00:35:21 | bluebrother | or the FAQ, whatever you like better |
| 00:36:52 | | Quit qwock (Client Quit) |
| 00:37:15 | amiconn | jhMikeS: It's definitely a COP cache problem. fire.rock works when run directly after boot |
| 00:37:40 | amiconn | ...and running greyscale.rock afterwards, I got a data abort on core 1 ... |
| 00:38:24 | * | amiconn wonders how to force the cop to invalidate its cache... |
| 00:38:52 | amiconn | That has nothing to do with your patch, btw, but with putting struct _grey_info into NOCACHEBSS |
| 00:39:09 | | Quit bluebrother ("switching ...") |
| 00:39:25 | amiconn | So your patch is fine |
| 00:39:35 | jhMikeS | toffe82: I think USB_OC (CS, c10) is handled by the OTG controller. I don't know about CSI_MCLK (RESET, K24). |
| 00:40:16 | | Join bluebrother [0] (n=Dom@rockbox/staff/bluebrother) |
| 00:41:46 | sourcemaker | reboot does not work... ipod hangs |
| 00:41:56 | | Join ZincAlloy [0] (n=d9eef959@gateway/web/cgi-irc/labb.contactor.se/x-68499ad41e004f5a) |
| 00:43:47 | bluebrother | define "hangs". Does the bootloader come up? |
| 00:45:21 | * | jhMikeS just trying to put the serial driver together correctly since it's so central on the S (and make it reusable for other imx targets). We'll probably want to use DVFS. |
| 00:45:21 | sourcemaker | I tried a game... but no reaction |
| 00:45:25 | | Join ddalton [0] (n=ddalton@124-168-53-116.dyn.iinet.net.au) |
| 00:45:44 | bluebrother | what exactly did you do? Did Rockbox start or not? |
| 00:45:46 | ddalton | hey anyone know where I can find the different hex firmware files? for h300? is that all I need? I don't seem to see them... |
| 00:46:08 | toffe82 | jhMikeS: the pins connected to the isp1504 are a6, a7.. (usbotg...) form the cpu |
| 00:46:23 | amiconn | jhMikeS: Hmm, I think the plugin loader needs to flush + invalidate the cop's cache *before* loading the plugin |
| 00:46:24 | jhMikeS | the IMX will likely make CPUFREQ_NORMAL just a "can vary dynamically" setting |
| 00:46:33 | amiconn | Otherwise it's too late |
| 00:46:37 | sourcemaker | bluebrother: yes... reockbox starts fine |
| 00:46:40 | bluebrother | ddalton: most links to iriver seem to be dead. rasher has a mirror: http://rasher.dk/rockbox/iriver-firmwares/ |
| 00:47:02 | bluebrother | sourcemaker: well, then get the manual and check how the game you're trying to use works. And how the button mappings are. |
| 00:47:05 | jhMikeS | amiconn: There's no built-in mechanism to do it though unless you can force some kind of interrupt that does it. |
| 00:47:20 | gevaerts | toffe82: how many pins are there ? ULPI can have an 8 bit or a 16 bit link |
| 00:47:31 | bluebrother | sourcemaker: and I really don't understand why you tell something about "reboot does not work". |
| 00:48:03 | jhMikeS | amiconn: it has to do it before attempting to execute code within the plugin buffer much like the invalidate for thread creation does but that's easy to get it to perform that |
| 00:48:23 | ddalton | bluebrother: thanks |
| 00:48:36 | amiconn | It has to do that before eve loading the plugin into the plugin buffer |
| 00:48:51 | amiconn | Doing it later might overwrite parts of the already loaded plugin iiuc |
| 00:49:02 | toffe82 | gevaerts: 8bits |
| 00:49:13 | toffe82 | the isp is 8 bits |
| 00:50:27 | jhMikeS | amiconn: it can if it has pending writes from something previous in the plugin buffer. threading flushes those out when the thread exits in thread.c. |
| 00:50:37 | | Join DavidSG [0] (n=Tordre@n098h202.wsr.mun.ca) |
| 00:50:44 | sourcemaker | great... now everthink is working well |
| 00:51:04 | amiconn | jhMikeS: Hmm. Then I wonder what pending writes are there in case of the greylib.... |
| 00:51:04 | DavidSG | Hello |
| 00:51:39 | amiconn | When running fire.rock directly after boot it works, but when running it after some other greylib plugin, it often does not |
| 00:52:05 | amiconn | But the greylib only uses uncached addresses for the cop... |
| 00:52:14 | | Quit ender` (" Eagles may soar, but weasels are seldom sucked into jet engines.") |
| 00:52:15 | gevaerts | toffe82: you might need to set PTS to 10 and PTW to 0 in the PORTSC0 register. Of course they might be correct by default |
| 00:52:22 | jhMikeS | amiconn: and only uncached code? |
| 00:52:39 | amiconn | Eh, no |
| 00:52:53 | amiconn | But code shouldn't change, so no write-back, right? |
| 00:53:09 | amiconn | Hmm, but code could be cached.... |
| 00:53:21 | jhMikeS | but it could see some lines as the previous plugin that was there |
| 00:54:11 | amiconn | I have no idea how to clean this up from within the plugin... |
| 00:54:37 | amiconn | Any code that I'll run on cop to flush the cache will go into the cache... |
| 00:54:58 | amiconn | That is, as long as it doesn't reside in iram - but that it shouldn't for normal plugins... |
| 00:55:04 | jhMikeS | besides a forceable interrupt and handler in the core I don't know either |
| 00:55:35 | amiconn | Hmm, I could use UNCACHED_ADDR for a function call... |
| 00:56:00 | amiconn | But cleaning it up in the core sounds like a better approach imho |
| 00:56:50 | sourcemaker | great work |
| 00:57:45 | DavidSG | I applied for a gsoc possition working on the WPS theme editor/ creator. I was wondering if anyone here has read my proposal and is willing to give suggestions on how I may improve it. |
| 00:59:12 | sourcemaker | rockbox is using linux right? |
| 00:59:35 | | Part ddalton |
| 00:59:39 | BigBambi | sourcemaker: No |
| 00:59:57 | BigBambi | sourcemaker: Rockbox is built from the ground up, it is NOT based on linux |
| 01:00 |
| 01:00:17 | sourcemaker | BigBambi: ok |
| 01:00:21 | BigBambi | Rockbox is all Rockbox |
| 01:00:24 | gevaerts | DavidSG: hello |
| 01:00:34 | | Quit waldo (Remote closed the connection) |
| 01:00:48 | * | jhMikeS wonders why it seems so far fetched not use use someone else's kernel :) |
| 01:00:49 | sourcemaker | BigBambi: maybe thats the difference... why rockbox is working well and ipodlinux not :-) |
| 01:01:09 | | Quit DA_Desktop (Read error: 104 (Connection reset by peer)) |
| 01:01:30 | BigBambi | Rockbox is designed specifically for embedded systems with all the constraints that brings, and is focussed on music playback |
| 01:01:49 | jhMikeS | amiconn: I never could get forced interrupts to work on COP, just CPU but perhaps something was simple missing |
| 01:01:59 | | Join ali_as_ [0] (n=as@80.229.21.128) |
| 01:02:10 | amiconn | What do you mean with forced interrupts? |
| 01:02:26 | gevaerts | DavidSG: I have read your proposal, but I'm quickly going over it again |
| 01:02:42 | jhMikeS | you force an interrupt to occur instead of waiting for the source to generate it |
| 01:02:54 | * | domonoky also take a look again at this app :-) |
| 01:03:04 | jhMikeS | the imx avic has that as well |
| 01:03:36 | amiconn | how? |
| 01:03:54 | DavidSG | gewaerts: hello and thank you for reading |
| 01:04:07 | amiconn | Hmm, is that the INT_FORCED_* stuff? |
| 01:04:38 | DavidSG | s/gewaerts/gevaerts/ |
| 01:04:54 | jhMikeS | amiconn: yes |
| 01:04:58 | | Part sourcemaker ("Kopete 0.12.5 : http://kopete.kde.org") |
| 01:05:44 | * | bluebrother has the UnZip class reporting its progress :) |
| 01:06:16 | domonoky | DavidSG: have you seen : http://www.rockbox.org/twiki/bin/view/Main/GSoCApplicationTemplate2008 ? |
| 01:06:48 | DavidSG | domonoky: No, I am sorry I haven't. |
| 01:07:39 | gevaerts | DavidSG: no worries. I usually post a comment to all applications with that link, but apparently I forgot that in your case. Sorry |
| 01:07:48 | toffe82 | gevaerts: thanks for the info but I don't program ,I just look the code sometimes, really have no time ;) |
| 01:08:15 | gevaerts | toffe82: ok. Just make sure that jhMikeS does it properly then ;) |
| 01:08:22 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 01:08:37 | DavidSG | I see i have some typing to do now. |
| 01:08:40 | | Join Rob2222 [0] (n=Miranda@p4FDCD502.dip.t-dialin.net) |
| 01:09:15 | toffe82 | gevaerts: you don't have a gigabeat S :) |
| 01:09:23 | domonoky | DavidSG: :-) feel free to extend your application according tothis :-) |
| 01:09:32 | gevaerts | DavidSG: it would be good, but we can still go over what's there now. You seem to have covered most of the technical things |
| 01:09:41 | gevaerts | toffe82: I don't have one, no :) |
| 01:09:49 | amiconn | jhMikeS: I'll try calling the isr with its uncached address when running on cop |
| 01:09:59 | toffe82 | gevaerts: do you want one ? |
| 01:10:09 | DavidSG | gevaerts: That would be good that way i can make allmy revisions at the same time. |
| 01:10:09 | amiconn | That should tell us whether the caching is the problem |
| 01:10:18 | jhMikeS | we need to be able to program the SDMA as well and I don't want to hand-assemble code so perhaps extending gas would be possible. the opcodes are fully documented. |
| 01:10:26 | gevaerts | toffe82: I want a lot of things, but... |
| 01:10:32 | amiconn | It's an ugly solution because code within uncached ram is slow... |
| 01:11:15 | toffe82 | gevaerts: :) |
| 01:11:21 | jhMikeS | amiconn: exactly why a "perform cache operation" service in the core would be very useful |
| 01:11:49 | amiconn | What would be a good way to signal completion back from such an isr? |
| 01:12:00 | Nico_P | gevaerts: c'mon, the gigabeast is the target of rockbox's future! :) |
| 01:12:01 | amiconn | (a forced interrupt to clear cop cache I mean) |
| 01:12:42 | gevaerts | DavidSG: first a few disclaimers : I'm not really involved in the WPS side of things here, and I have a tendency to concentrate on problems I see, and ignore the good stuff, so please don't let those get you down too much |
| 01:13:00 | gevaerts | Nico_P: What ? Not the Meizu ? markun lied to me ! |
| 01:13:00 | jhMikeS | amiconn: does it need to? if it's forced before enabling the timer interrupt, then it has completed by the time the timer interrupt is enabled. |
| 01:13:09 | domonoky | gevaerts: usb is good stuff !! :-) |
| 01:13:17 | jhMikeS | or by the time it can service that IRQ anyway |
| 01:13:26 | amiconn | jhMikeS: It has to be done by the plugin loader, even before loading a plugin... |
| 01:13:30 | Nico_P | gevaerts: you bet he did :) |
| 01:13:39 | *** | Saving seen data "./dancer.seen" |
| 01:13:41 | | Quit RoTtE (Read error: 104 (Connection reset by peer)) |
| 01:14:22 | DavidSG | gevaets: It is okay, i can handle criticism, besides how can i fix problems that i don't know about |
| 01:14:26 | | Quit ali_as (Connection timed out) |
| 01:15:01 | amiconn | jhMikeS: Afaik it's not possible to invalidate without flushing |
| 01:15:01 | gevaerts | DavidSG: One thing that could be a problem in the long term is that WPS syntax tends to change over time. If the WPS editor uses a different parser, that could make maintenance more difficult. |
| 01:15:19 | | Join mcuelenaere [0] (n=mcuelena@78-21-185-185.access.telenet.be) |
| 01:16:55 | Nico_P | yes, thr WPS utility should use rockbox's parsing code directly and ideally its rendering code too |
| 01:17:41 | Nico_P | that should also allow focusing on other things like usability |
| 01:18:13 | DavidSG | gevaerts: Then i would have to integrate the code of the parser into the program so that it will not become obsolete. |
| 01:18:14 | jhMikeS | amiconn: then you'll lose pending writebacks and corrupt memory |
| 01:18:25 | domonoky | DavidSG: do you have any idea which toolkit you want to use for the PC side of this WPS/Theme maker ? |
| 01:18:38 | amiconn | ? |
| 01:18:59 | | Join miepchen^schlaf_ [0] (n=miepchen@p54BF6799.dip.t-dialin.net) |
| 01:19:27 | Nico_P | DavidSG: it should be possible to compile the parser's code directly into the program |
| 01:19:38 | Nico_P | we already have a command line WPS checker that does just that |
| 01:19:41 | jhMikeS | if you simply invalidate without a flush first then anything modified that hasn't yet been written to ram will be lost |
| 01:19:45 | gevaerts | DavidSG: that would be best. Of course, that would make using java a bit problematic |
| 01:19:45 | DavidSG | domonoky: not in particular, do you have any suggestions? I would like to keep it as portable as possible. |
| 01:20:25 | * | domonoky suggests simple C for the backend, and Qt for the gui.. |
| 01:20:39 | jhMikeS | though I think it's possible by just specifying different bits in the operation |
| 01:20:56 | DavidSG | gevaerts: Yeah i was thinking that, unless it read the paser code like a script and based the rendered image off the strait c code, but that sounds a bit crazy. |
| 01:21:02 | gevaerts | DavidSG: rbutil, our GUI installer, uses Qt4 |
| 01:21:21 | domonoky | DavidSG: do you have any experience in rockbox theme ability ? |
| 01:21:22 | gevaerts | That would indeed just lead to madness |
| 01:21:23 | Nico_P | domonoky: what do you mean by backend? |
| 01:21:54 | Nico_P | it would be compiled into the binary, right? |
| 01:22:29 | * | domonoky sees the java keyword in the application.. so no Qt.. :-) |
| 01:22:31 | DavidSG | domonoky: I have looked at them script behind them before, but as for actually makeing them i can say i have none. |
| 01:22:36 | jhMikeS | the s3c and imx caches do similar things (invalidate only just tosses out everything in the caches and changes to ram are discarded) |
| 01:23:25 | bluebrother | java? How should that use the rb parser? |
| 01:23:36 | domonoky | Nico_P: with backend i mean the basic wps handling, which is mostly the rockbox wps code, compiled preferabilty as a lib.. |
| 01:23:58 | gevaerts | DavidSG: I have another request : when you're editting anyway, could you try to make shorter paragraphs ? These are a bit too long to find things in easily |
| 01:24:19 | * | jhMikeS thinks he needs to fully understand the mailbox system on 502x but that's no good for 5002 anyway |
| 01:24:20 | DavidSG | gevaerts: that sounds like the easier thing i can fix onmy application |
| 01:24:42 | gevaerts | It shouldn't be too hard, no :) |
| 01:25:22 | DavidSG | bluebrother: java may be reconsidered for my final applications |
| 01:25:33 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 01:26:10 | amiconn | jhMikeS: I know I would loose pending writes. Iirc you once said that invalidating without flusing doesn't work on PP |
| 01:27:10 | jhMikeS | I think MrH said that (or just didn't investigate it much). You can try with just the CACHE_OP_INVALIDATE flag set. |
| 01:27:56 | DavidSG | gevaerts: just so i have some idea: How much has the scripting for WPS has changed in the history ofthe project |
| 01:29:24 | Nico_P | DavidSG: some time ago it was changed to separate parsing and rendering but the syntax stayed the same. after that there were a few evolutions but no big change |
| 01:29:55 | Nico_P | the parser became stricter over time after it was added |
| 01:30:19 | * | jhMikeS also has a reason to have NOCACHE for objects be distinct from NOCACHE for say, declaring an lcd driver framebuffer |
| 01:30:22 | BigBambi | In my humble opinion, you really need an integrated app though. If the utility and the actual codebase are separate they will drift out of sync and the app will become useless |
| 01:30:50 | Nico_P | indeed |
| 01:31:14 | DavidSG | Yeah in my application i mentioned have 2 applications, a desktop version, and a rockbox on the go version. |
| 01:31:32 | | Join bughunter2 [0] (n=Jelle@ip565fbeaa.direct-adsl.nl) |
| 01:31:45 | DavidSG | i can also see that becoming a problem with code going out of sync. |
| 01:32:18 | BigBambi | Well either desktop or on target, I just mean your app should use the parsing code directly from Rockbox, and not be independent. |
| 01:32:22 | amiconn | jhMikeS: Calling the ISR via its uncached alias address does indeed fix the problem (made a mistake first so had to track it down) |
| 01:32:53 | bluebrother | hmpf, windows needs special treatment as usual :( |
| 01:33:02 | amiconn | The macro can be used for functions, but you need an explicit 'address of': UNCACHED_ADDR(&_timer_isr) |
| 01:33:15 | BigBambi | DavidSG: Whether it is on the PC or target is in this sense irrelevant. |
| 01:33:22 | DavidSG | BigBambi: I agree completely. |
| 01:33:24 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
| 01:33:34 | BigBambi | DavidSG: coolio :) |
| 01:33:55 | amiconn | ...otherwise gcc throws a weird error |
| 01:34:02 | jhMikeS | amiconn: can't allocate the function as NOCACHEDATA_ATTR? (to make sure all adresses are compiled properly) |
| 01:34:41 | gevaerts | bluebrother: is rbutil currently localized ? |
| 01:34:43 | DavidSG | BigBambi: do you know a way to integrate the c code from the parser into a java application. |
| 01:34:57 | BigBambi | DavidSG: I'm not coder I'm afraid |
| 01:34:58 | amiconn | jhMikeS: It's not needed here, and it's not a permanent solution anyway |
| 01:35:03 | bluebrother | gevaerts: yes |
| 01:35:03 | BigBambi | s/not/no |
| 01:35:20 | bluebrother | we just don't have too much translation contributions. |
| 01:35:34 | gevaerts | DavidSG: you would need jni for that, but I'm not really sure if that works well for this kind of usage |
| 01:36:04 | Nico_P | DavidSG: Qt would probably be better suited |
| 01:36:40 | | Quit mrfree (Read error: 110 (Connection timed out)) |
| 01:37:14 | gevaerts | Especially if you also use the c renderer (which I would strongly recommend). That would really only leave pure GUI code in java, with huge amounts of glue around it |
| 01:38:51 | DavidSG | i don't like the sound of this glue, maybe java would not be the best idea. |
| 01:38:52 | domonoky | to combine all he could use Qt Jambi (Qt for java) *hehe* :-) |
| 01:38:52 | jhMikeS | amiconn: there is one trick available - you can switch the current thread's core and switch it back (old_core = switch_core(new_core)) |
| 01:39:15 | DavidSG | domonoky: you do like this Qt |
| 01:39:42 | bluebrother | DavidSG: Qt is a great library, and it's quite fun to work with it. |
| 01:40:05 | BigBambi | DavidSG: You can look at RBUtil (the installation etc. util - that uses Qt) |
| 01:40:06 | * | domonoky works on rbuti (which is in Qt)l, so i would like the WPS/Theme to be easy integrateable :-) |
| 01:40:12 | DavidSG | I can't say i have had experience working with it, but i will do some research. |
| 01:40:35 | gevaerts | DavidSG: you mention that you have one rockboxable player. Does it actually run rockbox now ? |
| 01:40:38 | Nico_P | DavidSG: do you know C or C++? |
| 01:41:42 | bluebrother | I see one major advantage of Qt: it's C++ (so you can easily integrate existing C code) but still cross-platform (Windows, Mac, Linux) |
| 01:41:46 | DavidSG | gevaerts: i run my ipod with rockbox right now. but i dual boot because i like using the TV out fuction of the video player on the default firmware. |
| 01:42:02 | DavidSG | Nico_P: I know both. |
| 01:42:11 | amiconn | jhMikeS: Eh, is that reliable? Sounds like a dirty trick to me... |
| 01:42:15 | | Quit lee-qid (Read error: 110 (Connection timed out)) |
| 01:42:28 | Nico_P | DavidSG: then learning Qt shouldn't be much work |
| 01:42:30 | amiconn | Hmm, and atm I can't see how this would help |
| 01:42:46 | bluebrother | no. In fact I learned C++ doing Qt :) |
| 01:43:04 | amiconn | Unless the plugin loader does it, that is. But the plugin loader runs in the main thread... |
| 01:43:27 | jhMikeS | amiconn: it is reliable and will make the caches coherent |
| 01:43:42 | DavidSG | Sounds good, even if it just for consistancy sake, I think it will be better to use QT. |
| 01:43:44 | Nico_P | knowing java and very little Qt, my impression is that Qt basically adds a java like library to C++ |
| 01:44:02 | amiconn | So the plugin loader could hop to the cop & back to make sure both caches are flushed before loading a plugin? |
| 01:44:05 | gevaerts | DavidSG: have you built rockbox yourself before ? Ever played with the code ? |
| 01:44:17 | jhMikeS | amiconn: yes |
| 01:44:45 | bluebrother | Nico_P: if you're doing GUI Qt is _much_ nicer. |
| 01:44:54 | Nico_P | I can imagine that |
| 01:44:58 | * | bluebrother did a bit of Java GUI some time back and hated it. |
| 01:45:34 | jhMikeS | amiconn: right now it's only being used if wanting to use remove_thread on a thread executing on another core (when remove_thread is actually enabled for debugging) |
| 01:45:51 | * | amiconn can't comment much as he never used any of the gui toolkits, but just from reading I'd probably prefer GTK+ over Qt |
| 01:46:07 | gevaerts | Try curses :) |
| 01:46:20 | DavidSG | gevaerts: I built the code before, i had to use the album art patch, As for programing, i was thinking of writing a small app for it and did some research on it but never got arround to it, school work unfortuatly came first. |
| 01:46:30 | bluebrother | a curses interface to Rockbox would be interesting. |
| 01:47:09 | | Join sourcemaker [0] (n=sourcema@p5B2DFB6F.dip.t-dialin.net) |
| 01:47:23 | gevaerts | DavidSG: that's good to know. At least we don't have to worry about you being able to setup the build environment then :) |
| 01:48:04 | jhMikeS | ...and hopefully I didn't mess it up along the way (last test was ok). A logf build should remove the spc_emu thread without any crash. |
| 01:48:55 | DavidSG | No difficulty there, the only problem I would have is I don't have acess to a Mac computer so I guess I will need some help testing for that. |
| 01:49:06 | | Quit dabujo ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )") |
| 01:49:36 | BigBambi | DavidSG: Testing shouldn't be an issue |
| 01:49:41 | * | bluebrother just fixed a bug he introduces some days back :) |
| 01:49:42 | gevaerts | That's not a big problem. You should be able to find volunteers easiy |
| 01:49:43 | amiconn | jhMikeS: Do I really need old_core, or could I just assume the cores? |
| 01:49:48 | BigBambi | There are generally plenty of willing people in here |
| 01:49:54 | mcuelenaere | gevaerts: I'm trying to port the USB stack to the ZVM, but currently the only thing I get are bus resets and Windows recognizing an unknown device. Any ideas? |
| 01:51:19 | bluebrother | with a good GUI toolkit there shouldn't be much platform specific stuff. Just look at the rbutil sources, the aren't much #ifdefs. |
| 01:51:46 | gevaerts | mcuelenaere: what kind of device-side controller does it have ? |
| 01:52:01 | jhMikeS | amiconn: sure. old_core is just the core the calling thread was assigned to before the switch. switch_core to the same core is basically a nop. |
| 01:52:05 | mcuelenaere | Philips ISP1583 |
| 01:52:08 | DavidSG | Sounds excelent. I will have to look closely at that now. |
| 01:52:30 | mcuelenaere | |
icon identifies that the person is a core developer (has commit access).