Subject: 21285 fixes

From: David Friedman <[email-masked]>
Date: Sun, 7 May 2000 19:18:58 -0400

A missing break statement in the 21285 serial driver prevents the kernel from setting the correct baud in 2.3.99-pre6-rmk1. I've included a patch for this.

Once I fixed that, I noticed that the kernel prints out several backtraces in request_standard_resources(), complaining about invalid addresses to virt_to_phys. The error messages are printed because high_memory is not initialized at this point, it is only set much later in mem_init(). But it seems that the use of the virt_to_bus macros in these cases is not entirely correct. I thought these macros could only be used in memory allocated with kmalloc() or get_free_page().

One more thing: when I disable CONFIG_DEBUG_LL, the kernel does not boot. Obviously, this is very hard to debug, since the serial port isn't mapped in. If anyone has any ideas about this, please let me know.

Thanks,

David Friedman
---
diff -ur linux/drivers/char/serial_21285.c /home/dsf/linux-2.3/linux/drivers/char/serial_21285.c
--- linux/drivers/char/serial_21285.c   Sun May  7 17:31:33 2000
+++ /home/dsf/linux-2.3/linux/drivers/char/serial_21285.c       Sat May  6 20:25:11 2000
@@ -212,6 +212,7 @@
        switch (cflag & CBAUD) {
        case B9600:
                baud = 9600;
+               break;
        case B19200:
                baud = 19200;
                break;

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

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 8 May 2000 07:20:42 +0100 (BST)

David Friedman writes:
> A missing break statement in the 21285 serial driver prevents the kernel
> from setting the correct baud in 2.3.99-pre6-rmk1. I've included a patch
> for this.

Thanks.  Applied.

> Once I fixed that, I noticed that the kernel prints out several backtraces
> in request_standard_resources(), complaining about invalid addresses to
> virt_to_phys. The error messages are printed because high_memory is not
> initialized at this point, it is only set much later in mem_init(). But
> it seems that the use of the virt_to_bus macros in these cases is not
> entirely correct. I thought these macros could only be used in memory
> allocated with kmalloc() or get_free_page().

True.  Can you provide more information?  Particularly where the invalid
usage of virt_to_phys is?

> One more thing: when I disable CONFIG_DEBUG_LL, the kernel does not boot.
> Obviously, this is very hard to debug, since the serial port isn't mapped
> in. If anyone has any ideas about this, please let me know.

You could comment out the #ifdef #endif in head-armv.S to enable the
mapping to be present.  However, from your previous point and this, it
sounds like you have other changes present in your kernel tree other
than just my patch?  Can you confirm this?
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: David Sean Friedman <[email-masked]>
Date: Mon, 8 May 2000 12:50:01 -0400 (EDT)

Excerpts from arm-linux: 8-May-100 Re: 21285 fixes by Russell A. L. Admin@arm. 
> usage of virt_to_phys is?

Maybe I didn't make my original message clear. Because
request_standard_resources() is calling virt_to_bus before mem_init(),
high_memory is 0, all uses of virt_to_bus in this case will cause a
backtrace on the EBSA285 compiled as an addin, provided that
CONFIG_DEBUG_ERRORS is set. But I am still not convinced that the use of
these macros is correct for the reasons I mentioned above. (Even though
x86 does the same thing).

> than just my patch?  Can you confirm this?

Yes. I'm using Mark van Doesburg's boot loader, which does the serial
port initialization in the kernel rather than in the BIOS (I assume your
bootloader does the latter), but the only change is to add this code to
head-armv.S. The only other change was to define the symbols
boot_memory_end, and boot_command_line, also in head-armv.S.

As you point out, the solution to this is simple enough, since there is
no reason to compile without CONFIG_DEBUG_LL. I was just hoping there
was an easy fix I had overlooked.

I hope this clarifies things.

David Friedman

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 8 May 2000 21:50:51 +0100 (BST)

David Sean Friedman writes:
> Maybe I didn't make my original message clear.

No, you didn't make your original message clear.  Unfortunately, you left
me guessing what configuration you are using, and so the real problem could
be in one of many places.  From the information you've now supplied, I now
know that you are in fact compiling up a kernel for a footbridge in add-in
mode, and you actually mean __virt_to_bus, not virt_to_bus or even virt_to_phys.

The use of these macros is actually correct.  However, it is arguably more
correct that these tests should not be in the __xx versions at all, but should
be in the standard xx versions.  The __xx versions are supposed to be
simplified, faster versions than their xx counterparts.

On the point of the validity of their use there - they are valid since we're
using them with memory within the kernels virtual view of memory, and not on
some randomly allocated area of virtual memory space.

ie, if your virtual map of RAM is 0xc0000000 to 0xd0000000, and you have the
kernel at 0xc0008000, then it is valid to use virt_to_xxx(0xc0008000).  However,
if vmalloc() returns 0xd0421000, then it is not valid to use
virt_to_xxx(0xd0421000), since the virtual address that vmalloc returns could
be pointing at any random physical page of RAM.

> bootloader does the latter)

My boot loader also does the serial port initialisation.  However, I am
unable to find any specific place where the serial port is initialised.

> but the only change is to add this code to head-armv.S.

Do you mean you've added extra code to head-armv.S to initialise the serial
port?  The correct place to put this would be in rs285_console_setup()
in drivers/char/serial_21285.c (I'm a little surprised that its not in there
already mind you).

> was an easy fix I had overlooked.

I don't think your problem is related to the debug code itself, since it
doesn't actually do any initialisation of the serial port.  However, it
may be a side effect of some of the code which CONFIG_DEBUG_LL enables,
which is why I need you to squash some of the possibilities.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: David Sean Friedman <[email-masked]>
Date: Mon, 8 May 2000 17:45:31 -0400 (EDT)

Yes, there is code added to initialize the serial ports in head-armv.S,
since Mark's bootloader doesn't do this. I know it is only necessary
when using the DEBUG_LL functions; the serial port is configured again
in console_init().

With regards to your comments on my problem with compiling without
DEBUG_LL, I'm inclined to agree with you that the problem has nothing to
do with the serial port itself (i.e. it is a side effect of setting up
the page mappings). But there is a cycle here: I need to be able to use
the serial port to debug this problem, which requires compiling with
DEBUG_LL, but the point is to get the kernel to boot without DEBUG_LL.

Unfortunately, I'm fairly busy with other work this week, but I'll try
to debug this next week once I have the time.

David Friedman