Re: [OpenBIOS] [commit] r1114 - in trunk/openbios-devel: arch/sparc32 include/arch/sparc32

[Mark Cave-Ayland]

On 23/04/13 22:54, Artyom Tarasenko wrote:
> Sorry, somehow I missed testing this patch.
> It breaks loading kadb:
>
> 0>  boot disk kadb -kdvs Not a bootable ELF image
> Loading a.out image...
> Loaded 7680 bytes
> entry point is 0x4000
> bootpath: /iommu/sbus/espdma/esp/sd@0,0

Ah okay. I thought that the post below was an ack from you that 128K was 
still okay to run kadb with an unmodified ofmem_arch_get_virt_top():

http://www.openfirmware.info/pipermail/openbios/2013-April/007606.html

I also can't see any memory regions in the output above that would 
overlap 0xffc00000 - has any of the output been removed?

So just to clarify: is what you're saying that a checkout of OpenBIOS 
r1114 fails? In that case can you confirm what value of 
ofmem_arch_get_virt_top() that you were using in the URL above when kadb 
did work?

ATB,

Mark.

[commit] r1114 - in trunk/openbios-devel: arch/sparc32 include/arch/sparc32

[Artyom Tarasenko]

On Wed, Apr 24, 2013 at 12:29 AM, Mark Cave-Ayland
 wrote:
> On 23/04/13 22:54, Artyom Tarasenko wrote:
> > Sorry, somehow I missed testing this patch.
> > It breaks loading kadb:
> >
> > 0>  boot disk kadb -kdvs Not a bootable ELF image
> > Loading a.out image...
> > Loaded 7680 bytes
> > entry point is 0x4000
> > bootpath: /iommu/sbus/espdma/esp/sd@0,0
>
> Ah okay. I thought that the post below was an ack from you that 128K was
> still okay to run kadb with an unmodified ofmem_arch_get_virt_top():
>
> http://www.openfirmware.info/pipermail/openbios/2013-April/007606.html

Correct. Ack for 128K.
> I also can't see any memory regions in the output above that would overlap
> 0xffc00000 - has any of the output been removed?

Yes. I thought only the SunOS related part was interesting. The
conflicting region comes from the early OpenBIOS initialization (guess
it would be the same on your machine):

OFMEM: ofmem_map_page_range ffdd3000 -> 050800000 000c0000 mode 0000003c
OFMEM: ofmem_map_page_range ffe93000 -> 050200000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffe94000 -> 071000000 00001000 mode 0000003c
OFMEM: ofmem_claim phys=ffffffffffffffff size=00020000 align=00001000
OFMEM: ofmem_claim_virt virt=ffce0000 size=00020000 align=00000000
OFMEM: ofmem_map_page_range ffce0000 -> 000fe0000 00020000 mode 000000bc
OFMEM: ofmem_claim_virt virt=fe000000 size=01ce0000 align=00000000

^^^^^^^^ This is the conflicting region.

OFMEM: ofmem_map_page_range ffe95000 -> d00000000 00001000 mode 0000003c
Configuration device id QEMU version 1 machine id 32
OFMEM: ofmem_map_page_range ffe96000 -> 010000000 00001000 mode 0000003c
[...]
> So just to clarify: is what you're saying that a checkout of OpenBIOS r1114
> fails? In that case can you confirm what value of ofmem_arch_get_virt_top()
> that you were using in the URL above when kadb did work?

The value (ucell)0xff000000 which you suggested in the SunOS thread,
seems to work
better than  the current OFMEM_VIRT_TOP. If I revert the two lines to
the state before r1114:

-    virt = ofmem_claim_virt(OF_CODE_START - MEMORY_SIZE, MEMORY_SIZE, 0);
+    virt = ofmem_claim_virt(-1, MEMORY_SIZE, PAGE_SIZE);

-    ofmem_claim_virt(OFMEM_VIRT_TOP, OF_CODE_START - MEMORY_SIZE -
OFMEM_VIRT_TOP, 0);

then kadb starts with both (ucell)0xff000000 and OFMEM_VIRT_TOP, but
with the later, the kernel dies a bit earlier.

HTH,
Artyom

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu