Ronald G Minnich <[EMAIL PROTECTED]> writes: > On 17 Jul 2002, Eric W Biederman wrote: > > > Ronald G Minnich <[EMAIL PROTECTED]> writes: > > > > > OK, the problem is that the new mkelfImage is putting things where > > > linuxbios is, and the legacy linuxbios in many of our cards can't take > > > that. > > > > How do you switch ELF images without switching LinuxBIOS? > > The only case I can think of (etherboot) should not be a problem. > > I'm not sure I get the point. > > linuxbios on this particular board is loading etherboot from FLASH. > Etherboot is then > loading the elfImage generated by the latest mkelfImage. Two interesting > things: > - images generated by the new mkelfImage are not comprehensible to objdump > (but old ones are, I'm still trying to get to this)
I probably removed the section header. readelf -a should still work. This is a known objdump bug. > - the new images have load address ca. 0x15000 etc. which seems to blow > etherboot out of the sky. the old images have high-memory load > addresses. O.k. Killing etherboot is significantly different from killing LinuxBIOS. I think I have always loaded some code 0x10000+, but I have never had a version that kills etherboot for me. Etherboot runs at 0x94000 so I don't see how a 0x15000 address would kill it. Anyway readelf -a gives me: from a 2.4.17 kernel. But this may be another binutils bug of the kind that breaks LinuxBIOS builds. I'm about an inch from introducing a configure script that tests for broken tools :) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align NOTE 0x0000d4 0x00010000 0x00010000 0x001c0 0x001c0 RWE 0 LOAD 0x0000d4 0x00010000 0x00010000 0x016fc 0x059b4 RWE 0 LOAD 0x0059b4 0x00091000 0x00091000 0x00000 0x00028 RWE 0 LOAD 0x0059b4 0x00100000 0x00100000 0xe6e98 0x700000 RWE 0 LOAD 0x0ec84c 0x00800000 0x00800000 0x00000 0x00000 RWE 0 > > > I hadn't realized I had changed the locations noticeably. Unless this > > is one of those cases where you always used a local hack, that I never > > adopted. > > if only that were the case :-) > > Anyway I'll get back to you asap as soon as I have better info. Sometimes > I describe the problem and you get me a patch in a few seconds :-) I try. It doesn't always work, but I try. Eric
