Maybe a Problem with "tip22"
Hi,
The screen shot in Attilio's bug report was done by me on my Indy. I
am not experienced in this beginning of the universe kind of code. But
I found the following clues which may be useful.
Please refer to bug 452798
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452798). Here is
message #15 from Guido:
On Sun, Nov 25, 2007 at 01:02:25PM +0100, Martin Michlmayr wrote:
How much work is 64 bit support?
It's not the 64bit support, things are simply not fitting into the
memory segment we use anymore:
Tip22 finds this memory map on my Indy:
1) Free Memory(3) segment found at (0x88002000,0x88740000)
2) Free Memory(3) segment found at (0x88800000,0x89002000)
3) Free Memory(3) segment found at (0x896f2000,0x94000000)
(1) is where the running kernel + initrd goes. (2) is where we tell the
prom to download the tftpboot image to and (3) is lots of free space.
The 64bit kernel (7MB) is just so much bigger than the 32bit one.
Attached is a hack to get things booting again (so installer testing can
proceed). It puts the tftp boot file into (3) and the initrd into (2) -
it succesfully boots a kernel with an initramfs on my R5K Indy. I'll
have to change some of the reservation code so we don't waste so much
ram before I can fix this for real though.
Cheers,
-- Guido
Here is the "objdump -x" output of the "netboot-boot.img" from Lenny:
debbootL.img: file format ecoff-bigmips
debbootL.img
architecture: mips:3000, flags 0x00000032:
EXEC_P, HAS_SYMS, HAS_LOCALS
start address 0x897020cc
Sections:
Idx Name Size VMA LMA File off
Algn
0 .text 00001e00 89702000 89702000 000000d0 2**4
CONTENTS, ALLOC, LOAD, CODE
1 .data 00ad1500 89703e00 89703e00 00001ed0 2**4
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000040 8a1d5300 8a1d5300 00000000 2**4
ALLOC
SYMBOL TABLE:
[ 0] e 00000000897038b8 st 1 sc 1 indx fffff strcpy
[ 1] e 0000000089703e00 st 1 sc 2 indx fffff kernel_load
[ 2] e 0000000089702a30 st 1 sc 1 indx fffff ArcGetPeer
[ 3] e 00000000897033a8 st 1 sc 1 indx fffff printf
[ 4] e 0000000089703e34 st 1 sc 2 indx fffff stdout
[ 5] e 0000000089702de4 st 1 sc 1 indx fffff vsprintf
[ 6] e 0000000089703e00 st 1 sc 2 indx fffff _fdata
And here is the objdump -x" output of the "netboot-boot.img" from Squeeze:
debbootS.img: file format ecoff-bigmips
debbootS.img
architecture: mips:3000, flags 0x00000032:
EXEC_P, HAS_SYMS, HAS_LOCALS
start address 0x888020cc
Sections:
Idx Name Size VMA LMA File off
Algn
0 .text 00001ea0 88802000 88802000 000000d0 2**4
CONTENTS, ALLOC, LOAD, CODE
1 .data 00982140 88803ea0 88803ea0 00001f70 2**4
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000040 89185fe0 89185fe0 00000000 2**4
ALLOC
SYMBOL TABLE:
[ 0] e 0000000088803914 st 1 sc 1 indx fffff strcpy
[ 1] e 0000000088803ea0 st 1 sc 2 indx fffff kernel_load
[ 2] e 0000000088802a30 st 1 sc 1 indx fffff ArcGetPeer
[ 3] e 00000000888033a8 st 1 sc 1 indx fffff printf
[ 4] e 0000000088803ed4 st 1 sc 2 indx fffff stdout
[ 5] e 0000000088802de4 st 1 sc 1 indx fffff vsprintf
[ 6] e 0000000088803ea0 st 1 sc 2 indx fffff _fdata
It seems to me that what Guido wanted was done in Lenny but not in
Squeeze. In the screen shot, "initrd" was being copied into 0x88800000
by the Squeeze image. Wouldn't it overwrite the loader?
I downloaded the Squeeze "tip22" package, and here is the beginning of
the "ld.script.IP22" script:
OUTPUT_FORMAT("ecoff-bigmips")
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
{
/* XXX: place the loader after the kernel */
. = 0x88802000;
/* read-only */
_text = .; /* Text and read-only data */
.text : {
_ftext = .;
*(.text .text.*)
*(.rodata*)
} =0
_etext = .; /* End of text section */
PROVIDE (etext = .);
Thanks for your help!
Edwin
Reply to: