* Re: Linux-2.1.129 boot on MCP750 <fwd> [not found] <SIMEON.9812091612.C@g-mun-af.muenchen.europe.mcd.mot.com> @ 1998-12-09 19:45 ` Alois Fertl 1998-12-10 11:13 ` Gabriel Paubert 0 siblings, 1 reply; 2+ messages in thread From: Alois Fertl @ 1998-12-09 19:45 UTC (permalink / raw) To: Cort Dougan; +Cc: Matt Porter, linuxppc-dev@lists•linuxppc.org, VALETTE Eric Yes its possible to change the locations where ppcbug loads via the net via the "niot" command. To my experience this address is only used if the "network prep mode" is switched off. If you switch this off the ppcbug does no longer prepare residual data (use "nbh" and you will see that R3 is zero). No residual data means that the raven is not detected and the code uses direct access to scan for PCI devices. As this will not work on the raven and you end up with no PCI at all. I do not know however which kernel version introduced this method of detecting the raven via the residual data. If I remember correctly it was possible to boot at least 2.0.32 with network prep mode switched off. > > You can change the address that ppcbug loads the image to. I pointed mine > at the end of memory to keep it out of the way. The boot code for prep is > very delicate right now due to the many many addresses that boards load > the image at so anything that can make it easier (such as moving the > address the kernel is loaded at) I want to take advantage of. > > }> There is a problem in boot/misc.c which manifests only > }> if netboot is used. Current ppcbug netboots at 0x5000 and > }> this forces decompress to overwrite its own source. > } > }Can you elaborate on which versions of ppcbug this is a problem with and > }in what cases? I have been booting the kernel on MVME23/26/27/36xx and an > }MCP750 without seeing this problem...maybe cause my MCP750 has an older > }rev of ppcbug. [[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]] [[ the message 'unsubscribe' to linuxppc-dev-request@lists•linuxppc.org ]] ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Linux-2.1.129 boot on MCP750 <fwd> 1998-12-09 19:45 ` Linux-2.1.129 boot on MCP750 <fwd> Alois Fertl @ 1998-12-10 11:13 ` Gabriel Paubert 0 siblings, 0 replies; 2+ messages in thread From: Gabriel Paubert @ 1998-12-10 11:13 UTC (permalink / raw) To: Alois Fertl Cc: Cort Dougan, Matt Porter, linuxppc-dev@lists•linuxppc.org, VALETTE Eric On Wed, 9 Dec 1998, Alois Fertl wrote: > > Yes its possible to change the locations where ppcbug loads via the net > via the "niot" command. To my experience this address is only used if > the "network prep mode" is switched off. If you switch this off the > ppcbug > does no longer prepare residual data (use "nbh" and you will see that R3 > is zero). No residual data means that the raven is not detected and the > code uses direct access to scan for PCI devices. As this will not work > on the raven and you end up with no PCI at all. A solution would be to add code to check if the value returned from reading at 0x80800008 returns something like a host bridge (0x0600???? little endian). Oe maybe the other way around: fall back to direct config method if after writing 0x80000008 at 0x80000cf8, 0x80000cfc does not show to be a host bridge. The preceding assumes that host bridge is device 0 on the PCI bus (it usually is). But in any case I prefer to rely on residual data if available: residual data is necessary to use the OpenPIC which is inside the Raven. > I do not know however which kernel version introduced this method of > detecting the raven via the residual data. If I remember correctly it > was possible to boot at least 2.0.32 with network prep mode switched > off. Note that this was because of netboot problems onn the MVME2600 that I started wrting my bootloader. It self relocates according to the free areas as given by the residual data and is compiled with -m relocatable option to make it 100% position independant. But it has other problems since it seems to only work on MVME2603 (nor even 2604). I would like to put my hands on some other HW because trying to debug this low level code through the net is not fun. Gabriel. [[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]] [[ the message 'unsubscribe' to linuxppc-dev-request@lists•linuxppc.org ]] ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1998-12-10 11:13 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <SIMEON.9812091612.C@g-mun-af.muenchen.europe.mcd.mot.com>
1998-12-09 19:45 ` Linux-2.1.129 boot on MCP750 <fwd> Alois Fertl
1998-12-10 11:13 ` Gabriel Paubert
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox