00:17:39 | sammy | morning * |
02:35:25 | sammy | Confuse ... |
02:42:06 | sammy | Amm.....how to sent kernel into flash ? |
02:42:21 | sammy | serial port , or jtag ? |
02:42:45 | sammy | Guru ? Russ ? |
03:13:10 | BZFlag | either will work. |
03:46:00 | sammy | if kernel put into 0xc0800000 what is the 0xc0000000 until 0xc0800000 put ? |
06:18:42 | Russ | yes sammy? |
06:24:13 | Russ | I'm here |
06:24:58 | sammy | some question but not about blob want to asking you ... |
06:25:28 | sammy | the kernel start at 0xc0800000 , |
06:26:59 | sammy | and how is the ram fall into rank......I mean what is in the 0xc0000000 |
06:27:10 | sammy | until 0xc0800000 |
06:29:14 | sammy | and in 32MB ram , how is that to set ram address ...? |
06:31:59 | sammy | and by BZFlag say flash the kernel can use serial port or jtag ? but how did the Jflash know that's the kernel , not the blob or other file , and where is the kernel address in flash memory ? |
06:32:56 | sammy | sorry ask too much , can you to digest this ? |
06:59:00 | BZFlag | the kernel location in flash is set inside blob. It copies it out to ram before running it. |
06:59:27 | BZFlag | normally you use jtag to flash blob, and then use blob to flash kernel and filesystem. |
06:59:38 | BZFlag | blob knows where to put the kernel. |
07:00:01 | BZFlag | you can watch the serial console while blob is booting and it shows where it is copying from. |
07:04:25 | sammy | thanx Guru... |
07:06:55 | BZFlag | grins |
07:22:01 | Russ | sammy: the space between 0xc0000000 and the start of the kernel is used for a standard place to put things the kernel needs, like the command line |
07:22:40 | Russ | if you look at the sa1100 datasheet, you'll see that the first ram bank is at the physicall address 0xc0000000 |
07:27:49 | sammy | but where is the kernel start at flash memory ? |
07:28:04 | sammy | after the blob ...or |
07:28:20 | Russ | the kernel is stored more or less like a file in flash memory |
07:28:37 | Russ | blob stores it at some location, and then when blob starts, it copies the kernel into ram |
07:29:05 | sammy | the image file...(kernel) |
07:30:34 | sammy | so we don't need to care where is the kernel " file ", put in where of the flash memory ? |
07:31:03 | Russ | right |
07:31:23 | Russ | we are adding support for loading the kernel from other locations right now (like the network) |
07:32:40 | sammy | use Ethernet ? |
07:33:01 | Russ | yes |
07:34:48 | sammy | but if we don't care we only have 4MB flash memory , how do I know the kernel size won't pass over it ? |
07:35:51 | Russ | some #defines in blob tell it where to store the kernel in flash, and how big it can be |
07:42:17 | sammy | last question what is the table from 0xc0000000 to 0xd0000000 |
07:42:24 | Russ | ? |
07:42:28 | sammy | if I have 32 MB RAM . |
07:42:29 | Russ | look in the sa1100 manual |
07:42:41 | Russ | the first dram bank is at 0xc0000000 |
07:42:46 | Russ | the second at 0xc8000000 |
07:42:55 | Russ | the third at 0xd0000000 |
07:43:00 | sammy | 4 MB or 8MB |
07:43:03 | Russ | the fourth at 0xd8000000 |
07:43:21 | Russ | what table? |
07:43:46 | sammy | from 0xc0000000 to 0xc8000000 = 8 MB ? |
07:44:03 | Russ | pull out your calculator and see |
07:45:04 | sammy | and the kernel start in 0xc0800000 |
07:45:14 | sammy | ? |
07:45:34 | Russ | 0xc8000000 - 0xc0000000 = 0x8000000) |
07:45:41 | Russ | 0x80000000 = 128MB |
07:45:46 | Russ | er |
07:45:58 | Russ | 0x8000000 = 128MB |
07:47:05 | Russ | a quick look at blob/include/main.c shows: |
07:47:13 | Russ | /* where does the kernel live in RAM */ |
07:47:13 | Russ | #define KERNEL_RAM_BASE (0xC0008000) |
07:47:44 | sammy | so if 32MB RAM , in 0xc0000000 only use 8MB long , and next 8MB start at 0xc0800000 , and so .... ? |
07:48:00 | Russ | why would it? |
07:49:28 | sammy | because like you say , the first bank is at 0xc0000000 , second bank at 0xc8000000 |
07:49:46 | Russ | right, so each bank can hold up to 128MB of ram |
07:50:07 | Russ | it doesn't mean each bank needs to hold 128M of ram |
07:50:19 | Russ | thats why blob does that alias checking stuff |
07:50:39 | Russ | its just the same 8M of ram over and over again (16 times) |
07:52:10 | sammy | so if the LART define 32MB ...it must be like this... |
07:52:32 | Russ | it shows the layout in the boot messages of blob |
07:52:38 | Russ | you can also see it in the schematic |
07:54:29 | sammy | 0xc0000000 |
07:54:30 | sammy | 8MB long |
07:54:31 | sammy | . <no use> |
07:54:32 | sammy | . <no use> |
07:54:33 | sammy | . <no use> |
07:54:34 | sammy | 0xc8000000 |
07:54:35 | sammy | 8MB long |
07:54:36 | sammy | . <no use> |
07:54:37 | sammy | . <no use> |
07:54:38 | sammy | . <no use> |
07:54:40 | sammy | 0xd0000000 |
07:54:42 | sammy | 8MB long |
07:54:44 | sammy | . <no use> |
07:54:46 | sammy | . <no use> |
07:54:48 | sammy | . <no use> |
07:54:49 | Russ | nope |
07:54:50 | sammy | 0xd8000000 |
07:54:52 | sammy | 8MB long |
07:54:54 | sammy | . <no use> |
07:54:56 | sammy | . <no use> |
07:54:58 | sammy | . <no use> |
07:54:58 | Russ | only the first two banks are used |
07:55:00 | sammy | something like this right ? |
07:55:02 | sammy | ? why ? |
07:55:12 | Russ | why? because there are only 4 chips |
07:55:35 | Russ | one of the address lines is skipped, so I think its something like: |
07:55:56 | Russ | 0xc0000000: first 8M of first bank (region A) |
07:56:03 | Russ | shadow of region A |
07:56:14 | Russ | second 8M of first bank (region B) |
07:56:22 | Russ | shadow of region A |
07:56:27 | Russ | shadow of region B |
07:56:46 | Russ | er |
07:57:25 | Russ | 0xc0000000: A, A, B, B, A, A, B, B, A, A, B, B, A, A, B, B |
07:57:36 | Russ | the second bank is the same way: |
07:57:50 | sammy | and it must be like this ........... |
07:57:53 | Russ | 0xc8000000: C, C, D, D, C, C, D, D, C, C, D, D, C, C, D, D |
07:58:18 | sammy | 0xc0000000 |
07:58:19 | sammy | 8MB long |
07:58:20 | sammy | . <no use> |
07:58:21 | sammy | . <no use> |
07:58:22 | sammy | . <no use> |
07:58:23 | sammy | 0xc1000000 |
07:58:24 | sammy | 8MB long |
07:58:25 | sammy | . <no use> |
07:58:26 | sammy | . <no use> |
07:58:27 | sammy | . <no use> |
07:58:29 | sammy | 0xc8000000 |
07:58:31 | sammy | 8MB long |
07:58:33 | sammy | . <no use> |
07:58:35 | sammy | . <no use> |
07:58:37 | sammy | . <no use> |
07:58:39 | sammy | 0xc9000000 |
07:58:41 | sammy | 8MB long |
07:58:43 | sammy | . <no use> |
07:58:45 | sammy | . <no use> |
07:58:47 | sammy | . <no use> |
07:58:49 | sammy | check again , teacher , |
07:58:51 | sammy | right ? |
07:58:57 | Russ | no |
07:59:15 | Russ | the regions are shadowed over and over again |
07:59:27 | Russ | so anywhere you look in the first two bank, you find memory |
08:00:26 | sammy | ........? there is a knife in my head ...#$@%^#$% |
08:00:29 | Russ | CS majors seem to have trouble with the concept shadow regions and overlapping regions |
08:00:50 | Russ | ok, if it tries to access 0xc4000000 |
08:01:15 | Russ | it will put the address 0x4000000 on the address bus, and select bank 0 |
08:01:41 | Russ | so, A24 is active, all the other address lines are inactive |
08:01:55 | Russ | because its only a 16M chip, A24 isn't connected to anything |
08:02:06 | Russ | so the chip see address 0x0000000 |
08:02:16 | Russ | and returns the data there |
08:02:35 | Russ | so reading from location 0xc0000000 and 0xc4000000 give you the same data |
08:02:55 | Russ | because you are just changing A24, which isn't connected to anything |
08:03:31 | Russ | or is that A26 |
08:03:38 | Russ | yah, A26, sorry |
08:04:12 | Russ | the last address lines attached to the chip would be A23, but A24 is connected instead, and A23 isn't connected to anything (you can double check on the schematics) |
08:05:12 | Russ | so when you access 0xc0000000 and 0xc0800000, you are just toggling A23 (so you are accessing the same location |
08:05:35 | Russ | its only when A24 becomes active (0xc1000000) that you access the other half of the chip |
08:06:03 | Russ | the level of A25 and A26 don't effect the chip |
08:07:24 | Russ | (it returns the same data whether or not they are on or off) |
08:07:28 | Russ | same case with A23 |
08:08:47 | sammy | so A23 and A24 map each other , A25 and A26 map each ohter |
08:09:01 | Russ | ? |
08:09:10 | Russ | map eachother? |
08:09:43 | Russ | A23, A25, and A26 aren't connected to the DRAM chips at all |
08:09:55 | Russ | so their values don't matter |
08:10:01 | Russ | look at blob/src/memory.c |
08:10:06 | Russ | and the schematics |
08:10:13 | Russ | and the sa1100 datasheet |
08:11:28 | sammy | ok....... starting have a little concept on it |
08:11:39 | Russ | sleep |
08:12:50 | sammy | (((Thanx )))~~~~~~~(long) |
08:14:58 | sammy | maybe I should re check out of the source and data sheet... |
16:58:05 | | jamey was last seen on #handhelds.org 3 days, 1 hours, 11 minutes and 40 seconds ago, saying: DragonEagle: we have a bunch of safeguards in the load bootldr command: it checks bootldr CRC, architecture, and link address. It would be fine to do this from Linux with an app that performs similar verification. [Tue Sep 4 16:46:25 2001] |
16:58:05 | Russ|werk | ibot: seen jamey |
21:18:14 | ed__ | anyone around |
21:18:15 | ed__ | la la la la al |
21:18:23 | ed__ | wakeup! |
21:18:46 | badd00d | noone home. |
21:18:54 | ed__ | goddamdmit |
21:19:01 | ed__ | i wanna chew out erik or jd |
21:19:01 | ed__ | :D |
21:20:17 | Russ|werk | jdb and erikm? |
21:20:30 | Russ|werk | what'd they do? |
21:21:21 | ed__ | built the lart |
21:21:30 | ed__ | so my disk keeps saying the cmd times out |
21:23:31 | ed__ | anyone have disk drive ron there lart |
21:23:59 | Russ|werk | I don't know jack about the LART IDE bus, except that its very simple |
21:24:25 | Russ|werk | unfortunately, its about midnight where they are, so they are probably gone |
21:24:57 | ed__ | yeah i know |