Subject: EBSA-285

From: Andrew Thomas <[email-masked]>
Date: Wed, 17 Feb 1999 14:32:23 GMT

Folks,

I'm trying to get Linux up on an EBSA-285 board. The source I'm
using is 2.2.1 with patch-2.2.1-19990128-1.gz applied, but
I'm having no luck getting the kernel to boot.

I've modified head-armv.S to set r0/r1 and setup_arch() in setup.c so
that params = NULL; and have tried faking an aif header (this didn't
work). I also wrote a little loader which can plant 'debugging code'
the result of which suggests the bug is in 
setup_pagetables (inlined into paging_init) at this point:

	/*
	 * unmap everything else
	 */
	for (address = end_mem; address; address += PGDIR_SIZE)
		free_init_section(address);

So, before I proceed any further, could someone sucessfully running
a kernel on an ebsa-285 board let me know which kernel (and patches)
they are running, what PCI cards they have (or a copy of their
.config) and finally whether they have the 21285 working as a console...

Thanks,

Andrew
------
Andrew Thomas				
Hewlett-Packard Laboratories, Bristol	
Filton Road				Email: [email-masked]
Stoke Gifford				Phone: +44 117 922 9511
Bristol BS34 8QZ			FAX:   +44 117 922 9286
United Kingdom				HP Telnet:     312 9511
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Wed, 17 Feb 1999 15:22:32 +0000

>setup_pagetables (inlined into paging_init) at this point:

If you get a crash in this sort of area the most likely cause is that the 
kernel is in the wrong place in physical memory.  It's quite important that 
the kernel be loaded at physical address 8000.

The other possibility is that you've told the kernel it has the wrong amount 
of RAM.

p.

---

From: Hwa Jin Bae <[email-masked]>
Date: Wed, 17 Feb 1999 07:58:43 -0800

You may want to verify that parameter parsing routine that figures
out the memory size on EBSA285 actually returns correct size for
the size of DRAM.  I noticed that for EBSA285 this is not being
done correctly if you don't pass the parameters explicitly in
boot parameter.  This results in hard-to-debug bad behavior during
bootup sequence -- around memory mapping setting.

-- 
Hwa Jin Bae
PSO Systems Inc
[email-masked]   
http://www.pso.com

---

From: Philip Blundell <[email-masked]>
Date: Wed, 17 Feb 1999 17:50:56 +0000

>bootup sequence -- around memory mapping setting.

Yeah.  It would be nice if someone could contribute some memory auto-sizing 
code actually.  It shouldn't be that hard.  One could probably assume a 
minimum of 4MB and go up from there.

p.

---

From: Werner Almesberger <[email-masked]>
Date: Wed, 17 Feb 1999 19:54:45 +0100 (MET)

> minimum of 4MB and go up from there.

linux-7110 has some, in
ftp://lrcftp.epfl.ch/pub/people/almesber/psion/boot-9.tar.gz, file findmem.S

There are a few things that make it less trivial than it may seem at first
sight:
 - the minimum step width can be rather small, e.g. on the Psion, it's
   just 512kB. So to scan a 4GB address space, you'd have to check 8192
   addresses. No big deal, except with ...
 - incomplete address decoding. This means that we need to copy all the
   original contents and put them back in the right order as soon as we
   find that some address doesn't point to real memory. (After all, the
   spot we're testing may happen to point somewhere into the kernel or
   into initrd.)

An added challenge on the 7110 is that we don't have a lot of memory to
throw at the problem (e.g. to store things we've overwritten), because
the things loaded by the boot loader (Arlo) may end up all over the
place, so we need to detect available memory and move things back to
sequence before running the kernel.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, DI-ICA,EPFL,CH   [email-masked] /
/_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 17 Feb 1999 22:58:42 +0000 (GMT)

> minimum of 4MB and go up from there.

I disagree here.  One some architectures, eg EBSA285, the SDRAM size must be
known before the SDRAM is in use, and that means that the boot loader must
know.  With the DC21285, it is not possible to probe the memory size and
organisation without disabling the SDRAM banks.

This information might as well be passed to the kernel by the loader code
anyway therefore.

Ok, you could find out what's currently set up, but I think that some of
the EBSA285 PBLs use fixed memory sizes, so increasing the SDRAMs with some
autoprobing code in the kernel will not be beneficial.  (you'll still only
have 16MB available).
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Werner Almesberger <[email-masked]>
Date: Thu, 18 Feb 1999 15:14:27 +0100 (MET)

> This information might as well be passed to the kernel by the loader code

By the way, I think it would be nice if the memory size detection (or,
rather retrieval of the size) could be moved to one of the
ARM-architecture-dependent files.

While I'm at it, is it true that current->tss.memmap should always be
equal to __virt_to_phys((unsigned long) &swapper_pg_dir) ? If yes, it
would be nice if this could be set in the general ARM code. Right now,
7110 and RPC set current->tss.memmap at run time, while all other
architectures use the compile-time default.

I've appended the patch I currently have in my 7110 tree for the latter
change. (Note: it doesn't touch the RPC code or the compile-time
default.)

- Werner

---------------------------------- cut here -----------------------------------

--- ref/arch/arm/mm/init.c	Tue Feb  9 00:38:23 1999
+++ work/arch/arm/mm/init.c	Tue Feb  9 02:20:08 1999
@@ -137,9 +137,13 @@
 	start_mem += PTRS_PER_PTE * sizeof (void *);
 #endif
 	memzero (empty_zero_page, PAGE_SIZE);
+#ifdef CONFIG_ARCH_CLPS7110 /* should be valid for all architectures */
+	current->tss.memmap = __virt_to_phys((unsigned long) &swapper_pg_dir);
+/* @@@ ask RMK; also used by RPC */
+#endif
 	start_mem = setup_pagetables (start_mem, end_mem);
 
 	flush_tlb_all();
 	update_memc_all();
 
 	end_mem &= PAGE_MASK;

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 18 Feb 1999 12:29:31 -0500 (EST)

Werner is right on both points here.  We have the same concerns on SA1100
architecture.

> +++ work/arch/arm/mm/init.c	Tue Feb  9 02:20:08 1999

Nicolas Pitre, B. ing.
[email-masked]