From mboxrd@z Thu Jan 1 00:00:00 1970 From: My-Hong Vuong Date: Tue, 17 Dec 2002 19:04:41 +1100 Subject: [U-Boot-Users] booting linux from u-boot - help! Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de I used smc1 because i was unable to get ppcboot running with smc2. our smc1 is at 9600. with the cache, i've disabled MSR_DR in head_8xx.S which then seems to get to start_here fine. but inserting the same code just before early_init doesn't seem to work... the assembly I'm using is : lis r25, 0xaaaa ori r25, r25, 0xaaaa lis r26, 0x8100 ori r26,r26,0x0000 stw r25, 0(r26) where r25 is the pattern I want to write into address 0x81000000. I've used r25 and r26 because I can't see them being used anywhere in the code... I'm not sure how do do it otherwise (i.e. restoring the original register values) any other ideas would be muchly appreciated, My Hong Vuong >>> Murray Jensen 12/17/02 04:24pm >>> On Tue, 17 Dec 2002 14:17:50 +1100, My-Hong Vuong writes: >Thanks for the prompt response. My pleasure. >The board I'm working with does not utilise SDRAM, rather SRAM - Samsung >K1S321615M, which does not utilise burst access - our ORx has Burst >Inhibit turned on - it does not support burst accesses. This shouldn't >pose a problem then, should it? No you are correct, you simply won't do burst transfers on the bus which means it can't be the problem. >We have CPU6 turned off as we're using an MPC860T Rev.D.4. OK >Switching >the Copyback on and off seem to have no effect. OK >also, for the console, we have it set at SMC1, standard/generic >serial... SMC1 - therefore no modem control (this was going to be my next guess). By the way, don't try to set the baud rate too high - it won't work on and SMC. A nice easy 9600 is good to use. >i'm unclear as to what you mean by: >you must have a virtual memory mapping set up once the mmu is turned on >- the head.S file sets one up for the IMMR and the first 8M of RAM until >the kernel takes over. > >Do you mean that BRx and ORx need to be set up again? (btw, i'm a newbie >at this stuff) No, a virtual memory mapping in the MMU. Linux takes care of this stuff, but if you are going to be poking values into a hardware device, you need to set up a virtual to physical address mapping and use the virtual address when the MMU is turned on, and the physical address when it is turned off. The mapping also needs to be non-cached. For example, something like: volatile phys_addr_t phys_addr = (phys_addr_t)0xXXXXXXXX; volatile void *virt_addr; volatile led_struct *led_ptr; virt_addr = ioremap(phys_addr, size); /* if MMU is off */ led_ptr = (led_struct *)phys_addr; led_ptr->... /* if MMU is on */ led_ptr = (led_struct *)virt_addr; led_ptr->... Don't take this literally - its just quick notes to give you an idea. Note the BRx/ORx stuff sets the "physical" address of devices, while the MMU mappings set the "virtual" address (you don't need a mapping to access the IMMRs - this is done for you). Also, most places in Linux have the MMU on, except for certain routines in the startup, and the exception handlers (in assembly). Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen at csiro.au Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/ To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.