Stefan Reinauer <[EMAIL PROTECTED]> writes:
> Ah, good. I only found two places where virt_to_bus is definitely
> needed. With below patch applied, I get the following output when
> chainloading etherboot (I have some rc1 cvs in flash and latest cvs as
> elfimage)
And since there is a different RELOCADDR (the initial load address)
rc1 will load rc2.
> It loads itself the second time, but hangs after this.
> Does this fail because it tries to relocate to the same position?
No. It is not at all obvious why this fails. In my test similiar
test cases I quickly fill up my scrollback buffer, with etherboot
loading etherboot.
Just taking inventory.
You have a 234Mhz processor with 28MB of ram.
Let me describe what I am seeing.
- rc1 running at 0x9400 loads rc2 at 0x21000
- rc2 looks around, finds you have 28MB of ram and moves itself
up to the top of memory.
- rc2 then asks if it should terminate and return to rc1.
- Timing out rc2 continues on and appears to successfully
load rc2 again at 0x21000.
- Then nothing happens.
So there is no immediately apparent culprit, odd.
Approxiamently the same configuration works here so I don't
see any immediate culprits.
I wonder if the nic disable code is effective.
So now I need to suggest debugging steps.
There are two very obvious tools I can see being useful.
1) Etherboot now checks the checksums generated by mkelfImage
so loading a kernel image will test for corruption before
attempt to execute that image.
2) Disabling relocation and seeing if that makes a difference.
My suggestion then is to go to line 438 or so of main.c and change:
loadkernel(kernel); /* We don't return except on error */
to
loadkernel("vmlinux2.elf"); /* We don't return except on error */
And then at vmlinux2.elf put a kernel generate by mkelfImage. And
see if that works. If it does not work not the failure mode
checksum failure or another mystery hang.
If that doesn't work disable relocation and see if that case works.
I am heading to bed now, but if nothing seems to make any headway, and
you are game I will send you my assembly debugging macros that you can
sprinkle over the startup code to get some debugging information.
At the very minimum I would like to track this far enough to get
a good error message out of the process.
Eric
> --------------------------------------------------------------------
> Welcome to elfboot, the open sourced starter.
> January 2002, Eric Biederman.
> Version 1.2
>
> 37:init_bytes() - zkernel_start:0xfffe0000 zkernel_mask:0x0000ffff
> Found ELF candiate at offset 0
> New segment addr 0x94000 size 0x89e4 offset 0x60 filesize 0x40c4
> (cleaned up) New segment addr 0x94000 size 0x89e4 offset 0x60 filesize
> 0x40c4
> Loading Segment: addr: 0x0000000000094000 memsz: 0x00000000000089e4
> filesz: 0x00
> 000000000040c4
> Clearing Segment: addr: 0x00000000000980c4 memsz: 0x0000000000004920
> Jumping to boot code
> ROM segment 0xc1ae length 0x2c12 reloc 0x9400
> Etherboot 5.1.2rc1 (GPL) Tagged ELF for [RTL8139]
> Boot from (N)etwork or from (L)ocal? CPU 234 Mhz
> N
> Probing...[RTL8139]Found Realtek 8139 ROM address 0x0000
> - The PCI BIOS has not enabled this device!
> Updating PCI command 0003->0007. pci_bus 00 pci_device_fn 78
> ioaddr 0X1000, addr 00:E0:4C:88:02:A5 100Mbps full-duplex
> Searching for server (DHCP)...
> Me: 192.168.0.13, Server: 192.168.0.23, Gateway 192.168.0.50
> Loading 192.168.0.23:vmlinux.elf (ELF)... Loading Etherboot version:
> 5.1.2rc2
> done
......
> ROM segment 0xc1ae length 0x2c12 reloc 0x00021000
> Etherboot 5.1.2rc2 (GPL) Tagged ELF for [RTL8139]
> Relocating _text from: [000260cc,0002ed1c) to [01bf73b0,01c00000)
> Boot from (N)etwork or from (L)ocal? CPU 234 Mhz
> N
> Probing...[RTL8139]Found Realtek 8139 ROM address 0x0000
> - ioaddr 0X1000, addr 00:E0:4C:88:02:A5 100Mbps full-duplex
> Searching for server (DHCP)...
> Me: 192.168.0.13, Server: 192.168.0.23, Gateway 192.168.0.50
> Loading 192.168.0.23:vmlinux.elf (ELF)... Loading Etherboot version:
> 5.1.2rc2
> done
> --------------------------------------------------------------------
>
>
>
> Stefan
>
>
> --
> The x86 isn't all that complex - it just doesn't make a lot of
> sense. -- Mike Johnson, Leader of 80x86 Design at AMD
> Microprocessor Report (1994)
