Subject: ebsa285 bug

From: David Friedman <[email-masked]>
Date: Thu, 18 May 2000 18:40:40 -0400

I think I've found another bug when using the ebsa285 in addin mode.

If anyone remembers the discussion about a week ago, I noted that the system does not boot when compiled without CONFIG_DEBUG_LL. I think the reason for this revisits the issue with using __virt_to_bus in request_standard_resources.

This may be fine for for other arm architectures, but using the ebsa285 in addin mode means that these macros are used to convert virtual addresses to PCI addresses. This seems incorrect here because the resource being requested is RAM.

I think that the reason this breaks the boot process is because the __virt_to_bus macro reads PCISDRAMBASE, in PCI config. space. The problem is that this is before paging_init, which means that config. space isn't mapped yet, unless the kernel was built with CONFIG_DEBUG_LL. In that case, config. space is mapped before start_kernel, so the macros behave as expected. I suppose that if PCI config. space is not mapped, then a trap would be generated, but this is before trap_init, so there is no handler and the boot process is broken.

I'm not really sure how to fix this, but maybe now that the problem is identified, someone can help with this.

Thanks,

David Friedman

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 19 May 2000 00:41:24 +0100 (BST)

David Friedman writes:
> I think that the reason this breaks the boot process is because the
> __virt_to_bus macro reads PCISDRAMBASE, in PCI config. space. The
> problem is that this is before paging_init, which means that config.
> space isn't mapped yet, unless the kernel was built with
> CONFIG_DEBUG_LL. In that case, config. space is mapped before
> start_kernel, so the macros behave as expected. I suppose that if
> PCI config. space is not mapped, then a trap would be generated, but
> this is before trap_init, so there is no handler and the boot process
> is broken.

That is probably exactly what's happening.

> identified, someone can help with this.

Look in arch/arm/kernel/setup.c:setup_arch for paging_init(), and move
request_standard_resources() after paging_init().  (It's currently
the function that is called directly before paging_init().

This means that we then get our memory mappings in place ready for
virt_to_bus to grab the right value from the footbridge.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |