From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zang Roy-r61911 Date: 04 Dec 2006 10:04:13 +0800 Subject: [U-Boot-Users] [PATCH 00/07 v2]: Add mpc7448hpc2 (Taiga) board support In-Reply-To: <20061201143152.9F8E4352621@atlas.denx.de> References: <20061201143152.9F8E4352621@atlas.denx.de> Message-ID: <1165197852.28151.38.camel@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Wolfgang On Fri, 2006-12-01 at 22:31, Wolfgang Denk wrote: > In message <1164960567.6742.25.camel@localhost.localdomain> you wrote: > > > > index d92f142..8a4d141 100644 > > --- a/lib_ppc/extable.c > > +++ b/lib_ppc/extable.c > > @@ -50,15 +50,29 @@ search_one_table(const struct exception_ > > const struct exception_table_entry *last, > > unsigned long value) > > { > > + DECLARE_GLOBAL_DATA_PTR; > > + > > while (first <= last) { > > const struct exception_table_entry *mid; > > long diff; > > > > mid = (last - first) / 2 + first; > > - diff = mid->insn - value; > > - if (diff == 0) > > - return mid->fixup; > > - else if (diff < 0) > > + if (mid > CFG_MONITOR_BASE) { > > + /* exception occurs in FLASH, before u-boot > relocation. > > + * No relocation offset is needed. > > + */ > > + diff = mid->insn - value; > > + if (diff == 0) > > + return mid->fixup; > > + } else { > > + /* exception occurs in RAM, after u-boot relocation. > > + * A relocation offset should be added. > > + */ > > + diff = (mid->insn + gd->reloc_off) - value; > > + if (diff == 0) > > + return (mid->fixup + gd->reloc_off); > > + } > > + if (diff < 0) > > first = mid+1; > > else > > last = mid-1; > > The problem I see with this code is that it is based on the > assumption that CFG_MONITOR_BASE is greater than any RAM address. > While this is always true so far, I would rather not rely on this. I would not rely on this either, if there is a better way :-). Anyway, it's better than a define. In future, there might be a board whose exception code will occur in both RAM and Flash. A fixed macro define can not deal with this condition, although, I do not see this kind of ppc board in u-boot tree until now. > > And I still don't understand why this change is necessary, and/or if > this is the right fix. If a fix is needed, then probably the values > of "value" is wrong in the first place, so the fix should be in the > calling routine. > "The "value" is the address of exception occurring. For mpc7448hpc2 board, a tsi108/9 bridge is used. There is a hardware chip errata, when the tsi108 pci controller has a config read operation. This operation will induce a processor exception. The following code does a pci config dword read. +unsigned int __get_pci_config_dword (u32 addr) +{ + unsigned int retval; + + __asm__ __volatile__ (" lwbrx %0,0,%1\n" + "1: eieio\n" + "2:\n" + ".section .fixup,\"ax\"\n" + "3: li %0,-1\n" + " b 2b\n" + ".section __ex_table,\"a\"\n" + " .align 2\n" + " .long 1b,3b\n" + ".text":"=r"(retval):"r"(addr)); + + return (retval); +} A exception will occur at address "1" ("value"), when the code executes in RAM (after relocation). While the address 1b and 3b are assigned when u-boot compiling. 1b and 3b are located in Flash. If the exception occurs in Flash, everything will be OK. While, for pci config read occurs in RAM, if I do not consider the reloc_off, I can not find the __ex_table. Do you think it is reasonable for the code to jump back to flash to execute? This might ensure the exception occurring address locates in FlASH. I can see the mechanism to deal with exception in u-boot is just similar to kernel, while kernel does not has such relocation. The same code is OK in kernel. For u-boot, we should consider this issue, although there is no other ppc board encounter this. thanks! Roy