| 18:22:46 | erikm | hi |
| 18:36:28 | prpplague | howdy |
| 18:37:23 | prpplague | erikm: are you available for questions about blob? |
| 18:52:08 | erikm | prpplague: yes |
| 18:53:29 | prpplague | i'm new to blob, the sa-1100 based device i'm trying to get blob running on has a write protected bootload thats not linux friendly |
| 18:53:59 | prpplague | i'd like to have the original bootloader call blob at a different flash address |
| 18:54:41 | erikm | is the original bootloader able to call a program at any location in memory? |
| 18:55:12 | prpplague | yes, i've linked the blob-rest to a flash address and can get it to run somewhat |
| 18:55:38 | prpplague | the problem i think i'm having is the original bootloader is turning on the mmu and doing some mapping |
| 18:55:49 | erikm | aieee |
| 18:55:59 | erikm | what platform is it? |
| 18:56:03 | prpplague | do i need to turn the mmu off before getting blob running? |
| 18:56:11 | erikm | (and what bootloader) |
| 18:56:13 | prpplague | the ELF board from InHand Electronics |
| 18:56:28 | prpplague | its based on the old Omnimeter platform |
| 18:57:03 | erikm | hmm |
| 18:58:13 | erikm | blob doesn't care about the MMU as long as it has a one-to-one physical-virtual mapping |
| 18:59:44 | prpplague | thats the problem flash normally resides at 0x00000000 but after mmu is started the flash is relocated to 0x04000000 and dram at 0x00000000 |
| 18:59:56 | erikm | that's sick |
| 19:00:00 | prpplague | i know |
| 19:00:17 | prpplague | i've got some assembly to un-do this |
| 19:00:23 | erikm | oh, that's good |
| 19:00:43 | erikm | the solution should be quite easy: |
| 19:01:04 | erikm | make a separate blob-start code that disables the MMU |
| 19:02:11 | erikm | after disabling the MMU, jump to the 0xc0000400 (start of trampoline.S) and you're in business |
| 19:04:07 | prpplague | what about the fact that the blob with not be located at 0x00000000 in flash but rather at 0x00020000 ? |
| 19:04:45 | erikm | prpplague: that shouldn't be a real problem. blob-rest doesn't know about that |
| 19:05:00 | prpplague | ohh, gotya |
| 19:05:00 | erikm | prpplague: blob-rest assumes it is located at 0xc0000400 |
| 19:05:25 | erikm | it only starts to matter as soon as you're trying to write the flash |
| 19:05:43 | erikm | but I think the most important thing right now is to get it running at all |
| 19:07:01 | prpplague | right, what about when the get_memory_map function is called in memory.c won't this over right the code at 0xc0000400 ? |
| 19:07:59 | erikm | no, it carefully doesn't touch that part |
| 19:08:08 | erikm | (hey *I* coded it :) |
| 19:08:35 | prpplague | lol |
| 19:09:15 | erikm | the memory is scanned in 1MB chunks starting at 0xc0000000, so it jumps over the stuff at 0xc0000400 |
| 19:10:43 | prpplague | ahh,so it only writes a zero at the base of each one meg chunk |
| 19:10:51 | erikm | yes |
| 19:11:29 | erikm | and the memory at 0xc0000000 isn't used anyway so we can touch it without problems |
| 19:12:31 | prpplague | ok two more questions and i'll leave you alone... |
| 19:12:43 | prpplague | in the README on porting it refers to: |
| 19:12:46 | prpplague | #if defined FOOBAR |
| 19:12:46 | prpplague | mdcas0: .long 0x1c71c01f |
| 19:12:46 | prpplague | mdcas1: .long 0xff1c71c7 |
| 19:12:46 | prpplague | mdcas2: .long 0xffffffff |
| 19:12:46 | prpplague | mdcnfg: .long 0x0334b21f |
| 19:12:47 | prpplague | #endif |
| 19:13:07 | prpplague | what are these and where do the values come from? |
| 19:14:27 | erikm | that are the memory timing parameters. it's explained int reference #1 (see the comments at the top of the file) |
| 19:14:43 | erikm | you won't need them because the hostile bootloader will set them for you |
| 19:15:29 | prpplague | ahh, must have missed it, also there is in the memsetup.c also is liste mcs0 which is not referenced in the README |
| 19:16:50 | erikm | yeah, because that's for the sa1110, not for the sa1100 |
| 19:17:11 | erikm | I'm currently rewriting the sa1110 memory setup |
| 19:17:18 | prpplague | ahh, so when i include my new entry, don't include mcs0 |
| 19:17:26 | erikm | (or actually: writing it from scratch) |
| 19:17:31 | prpplague | alright, one left... |
| 19:17:58 | prpplague | when figuring the clock speed 0x09 is 190mhz is 0x0a 206.7 ? |
| 19:18:27 | erikm | if you can't get rid of the evil bootloader, you don't need to setup the memory anymore |
| 19:18:37 | erikm | so you shouldn't have to bother yet |
| 19:18:59 | prpplague | ahh, thats right! |
| 19:20:11 | prpplague | just for reference... you might want to include in the README a table of hex values that correspond to clock speed |
| 19:20:40 | prpplague | thanks erik, i really appreciate the info |
| 19:20:52 | erikm | why? it is documented in the SA1100 manual |
| 19:22:20 | prpplague | i didn't know that, i'm still a sa newbie |
| 19:24:33 | prpplague | i have the architectural reference manual for arm, what would it be listed under? |
| 19:25:21 | erikm | get it from developer.intel.com |
| 19:25:51 | prpplague | never mind, found it |
| 19:26:34 | erikm | it's zipped, it's still huge, but it's good |
| 19:26:52 | erikm | (though arm arm rev5 is also huge) |
| 19:27:28 | prpplague | i've got the books from one of the old intel sa-1100 multimedia boards |
| 19:27:58 | prpplague | if you ever find yourself around tyler,tx i'll buy you a steak and a beer, thanks for the help |
| 19:28:23 | erikm | I think I need to keep a notebook with all people who want to buy me a beer :) |
| 19:29:49 | prpplague | sounds like a nice app for a handheld device, "hmm i'll be in the xxx area, who owes me a beer? let me check my handheld..." |
| 19:30:10 | prpplague | owe-a-beer-lart |
| 19:32:13 | erikm | heh :) |
| 19:52:33 | prpplague | this is an incorrect syntax right? |
| 19:52:36 | prpplague | ldr r4, =0x000FFFFF |
| 19:53:23 | erikm | what do you want to do? |
| 19:54:30 | prpplague | this was a cut-n-paster from the code i was sent to turn the mmu maping off, however this line is getting a syntax error during the compile |
| 19:56:10 | erikm | I think you either want ldr r4, 0x000ffff, or ldr r4, #0x000ffff |
| 19:56:17 | erikm | but the last one wont work |
| 19:56:31 | erikm | ehm, sorry, it will |
| 19:57:50 | prpplague | i think this code was previously used on a m$ setup |
| 19:59:05 | erikm | I think you just want ldr r4, 0x000ffff |
| 19:59:17 | erikm | (load r4 with the contents of memory location 0x000ffff) |
| 19:59:20 | prpplague | in startup.S, in the copy_loop, what determines where the code comes froms |
| 20:00:00 | prpplague | ya, thats what it was, i'm looking at a ref for intel arm development |
| 20:00:02 | erikm | see comments just above copy_loop |
| 20:01:59 | prpplague | ya i see this: |
| 20:02:03 | prpplague | /* get a clue where we are running, so we know what to copy */ |
| 20:02:03 | prpplague | andr0, pc, #0xff000000/* we don't care about the low bits */ |
| 20:02:24 | prpplague | but i not sure i understand what is happening here... |
| 20:03:58 | erikm | it ands the pc with 0xff000000 and puts it in r0 |
| 20:04:21 | erikm | so r0 effectively contains the upper 8 bits of the pc |
| 20:04:48 | erikm | which means that it contains 0x00000000 when running from flash, or 0xc0000000 when running from RAM |
| 20:07:24 | prpplague | so if hardcoded r0 with the location 0x0002000 it would copy from flash to ram properly, a better way would be to add a flag or something for non-standard locations |
| 20:08:02 | erikm | hardcoding should do for the time being |
| 20:08:17 | prpplague | thanks once again |
| 20:12:36 | erikm | goes zzz |
| 20:12:37 | erikm | bye |
| 23:44:48 | prpplague | howdy BZFlag |