On Mon, Aug 26, 2013 at 7:14 PM, Scott Wood <[email protected]> wrote: >> that kernel must be at location 0. Another problem was that interrupts >> got re-enabled during execution of my bootloader (I am doing some >> syscalls -> goes to Cisco rom), > Do you mean you're calling into the rom after Linux has already started > executing? That's not normal for 8xx.
No, in bootloader. I have disabled interrupts and then later did a syscall which probably enabled them again. As I have overwritten some of Cisco ROM data it crashed (at random place). >> I am also curious why CONFIG_PPC_EARLY_DEBUG_CPM uses >> CONFIG_PPC_EARLY_DEBUG_CPM_ADDR as pointer to transmit SMC buffer and >> not address of CPM/SCM parameter RAM ? TX buffer address can be read >> from SMC parameter RAM. Wouldn't this solution be more portable? At >> least this way I do it when I take over console from Cisco >> startup/rommon. > > The point was to keep things as simple as possible (e.g. for use in > temporary handcoded asm as needed). This is a hacky debugging feature > that assumes you know what you're doing and can set the address to match > what the loader does (and that the loader's choice of address is > static). If you have an improvement that keeps it simple, feel free to > send a patch. How about making CONFIG_PPC_EARLY_DEBUG_CPM_PARRAM that woud carry address of SMCx parameter RAM (IMMR+0x04180 on MPC866) and this value would be used in case CONFIG_PPC_EARLY_DEBUG_CPM_ADDR is zero ? This would allow kernel hackers to still use CONFIG_PPC_EARLY_DEBUG_CPM_ADDR for assembly debugging (+legacy use) and everyone else can use it as a more reliable option that does not rely on particular bootloader behavior. Early debug is good even for end-users so as they can send debug output if anything goes wrong at early stage. Anyway, difference between _PARRAM and _ADDR is only one lwz instruction, so I guess it is possible to completely discard _ADDR if there is no legacy use for it. I am also not sure if this works with SCC UART ports or only CPM SMC UART. Martin _______________________________________________ Linuxppc-dev mailing list [email protected] https://lists.ozlabs.org/listinfo/linuxppc-dev
