| 00:51.38 | *** join/#edev redblue (i=star@ppp109.108-253-207.mtl.mt.videotron.ca) |
| 01:04.39 | *** join/#edev openocdn00b (n=ddkd@c-98-226-129-230.hsd1.in.comcast.net) |
| 01:05.49 | openocdn00b | Does anybody know how to handle interrupts using the s3c2440 ARM9 SOC? It does not support address remaping or exception vector remaping |
| 01:06.00 | openocdn00b | so how do I handle interrupts from sdram? |
| 01:06.28 | openocdn00b | they keep going to address 0x000 +offset but that's my vector table in flash |
| 01:06.44 | openocdn00b | I want it to go to my vector table in sdram at 0x30000000 |
| 01:12.13 | openocdn00b | I need this mostly when I am debugging since all my code is in sdram and flash could be erased or garbage etc |
| 01:12.36 | openocdn00b | in that case I do not know what to do since interrupts keep going to that fixed address |
| 01:14.39 | openocdn00b | I would love just to remap sdram to address 0x000 after getting sdram ready but this processor does not provide this functionality |
| 01:19.51 | MonMotha | openocdn00b: I said before, that chip s a full MMU |
| 01:19.57 | MonMotha | you can run Linux on it |
| 01:20.03 | MonMotha | so clearly it supports all that |
| 01:23.01 | openocdn00b | oh you have said that before? I missed it |
| 01:23.09 | joe_bleau | Why not just program the MMU to put sdram at 0? |
| 01:23.21 | openocdn00b | yes, it does have an MMU but I do not want/need to use it |
| 01:24.03 | openocdn00b | so there is no other way? I HAVE to use the MMU? |
| 01:24.29 | openocdn00b | others ARMs like LPC's ARM7 will let you just remap the address |
| 01:24.35 | openocdn00b | they do not have MMUs |
| 01:24.38 | openocdn00b | or MPU |
| 01:27.14 | joe_bleau | I'm not up on arm9, but can you enable the caches without the MMU? |
| 01:27.40 | joe_bleau | Seems like I had to use the MMU on the webpal to activate the cache. |
| 01:29.16 | openocdn00b | hmm... really? I did not know that |
| 01:29.32 | openocdn00b | getting the cache working was my next step after getting interrupts working |
| 01:30.11 | openocdn00b | that kinda hurts cause I have never used a MMU and know little about them |
| 01:30.49 | joe_bleau | Just checked. On the old 710T, you had to enable the MMU to use the cache. |
| 01:30.59 | joe_bleau | LIke I said, I'm not up on the arm9 arch. |
| 01:31.10 | openocdn00b | that is why I am avoiding it since I want this code to also run in systems without MMU |
| 01:33.59 | openocdn00b | The Atmel AT91SAM7 has a remap command that will remap the memory for you but I guess since this chip has an MMU they did not bothered in adding such a thing |
| 01:35.44 | joe_bleau | Could you build a jump table in flash at 0, adding one level of indirection? |
| 01:36.06 | openocdn00b | while I learn about MMU how can I do a long jump from flash into SDRAM in my flash vector table? I tried B =InterruptDispatcher and it generated some crazy code that does not work |
| 01:36.28 | openocdn00b | joe_bleau: yeah for now that is what I am going to do |
| 01:37.50 | openocdn00b | I say for because while using the debugger that is not going to cut it since all my code will be in SDRAM and flash could be in any state at that time including blank or currupted data |
| 01:38.08 | openocdn00b | or it could have a different program all together |
| 01:40.12 | joe_bleau | Oh, 920T is a bit different. Looks like you can run icache with no mmu, but dcache requires mmu. |
| 01:40.15 | openocdn00b | ARM920T is the only core that supports MMU :-( so all the other ARM9TDMI etc won't be able to run my code |
| 01:56.51 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 02:07.59 | MonMotha | openocdn00b: I suspect that many ARM9TDMI implementations will provide a remap option similar to AT91SAM7 |
| 02:08.11 | MonMotha | basically a poor man's |
| 02:08.14 | MonMotha | MMU |
| 02:08.24 | *** join/#edev dfarnsworth (n=dfarnswo@65.200.49.156) [NETSPLIT VICTIM] |
| 02:08.25 | MonMotha | but since 920T has a full MMU, no remap command is provided. You just use the MMU. |
| 02:14.03 | MonMotha | hence, you may need to have your interrupt remapping be handled in an arch dependent manner |
| 02:14.06 | MonMotha | that sort of thing is normal |
| 02:14.26 | MonMotha | not all ARM9TDMI are likely to provide the same semantics for interrupt remapping anyway |
| 02:18.11 | Madsy | Afaik, Neither ARM7 nor ARM9 supports remapping of the exception vectors. |
| 02:18.23 | Madsy | Though perhaps SoC implementations vary. I'm not sure. |
| 02:18.56 | joe_bleau | I thought the remap was outside the core and implementation dependant. |
| 02:24.37 | Madsy | joe_bleau: armarm mentions low and high offsets for the exception vectors |
| 02:24.54 | Madsy | 0x00000000 or 0xFFFF0000 |
| 02:30.57 | MonMotha | Madsy: correct. It's not a function of the CPU, but the SoC |
| 02:31.02 | MonMotha | AT91SAM7 has a remap option, for example |
| 02:31.15 | Madsy | openocdn00b: If your exception vector table is at a totally different address offset than 0x0, how does the system even boot? |
| 02:31.17 | MonMotha | now, it may be that they modify the core to do it; I don't know |
| 02:31.46 | MonMotha | many of these SoCs are synthesizable cores, after all |
| 02:31.58 | Madsy | openocdn00b: Put the exception table entries at 0x0, and make them branch to your handlers. |
| 02:32.24 | MonMotha | you can emulate this in software |
| 02:32.25 | Madsy | By either using B or LDR |
| 02:32.51 | MonMotha | put your boot-time exception handlers in the ROM, but have each handler check for a valid table in RAM. If it sees one, it jumps into the one in RAM instead |
| 02:33.01 | MonMotha | costs you a cycle or two, but it does the job if that latency is OK |
| 02:33.13 | MonMotha | (ok, more like 5-6 cycles, but whatever) |
| 02:34.01 | Madsy | Heh, my GBA interrupt handler uses self-modifying code, so it can't be in ROM ;-) |
| 02:35.07 | MonMotha | Madsy: I think that's the problem openocdn00b is having |
| 02:35.34 | MonMotha | needs to have a valid exception handler set at boot-time (before things are in RAM), but wants normal operation to have exception handlers in RAM |
| 02:35.40 | MonMotha | that's what I get out of all this, at least |
| 02:39.33 | Madsy | Right. So his RAM bank offset 0x30000000 is out of range for a branch? |
| 02:39.43 | Madsy | That sounds kind of weird. |
| 02:41.01 | Madsy | B,BL can branch to +- 32 MB |
| 02:41.22 | Madsy | It doesn't sound like he has ARMv4T, which gives you BX |
| 02:42.23 | MonMotha | Madsy: I think he was looking for a hardware "remap" option which forces the CPU through address trickery to go directly into RAM |
| 02:42.37 | MonMotha | check out the Atmel AT91SAM7X256 for an exmaple |
| 02:43.24 | Madsy | Right. |
| 02:46.20 | Madsy | The GBA is kind of funny in this regard. The BIOS branches to 0x08000000, which Flash ROM. But the memory is dead slow. |
| 02:46.41 | Madsy | So I ended up injecting code to faster memory areas. |
| 02:47.06 | MonMotha | ah |
| 02:47.12 | Madsy | In order to create the executable image on descending addresses. |
| 02:47.30 | MonMotha | the idea of the remap on the Atmel chip is to let you change interrupt handlers at runtime easily |
| 02:47.51 | Madsy | Yeah. Luckily the GBA BIOS takes care of all the handlers :-) |
| 02:47.52 | MonMotha | since normally the table would reside in flash |
| 02:48.02 | Madsy | Except for the IRQ handler, if you turn it on. |
| 02:48.06 | MonMotha | heh, no BIOS or anything of the like in this case |
| 02:48.09 | MonMotha | bare metal |
| 02:48.52 | Madsy | Well, "bios" is kind of confusing. It's a read-only part of the work-ram. Reading from the area gives you garbage. |
| 02:49.21 | Madsy | Where the bootloader and a trivial SWI and IRQ handler is stored. |
| 02:49.43 | Madsy | Even more weird, it's mirrored a few times. |
| 02:50.13 | Madsy | s/confusing/misleading |
| 02:50.30 | MonMotha | fun |
| 02:50.39 | Madsy | Indeed. |
| 02:50.41 | MonMotha | I've found lots of game consoles are like that |
| 02:50.48 | MonMotha | ever looked at the memory map of a Playstation? :) |
| 02:51.05 | Madsy | Only community made documentation. |
| 02:51.17 | MonMotha | it's MIPS, so there's already the whole cacheable/non-cacheable/supervisor/user address thing going on |
| 02:51.21 | MonMotha | oh, I don't have any official docs |
| 02:52.01 | Madsy | I've searched for PSX tools for a long time. Seems like the community is extinct. |
| 02:52.09 | MonMotha | well, the console is pretty old at this point |
| 02:52.24 | Madsy | I have a PSX with a serial port. Modded as wel. |
| 02:52.25 | Madsy | l |
| 02:52.31 | MonMotha | and it wasn't exactly a marvel of hardware for its time |
| 02:52.34 | MonMotha | just had very good marketing |
| 02:52.49 | Madsy | And I know some basic MIPS from coding for the PSP. |
| 02:53.40 | Madsy | IIRC, the hardware was okay taking the price into account. |
| 02:53.46 | MonMotha | eh, it was alright |
| 02:53.50 | *** join/#edev moi1234 (n=moi@ip70-179-18-67.sd.sd.cox.net) |
| 02:53.55 | openocdn00b | thank you for the comments guys |
| 02:53.57 | Madsy | Sure, the CPU sucked, but it did have a vector co-processor. |
| 02:54.01 | openocdn00b | I was gone there for a min |
| 02:54.25 | openocdn00b | what I got from this is to use the MMU :-( |
| 02:54.26 | MonMotha | it wasn't bad, but it was far from an amazing machine |
| 02:54.57 | openocdn00b | for now I will try to make my vector table in flash point to where my vector table in ram is going to be |
| 02:55.01 | Madsy | MonMotha: Show me a console you believe is amazing then ;-) |
| 02:55.11 | joe_bleau | Atari 2600? |
| 02:55.20 | Madsy | haha |
| 02:55.20 | openocdn00b | but for some reason my code is not compiling when I do a B |
| 02:55.52 | MonMotha | Madsy: good point |
| 02:56.04 | MonMotha | I guess I'm comparing it to my other hobby which is video arcade games |
| 02:56.08 | joe_bleau | I've entertained the idea of hacking some 2600 code at times. |
| 02:56.32 | MonMotha | until ~1997, they were pretty much always far more advanced than just about anything an individual would buy for gaming other than a totally decked out PC |
| 02:56.45 | MonMotha | then they all started to use consoles (oddly, mostly Playstations) and PCs |
| 02:57.12 | MonMotha | I just get a kick out of comparing, say, a Playstation to a Midway Seattle |
| 02:57.36 | Madsy | MonMotha: I guess the hardware in TV consoles is compromise between price point and features. |
| 02:57.53 | MonMotha | Madsy: pretty much. The video arcade people didn't care as much about cost |
| 02:58.06 | MonMotha | take a look inside a Daytona USA machine some time if you want to prove that :) |
| 02:59.04 | Madsy | For the time is was made, Nintendo did a genius thing when they made it possible to add extra memory banks in game cartridges. |
| 02:59.24 | Madsy | it* |
| 03:00.08 | Madsy | The built-in memory in the NES was enough for most early games to run. And it made the system cheap to build. |
| 03:00.17 | Madsy | s/build/assemble |
| 03:00.52 | Madsy | And because game companies could extend the system's features, it even expanded the longevity of the system. |
| 03:01.06 | Madsy | The last NES game was made in 1995, afaik. |
| 03:02.53 | Madsy | They even took it further with the SNES |
| 03:03.05 | Madsy | Cartridges could even add co-processor interfaces. |
| 03:03.16 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 03:03.46 | MonMotha | Madsy: IIRC, some of the very late Neo Geo games actually had a processor on the carts that the game ran on. The main CPU was basically told to idle and give up the bus. |
| 03:03.49 | Madsy | You would be crazy to do something like that nowadays though.. |
| 03:04.12 | Madsy | Haha.. the NeoGeo? |
| 03:04.20 | Madsy | I remember mine loved to suck batteries dry. |
| 03:04.26 | MonMotha | of course, if you've ever seen a Neo Geo cart, you'd know there's enough pins (and yes, they pretty much put the entire CPU bus on it) |
| 03:04.33 | Madsy | How many did it use anyway? Six or eight? |
| 03:04.33 | MonMotha | not the pocket, the MVS/AES |
| 03:04.37 | Madsy | Aha. |
| 03:04.56 | MonMotha | I've got a 1 slot and a 4 slot MVS in my basement :) |
| 03:07.18 | *** join/#edev miknix (n=miknix@gentoo/developer/miknix) |
| 03:12.09 | *** join/#edev dijenerate (n=dijenera@69.73.211.40) |
| 03:13.35 | sunrunner20 | grr |
| 03:56.44 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 04:09.30 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |
| 04:49.20 | *** join/#edev moi1234 (n=moi@ip70-179-18-67.sd.sd.cox.net) |
| 04:59.43 | *** join/#edev agaffney (n=agaffney@gentoo/developer/agaffney) |
| 05:34.20 | *** join/#edev moi1234 (n=moi@ip70-179-18-67.sd.sd.cox.net) |
| 06:18.03 | *** join/#edev Ian_Daniher|XO (n=olpc@69.61.230.246) |
| 07:17.19 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 08:00.27 | *** join/#edev openocdn00b (n=ddkd@c-98-226-129-230.hsd1.in.comcast.net) |
| 08:04.55 | *** join/#edev redblue (i=star@ppp045.108-253-207.mtl.mt.videotron.ca) |
| 08:06.02 | *** join/#edev linac (n=lin@121.201.98.72) |
| 08:28.18 | *** join/#edev moi1234 (n=moi@ip70-179-18-67.sd.sd.cox.net) |
| 09:00.59 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-164-205-19.dllstx.fios.verizon.net) |
| 09:07.30 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 09:16.28 | *** join/#edev mRCUTEO (n=IRCLUNAT@96.9.131.182) |
| 09:16.32 | *** part/#edev mRCUTEO (n=IRCLUNAT@96.9.131.182) |
| 09:16.59 | *** join/#edev sunrunner20|prom (n=jamesdoe@pool-70-104-23-220.dllstx.fios.verizon.net) |
| 10:05.50 | *** join/#edev lyakh (n=lyakh@p57BD2A90.dip0.t-ipconnect.de) |
| 11:10.02 | *** join/#edev DrZimmerman (n=theo@77-56-225-121.dclient.hispeed.ch) |
| 11:14.15 | *** join/#edev das_plague (n=prpplagu@ppp-70-244-162-101.dsl.rcsntx.swbell.net) [NETSPLIT VICTIM] |
| 11:14.15 | *** join/#edev keesj (n=keesj@ip49-193-210-87.adsl2.static.versatel.nl) |
| 11:33.34 | *** join/#edev steliosk (n=Stelios@ipa107.2.tellas.gr) |
| 12:08.12 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 12:17.28 | *** join/#edev dijenerate (n=dijenera@69.73.211.40) |
| 12:51.29 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-164-205-212.dllstx.fios.verizon.net) |
| 13:10.41 | *** join/#edev likewise_ (n=chatzill@82-171-51-231.ip.telfort.nl) |
| 13:35.37 | *** join/#edev redblue (i=star@ppp087.108-253-207.mtl.mt.videotron.ca) |
| 14:45.37 | *** join/#edev GPSFan (n=kenm@64.92.143.179) |
| 14:45.37 | *** mode/#edev [+o GPSFan] by ChanServ |
| 15:05.58 | *** join/#edev chouimat (n=dieu@kde/developer/chouinard) |
| 15:42.46 | *** join/#edev sunrunner20|prom (n=jamesdoe@pool-71-97-107-136.dllstx.dsl-w.verizon.net) |
| 16:00.01 | *** join/#edev dijenerate (n=dijenera@69.73.211.40) |
| 16:09.33 | *** join/#edev damien (n=damien@brc29-1-82-245-194-55.fbx.proxad.net) |
| 16:34.58 | *** join/#edev lyakh (n=lyakh@p57BD2A90.dip0.t-ipconnect.de) |
| 16:36.18 | Ian_Daniher|XO | g1powermac: ping - pls PM me with your address stat |
| 16:46.16 | *** join/#edev Ian_Daniher|XO (n=olpc@69.61.230.246) |
| 17:08.18 | *** join/#edev sunrunner20 (n=jamesdoe@pool-96-226-67-88.dllstx.fios.verizon.net) |
| 17:57.34 | *** join/#edev Bluenarf (n=Paul@apollo.paulsnet.org) |
| 18:25.44 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |
| 19:21.54 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 19:35.29 | *** join/#edev redblue (i=star@ppp153.108-253-207.mtl.mt.videotron.ca) |
| 19:45.37 | Mirell | Hmm.. |
| 19:46.01 | g1powermac_PB | yay, my _fourth_ power adapter for my powerbook came in today |
| 19:47.30 | Mirell | Ouch. |
| 19:48.31 | g1powermac_PB | though I can't blame apple for all of them, I never bought an apple branded adapter after the original one had a melt down |
| 19:48.55 | g1powermac_PB | (and yes, it literally melted its own power cord on the DC side) |
| 19:50.48 | g1powermac_PB | though I'm happy it didn't start sparking like I've read about for the apple power adapters of that era |
| 21:12.57 | ZeZu | think its time to fix the powerbook, cables dont just melt |
| 22:00.08 | *** join/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 22:23.27 | g1powermac | ZeZu, actually, there was a major design flaw with the older apple adapters that caused them to melt and spark |
| 22:24.14 | ZeZu | and its not been fixed that you've gone through that many of them ? |
| 22:24.19 | ZeZu | and there was no recall ? |
| 22:25.09 | g1powermac | there might have been a recall, but the others that died were cheap generic branded ones, not apple branded |
| 22:28.08 | g1powermac | and the generic ones didn't melt, they just quit working |
| 22:30.27 | ZeZu | no surprise there |
| 22:33.44 | g1powermac | http://theappleblog.com/2005/08/13/powerbook-65w-ac-adaper-repair/ |
| 22:35.04 | g1powermac | http://www.appledefects.com/?p=220 |
| 22:36.53 | g1powermac | though the odd part is mine melted a few inches away from the base of the adapter |
| 22:38.29 | g1powermac | and here's the class action suit that was over these failing adapters: http://forums.macrumors.com/showthread.php?t=481790 |
| 22:40.42 | g1powermac | ooo, video of one failing: http://www.applesource.com.au/macbook/soa/Video-Sparking-PowerBook-adapter/0,2000070811,339287560,00.htm |
| 22:54.44 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 23:09.21 | Mirell | Sigh. |
| 23:12.32 | *** join/#edev redblue (i=star@ppp055.109-253-207.mtl.mt.videotron.ca) |
| 23:28.07 | *** join/#edev agaffney (n=agaffney@gentoo/developer/agaffney) |
| 23:34.10 | *** join/#edev balister_ (n=balister@pool-71-171-21-6.nwrknj.east.verizon.net) |
| 23:37.07 | *** join/#edev Crofton (n=balister@pool-71-171-21-6.nwrknj.east.verizon.net) |
| 23:44.49 | *** join/#edev miknix (n=miknix@gentoo/developer/miknix) |