Subject: transform zImage to AIF

From: [email-masked]
Date: Thu, 18 Feb 1999 12:14:57 +0100

Here my code to prepend an AIF header to zImage for EBSA285
Please tell me if I'm doing something wrong

# Makefile
SIZE := $(shell wc -c zImage | gawk '{print $$1}')
hdr:	hdr.S zImage
	arm-linux-as --defsym size=$(SIZE) hdr.S -o hdr.o
	arm-linux-objcopy -O binary hdr.o hdr
	cat hdr zImage > linux.axf

/* hdr.S */
	.text
	mov r0,r0
	mov r0,r0
	bl init
	.word 0
	swi 0x11
	.word size
	.word 0
	.word 0
	.word 0
	.word 0
	.word 0x8000
	.word 0
	.word 32
	.word 0
	.word 0
	.word 0
	mov r0,r0
init:	mov r0,#0
	mov r1,#4 /* EBSA285 */
	mov r4,#0
	orr r4,r4,#0x8000
	mov r5,#0x130 /* turns MMU off */
	mcr p15,0,r5,c1,c0
	mov r0,r0
	mov pc,r4
	mov r0,r0
	mov r0,r0
	mov r0,r0
	mov r0,r0
	mov r0,r0
	mov r0,r0
	mov r0,r0

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

---

From: Philip Blundell <[email-masked]>
Date: Thu, 18 Feb 1999 13:38:02 +0000

>Please tell me if I'm doing something wrong

The code itself looks OK but you might not be taking sufficient care over the 
memory layout.  If the idea is that this works in the same way as the CATS 
bootstrap (ie you load it at address 0), you need to have enough padding that 
zImage starts at 0x8000.  This is what the .align and .space directives were 
for in the source I sent you.  Alternatively you could load the code at 
0x8000-sizeof(hdr) but Angel might not be too keen on that.

p.

---

From: [email-masked]
Date: Thu, 18 Feb 1999 16:21:17 +0100

> 0x8000-sizeof(hdr) but Angel might not be too keen on that.

According to the doc, you  cannot use memory under 0x8000. So, 
I've prepend an AIF header that tells the boot loader to copy image 
to 0x8000, then I've put into zero-init zone the part of code to set 
r0,r1 and put off mmu, then I should jump to 0x8000

But I'm not sure zero-init code is executed in that case.

Anyway, by initialisiing UART in uncomp_setup_arch() , I now get
"Uncompressing Linux...done"
and "now booting the kernel.",
but then .... nothing

I've also tried by adding the bootstrap instructions to the beginning 
of head.S, but It doesn't work neither better nor bader

Christophe

---

From: Philip Blundell <[email-masked]>
Date: Thu, 18 Feb 1999 15:33:12 +0000

>and "now booting the kernel.",

Try putting debugging at the start of head-armv.S to see if it's managing to 
call that code at the right address.  If so then trace it through and see 
where it falls over.

p.

---

From: [email-masked]
Date: Fri, 19 Feb 1999 17:17:29 +0100

> call that code at the right address.  If so then trace it through and see 

Ok, I've put debbuging stuff and now I can tell that It runs until we 
try to set MMU on. till there, I'm able to write things on serial at 
addr 0x42000000. After that, I try to write things on serial at addr 
0xFE000000, and I get nothing.

Here my code: (I know i'm destroying r3 and r4, but we dont need 
them between my two debugs)

There is one thing I dont understand: You initialise cr1 using r0, but 
r0 is not initialised in order to set MMU , is it ?
It has been used to address page tables

Christophe

@
@ The following should work on both v3 and v4 implementations
@
		mov	lr, pc
		mov	pc, r10					@ Call processor flush 
(returns ctrl reg)
		adr	r5, __entry
		sub	r10, r10, r5				@ Make r10 PIC
		ldr	lr, .Lbranch

		mov	r3,#0x042000000
1:		ldrb	r4,[r3,#0x178]
		tst	r4,#0x10
		beq	1b
		mov	r4,#'M'
		strb	r4,[r3,#0x160]

		mcr	p15, 0, r0, c1, c0			@ Enable MMU & 
caches.  In 3 instructions
								@ we lose this page!
		mov	pc, lr

.Lalready_done_mmap:
		mov	r3,#0xFE000000
1:		ldrb	r4,[r3,#0x178]
		tst	r4,#0x10
		beq	1b
		mov	r4,#'m'
		strb	r4,[r3,#0x160]

---

From: Philip Blundell <[email-masked]>
Date: Fri, 19 Feb 1999 17:25:55 +0000

>r0 is not initialised in order to set MMU , is it ?

Yes, it's loaded by this subroutine call (which winds up at 
.Larmv4_flush_early)

p.

---

From: [email-masked]
Date: Fri, 19 Feb 1999 18:37:24 +0100

> >		mov	pc, r10					@ Call processo

Ok, so r0 is correctly initialised. 
Do you see any reason why I get the M printed on my terminal
before switching MMU on, and I dont get the m after MMU on ?

The progs continues at .Lalready_done_mmap, doesn't it ?

christophe

---

From: Andrew Thomas <[email-masked]>
Date: Fri, 19 Feb 1999 18:32:56 GMT

> The progs continues at .Lalready_done_mmap, doesn't it ?

I've just caught up on this discussion on the armlinux mailing
list. I have the same problem :-( I'm a bit further along than
you now that I've written the beginnings of a debugger (I wish
I was joking..) The problem is in console_init, specifically the
test to see if the UART exists in serial_console_setup ...
On my hardware, and I'm guessing on yours, this doesn't exist - I
want to use the UART on the 21285....

I've tried several kernel configs which only have 21285 UART in,
but they don't build :-( Also check out PARAMS_BASE (hunt around in the
code) this struct is usually setup by the bootloader (it seems).

Hope this helps you along..

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: Fri, 19 Feb 1999 20:01:54 +0000

>The progs continues at .Lalready_done_mmap, doesn't it ?

That's certainly the idea, yes.

p.

---

From: Philip Blundell <[email-masked]>
Date: Fri, 19 Feb 1999 20:03:54 +0000

>but they don't build :-( Also check out PARAMS_BASE (hunt around in the

What's the error you get?  This certainly should be possible.

p.

---

From: Dave Baukus <[email-masked]>
Date: Fri, 19 Feb 1999 14:44:56 -0600

> What's the error you get?  This certainly should be possible.

Depending on the the level the problem may be one or more of the following:

	1.) that at some point serail_21285.c was moved to 
	drivers/char yet arch/arm/Makefile modifies 
		CHAR_DRIVERS  := arch/arm/drivers/char/char.a

	thus char.a does not include serial_21285.o; thus the final link of the
	kernel complains.

	I hack this by:
		CHAR_DRIVERS  := drivers/char/char.a
	
	2.) The other thing may be that drivers/char/tty_io.c at some levels
	does not include a call to rs285_init(). (don't quote me on the function
	name).

	3.) Finally, don't define any of the other serial options such as 
	because in some level of tty_io.c  SERIAL_CONSOLE and SERIAL_21285_CONSOLE
	are mutually exclusive.

--
Dave Baukus
	Inet Technologies Inc. - R & D
	[email-masked]
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 19 Feb 1999 21:01:11 +0000 (GMT)

> 		CHAR_DRIVERS  := drivers/char/char.a

Or get a more up to date kernel source.  Everything in arch/arm/drivers has been
gone for about 2 to 3 weeks now.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        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: Dave Baukus <[email-masked]>
Date: Fri, 19 Feb 1999 15:19:13 -0600

> gone for about 2 to 3 weeks now.

Yea, I was hoping for that, but  the latest I can find is 2.2.1 w/
patch-2.2.1-rmk3 doesn't provide for SERIAL_21285 configuration in the config
scripts.

I haven't tracked down missing piece.

---

From: Philip Blundell <[email-masked]>
Date: Fri, 19 Feb 1999 21:25:52 +0000

>	does not include a call to rs285_init(). (don't quote me on the 
>       function name).

I do seem to have this patch in my tree.  Not sure if it's still necessary.

diff -u --recursive --new-file clean/linux/drivers/char/tty_io.c linux/drivers/char/tty_io.c
--- clean/linux/drivers/char/tty_io.c	Tue Feb 16 21:12:28 1999
+++ linux/drivers/char/tty_io.c	Tue Feb 16 21:13:43 1999
@@ -130,6 +130,8 @@
 static int tty_fasync(int fd, struct file * filp, int on);
 extern long console_8xx_init(long, long);
 extern int rs_8xx_init(void);
+extern int rs285_init(void);
+extern long rs285_console_init(long, long);
 
 #ifndef MIN
 #define MIN(a,b)	((a) < (b) ? (a) : (b))
@@ -2155,6 +2160,9 @@
 #endif
 #ifdef CONFIG_ESPSERIAL  /* init ESP before rs, so rs doesn't see the port */
 	espserial_init();
+#endif
+#ifdef CONFIG_SERIAL_21285
+	rs285_init();
 #endif
 #ifdef CONFIG_SERIAL
 	rs_init();

>	because in some level of tty_io.c  SERIAL_CONSOLE and 
>       SERIAL_21285_CONSOLE are mutually exclusive.

If this is the case in the latest kernel can you point to the problem?  I just 
looked at the code and didn't see anything obvious.  If you select both then 
the 16550 console will take precedence by default assuming both devices 
actually exist (eg on CATS or NetWinder).

p.

---

From: Philip Blundell <[email-masked]>
Date: Fri, 19 Feb 1999 21:44:42 +0000

>patch-2.2.1-rmk3 doesn't provide for SERIAL_21285 configuration in the config

Yes, it does.  You need to have turned on `nonstandard serial port support' 
but it's there.  Look in drivers/char/Config.in.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 19 Feb 1999 21:49:43 +0000 (GMT)

> patch-2.2.1-rmk3 doesn't provide for SERIAL_21285 configuration in the config

It is in there:

   if [ "$CONFIG_FOOTBRIDGE" = "y" ]; then
     bool '21285 serial port support' CONFIG_SERIAL_21285
     if [ "$CONFIG_SERIAL_21285" = "y" ]; then
       bool '   Console on 21285 serial port' CONFIG_SERIAL_21285_CONSOLE
     fi
   fi

That's in the character devices section.  Look for (and set)

bool 'Non-standard serial port support' CONFIG_SERIAL_NONSTANDARD
   _____

---

From: "christophe leroy" <[email-masked]>
Date: Sat, 20 Feb 1999 12:09:34 MET

> want to use the UART on the 21285....

So it means that you arrive at serial_console_setup.

My problem for now resides before realy starting the kernel, in 
head-armv.S

I'm able to write things on serial by writing bytes at 0x42000160 
(after been sure UART is free by testing 0x42000178) when MMU is OFF.
But When I try to write things on serial just after having switch MMU 
ON ,in the beginning of .Lalready_done_mmap  (So I write at 
0xFE000160, which is the supposed virtual adresse of UART), nothing 
happens. So I wonder what happens after having put MMU ON.

As you seem to have more experience than me on it, maybe have you an 
idea of what could be wrong at that point .

Christophe

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 20 Feb 1999 12:06:36 +0000 (GMT)

> happens. So I wonder what happens after having put MMU ON.

There is at the bottom of head-armv.S a load of debugging code for exactly
this sort of debugging.  You may want to try some of it out.  Note however,
that it does require a serial lead with RTS and CTS connected (it's sometimes
useful while using these to be able to stop the kernel...)
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        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: "christophe leroy" <[email-masked]>
Date: Sun, 21 Feb 1999 11:52:49 MET

> useful while using these to be able to stop the kernel...)

I'd a look at it. It's exactly what I'm doing.
On EBSA285, RTS and CTS arent used

christophe

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 21 Feb 1999 11:07:47 +0000 (GMT)

> On EBSA285, RTS and CTS arent used

I know that my printascii (etc) code does indeed work correctly in all
EBSA285 releases, so if you're doing the same as my debugging code, you
can't be getting to .Lalready_done_mmap.  The only thing that would
stop this is if the kernel was not correctly located in memory.

I seem to remember you were adding some extra code at the start of the
kernel by using objcopy - this is probably where the problem lies.  Your
extra code is relocating the kernel, and thereby causing all the internal
references in the code to point at the wrong place.

Try adding your code directly into arch/arm/head-armv.S
   _____

---

From: [email-masked]
Date: Mon, 22 Feb 1999 12:20:44 +0100

Thanks for your help ! I'm now running longer.
The problem was that I had had things at the beginning of head.S, 
which I think did move the kernel at the wrong place (why ?)
Now I've replaced some of the nop by what I need, so I dont move 
code anymore and it works.

So, now I can run till paging_init, but after paging_init I dont have
any output more. 
Does paging_init invalidates page 0xFE000000, so I cannot write 
anymore directly into UART, or is that paginig_init that never 
returns ?

Christophe

---

From: Andrew Thomas <[email-masked]>
Date: Mon, 22 Feb 1999 11:57:35 GMT

> gone for about 2 to 3 weeks now.

But...

I'm using 2.2.1 patched with patch-2.2.1-19990128-1.gz ..

Patching with patch-2.2.1-rmk3.gz or patch-2.2.1-rmk4.gz and running
xconfig doesn't allow me to configure "Character Devices/21285 serial port support",
and I only have a 21285 serial port...

Andrew

---

From: Andrew Thomas <[email-masked]>
Date: Mon, 22 Feb 1999 12:05:06 GMT

> and I only have a 21285 serial port...

Oops. Enable non standard "non standard serial support"

Sorry (it is a monday morning after all :-))

Andrew

---

From: Russell King <[email-masked]>
Date: Mon, 22 Feb 1999 12:44:19 +0000 (GMT)

> code anymore and it works.

Since the kernel is linked to be at address 0x8000, and you've added
code to the start of the kernel which tells the AIF loader that your
extra code starts at 0x8000, the kernel is going to be in the wrong
place.

> anymore directly into UART, or is that paginig_init that never 

No.  Please use the printascii, it's there for this sort of debugging!
Try putting it into 'printk' since it will hopefully allow the kernel
to tell you what's going wrong.

--
Russell King ([email-masked])

---

From: [email-masked]
Date: Mon, 22 Feb 1999 16:11:35 +0100

> to tell you what's going wrong.

Ok, I've added debugging code to printk, and then I can tell:
It hangs in setup_pagetables in paging_init, which is called with 
start_mem=0xC0075DA4 and end_mem=0xCEFD0240 (what 
strange values)

I'd a look at setup arch and I got params=0xC0000100, 
params....page_size=0xe59FF018 and nr_pages=0xe59FF018

I think something is wrong there. Should be params struct be 
initialised somewhere before ? or params be null ?

Christophe

---

From: Philip Blundell <[email-masked]>
Date: Mon, 22 Feb 1999 15:28:52 +0000

>I think something is wrong there.

Definitely.  Those two numbers are ARM instructions.

>Should be params struct be 

If you don't have a bootloader to initialise the params struct, you need to 
fiddle setup.c to set params=NULL.  Otherwise you'll be in all sorts of 
trouble.

p.

---

From: [email-masked]
Date: Mon, 22 Feb 1999 17:46:43 +0100

> fiddle setup.c to set params=NULL.  Otherwise you'll be in all sorts of 

Thanks a lot, now it works better. (not yet the best) 

I've now managed to begin to boot, but kernel keeps waiting at
PCI: Probing PCI hardware.
Is there something wrong with PCI ? My card is configured as host-
bridge and is plugged on DEC PCI backplane

Christophe

---

From: Russell King <[email-masked]>
Date: Mon, 22 Feb 1999 16:47:10 +0000 (GMT)

> initialised somewhere before ? or params be null ?

Yes, by a boot loader, or params can be NULL (in which case you
have to specify the memory size using mem=).

---

From: Philip Blundell <[email-masked]>
Date: Mon, 22 Feb 1999 17:03:46 +0000

>bridge and is plugged on DEC PCI backplane

Check that you're clearing down the PCI reset signal.  I think the kernel 
expects the bootloader to do this.  Even then though you will probably need 
something to set up the BARs; the kernel can't currently do all the PCI 
stuff on its own.

p.

---

From: [email-masked]
Date: Mon, 22 Feb 1999 18:11:06 +0100

> something to set up the BARs; the kernel can't currently do all the PCI 

Ok, so is there a bootloader somewhere that is able to do that ?

Christophe

---

From: Philip Blundell <[email-masked]>
Date: Mon, 22 Feb 1999 17:18:54 +0000

>Ok, so is there a bootloader somewhere that is able to do that ?

I assume there must be, since people are running Linux on EBSA boards 
successfully.  But I don't know where you can get it.  Russell King is 
probably da man.

p.

---

From: [email-masked]
Date: Mon, 22 Feb 1999 18:49:25 +0100

> successfully.  But I don't know where you can get it.  Russell King is 

EBSA285 Manual is clear enough to do one my self. 
Now My kernel boots until rootfs mount.

Thanks for people who helped me.
For those who, like I did,  have problems to boot Linux kernel on 
EBSA285,
I can give them everything they need to boot.

Christophe

---

From: [email-masked]
Date: Tue, 23 Feb 1999 10:11:11 +0100

> 
> Hi Christophe,
> 
> I have been following this discussion since it started.  You mentioned
> below you would be willing to share info on booting Linux on the
> ebsa-285.  We have our own similar hardware, nad I would be interested
> in attempting to get Linux to run on it.  So, as you say, can you give
> me everything I need to boot?:)  Thanks!
> 

Find attached a tar archive that contains something to create a 
linux.axf that you can download to flash using FMU, and a patch 
on linux2.2.1+patch-2.2.1-rmk4, that do necessery inits (r0, r1, 
MMU off, PCI init, serial init).

Dont forget to choose 21285 serial port and console on 21285 
serial port in char devices, non standard serial ports, in kernel 
config.

I'm currently working on a block device for flash memory

Christophe

---

From: [email-masked]
Date: Tue, 23 Feb 1999 10:42:01 +0100

> have to specify the memory size using mem=).

I've now a kernel that boots correctly. I've added a network card, and
the kernel says me that It has detected my card but the card has 
no IO adress assigned. I think that I have some PCI configs to do,
but I dont know what to do

Do you know where I can find a BIOS for EBSA285, that does it,
or where I can find infos on PCI bus in order to write a PCI 
configurator ?

Thanks

Christophe

---

From: Philip Blundell <[email-masked]>
Date: Tue, 23 Feb 1999 10:03:35 +0000

In message <[email-masked]>, [email-masked] wri
>but I dont know what to do

Yes.  You need to scan the bus and allocate I/O and memory regions.  If you 
can do this in a way that fits neatly into the generic PCI support that would 
be a plus.

>or where I can find infos on PCI bus in order to write a PCI 

Check your local bookstore.  You should be able to buy a book about PCI 
without too much trouble and everything is explained in there.

p.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 23 Feb 1999 10:05:27 +0000

>or where I can find infos on PCI bus in order to write a PCI 

The Linux kernel includes full PCI setup code (BIOS if you will).
I originally wrote it for the Alpha and it was then taken, expanded
etc.   It is very functional, I believe that it runs/works on the ebsa-285
at system start up.  I am assuming that this is the case 'cos I have
another PCI based ARM system that I'm about to turn PCI on for.  Right now
I'm at the 'loading  a RAMdisk stage'...

---

From: David Feustel <[email-masked]>
Date: Tue, 23 Feb 1999 06:50:45 -0500

AnnaBooks ( http://www.annabooks.com ) has a couple of reference
manuals on PCI. The one I got from Annabooks seems very complete,
but then I haven't tried to do anything with PCI hardware using 
that info yet :-).

-- 
David Feustel
Fort Wayne, Indiana
219-483-1857

http://www.d-feustel.com

---

From: David Feustel <[email-masked]>
Date: Tue, 23 Feb 1999 06:57:00 -0500

PCI Hardware and Software Architecture & Design
by Edward Solari & George Willse
ISBN 092939259-0
from Amazon or Annabooks

-- 
David Feustel
Fort Wayne, Indiana
219-483-1857

http://www.d-feustel.com

---

From: christophe leroy <[email-masked]>
Date: Tue, 23 Feb 1999 15:26:52 +0000

> I'm at the 'loading  a RAMdisk stage'...

Is it the layout_? functions in bios32.c ?
You find them in alpha and m68k arch, not in all arch, not in arm.
I'd a look at it and I think i'll try to port it to arm.

Could you please sum up how it works ? (I mean what function is 
doing what) And what I can discard as there is a lone PCI bus on
EBSA285 board

Christophe

---

From: Dave Baukus <[email-masked]>
Date: Tue, 23 Feb 1999 09:33:55 -0600

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

I'm sure I'll be corrected if I'm wrong, but, I think the PCI bus scanning
and setup works correctly on ebsa285; the PCI subsystem has located all devices
on the bus. The problem lies in fact that some pre-OS
entity, BIOS for lack of a better term, did not allocate IO, MEM, and interupts
to the various devices. If you look at arch/arm/kernel/hw-ebsa285.c you'll see
where pcibios_fixup_ebsa285() assigns some interrupt values, maps some devices
to IO for some architectures, .....

For me, since the ebsa285 is a transitional platform, I added a hard coded
function
that assigns the IO and such; this looks like:

...
....
        /* sort out the irq mapping for this device */
        switch (machine_type) {
        case MACH_TYPE_EBSA285:
                dev->irq = ebsa_irqval(dev);
                /* Turn on bus mastering - boot loader doesn't
                 * - perhaps it should! - dag
                 */
#if 0
                pci_set_cmd(dev, 0, PCI_COMMAND_MASTER);
#else
                inet_pci_bios_fixup(dev);
#endif
                break;
...
...

The function inet_pci_bios_fixup() simply looks for the devices I know I
have (a 3com ethernet) and assigns an IO address and sets the command register.
A more elegant and generic solution will have wait.

---

From: Paul Koning <[email-masked]>
Date: Tue, 23 Feb 1999 10:51:06 -0500

>>>>> "Dave" == Dave Baukus <[email-masked]> writes:

 Dave> I'm sure I'll be corrected if I'm wrong, but, I think the PCI
 Dave> bus scanning and setup works correctly on ebsa285; the PCI
 Dave> subsystem has located all devices on the bus. The problem lies
 Dave> in fact that some pre-OS entity, BIOS for lack of a better
 Dave> term, did not allocate IO, MEM, and interupts to the various
 Dave> devices. ...

I think the issue is that EBSA285 doesn't HAVE a BIOS.

Personally, I wonder about depending on such a notion.  There's
nothing wrong with having the OS initialization do the entire system
init from scratch.  At worst that duplicates what a "BIOS" did; at
best it's what makes things work.

	paul

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 23 Feb 1999 16:32:12 +0000 (GMT)

> I think the issue is that EBSA285 doesn't HAVE a BIOS.

I do have a BIOS like loader for the EBSA285, but is in dire need of a
cleanup in certain areas (which I know I must get around to).

> best it's what makes things work.

The PCI initialisation is hardware specific - there is no way to know
what an EBSA285 is plugged into, and therefore I'd prefer that on this
machine the kernel did NOT initialise the PCI bus.  In fact, my current
thinking is to reduce some of the initialisation that the kernel does on
EBSA285.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        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: "[email-masked]" <[email-masked]>
Date: Tue, 23 Feb 1999 17:34:32 +0000

>thinking is to reduce some of the initialisation that the kernel does on

The EBSA-285 is even more complicated than normal as it can run either
as an intelligent device or as the host bridge.  Host bridge is the standard
Intel PCI based system case.

There are two parts to the PCI initialisation.  The (standard) kernel
uses BIOS callbacks to discover the PCI topology (what devices on 
what buses using which addresses in what PCI spaces).  In the Alpha/MIPs
cases, there is system specific code that carries out the init functions
normally carried out by Intel BIOS.  It's a bit generalised but it
has to be system specific 'cos how PCI land is accessed and how interrupts
are routed is system specific.  That's handled by arch/alpha/kernel/bios32.c.
The generic code is in drivers/pci/pci.c and is the same across architectures.
I seem to remember 2.2.1 giving you the ability to completely re-init the
PCI subsystem though.

As for whether or not this code should be in the kernel is an interesting
question.  If it is not, then where does it go?  How does the kernel
figure out the PCI topology?   You could have a bootloader/console that
inits the PCI and hands off the PCI topology information to the kernel.
Given that the PCI system has been configured, the kernel could figure out
the topology itself (via configuration cycles) in a system independent
way.  

Without a console, you have to assume that the kernel has to do all of 
the work.   Most ARM systems do not have consoles.  In the Alpha case,
the Miniloader (MILO) uses the kernel PCI setup code and the kernel then
re-inits the PCI subsystem (a little sordid, but it works).

Dave
   _____

---

From: Philip Blundell <[email-masked]>
Date: Tue, 23 Feb 1999 18:45:44 +0000

>figure out the PCI topology?   You could have a bootloader/console that

I'd like to see it go in the kernel at least as an option.  With the exception 
of interrupt routing, the kernel can do as good a job of the PCI configuration 
as the console could.  On platforms where the interrupt lines are fixed 
(NetWinder and CATS for example, but not EBSA-285) it can do everything.

Also, experience shows that we tend to end up having code in the kernel to go 
through and fix up things that the console didn't do the way we wanted them in 
any case.  We might as well not bother and just let the kernel do the whole 
lot in the first place.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 23 Feb 1999 20:05:11 +0000 (GMT)

> Intel PCI based system case.

Indeed.  There are two different 'architectures' in the kernel (one is sitting
in my incoming patches and is available from Mark van Doesburg) which is the
'intelligent device' mode, and the EBSA285 case which is the stuff thats presently
in my kernels.

> I seem to remember 2.2.1 giving you the ability to completely re-init the

Indeed, and we make use if that exactly how the other architectures do.
However, when the EBSA285 is being used as a host bridge, it is responsible
for initialising the system and such like.

I'm not over thrilled by the idea of programming the kernel into flash -
this to me is too limited.  A better solution would be to have a BIOS-like
loader (MILO or whatever) that pulls the kernel off of whatever medium it
is stored on.  This is exactly the point behind my BIOS - to be generic.

> the topology itself (via configuration cycles) in a system independent

Indeed.

> re-inits the PCI subsystem (a little sordid, but it works).

Not necessarily - you still need to get the kernel from somewhere.  If you
have a small BIOS programmed into the flash, then that can give you so
many more options than a kernel could ever give you.  The BIOS could even
load the kernel from flash if you wanted it to.

I'm not talking here about replacing the EBSA angel loader btw, I'm talking
about supplementing it with a Linux Loader.

Now that 2.2's in the making, things were quietening down (until Linus
released 2.2.2 today), and I was going to clean up the last few bits in
my BIOS to get it out there...  There are loads of improvements that could
be made to it as it stands though.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        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: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 23 Feb 1999 20:23:47 +0000 (GMT)

> (NetWinder and CATS for example, but not EBSA-285) it can do everything.

Indeed - totally embedded machines like the NetWinder it is a good idea
since you know 100% what you're dealing with.  However, when talking about
a plug in card, I'd rather not have 50 different initialisation themes in
the kernel.

> any case.  We might as well not bother and just let the kernel do the whole 

I have two points here:

1. the kernel cannot possibly know the way the bus needs to be set up
   in every case. 

2. a freebios could set up the PCI bus how we wanted it in the first place,
   while releaving the kernel of the task of knowing system X, Y and Z's
   peculiarities.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        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: David A Rusling <[email-masked]>
Date: Wed, 24 Feb 1999 08:42:23 +0000

> 1. the kernel cannot possibly know the way the bus needs to be set up

Well, err, yes it can.   The Alpha/MIPs cases work on a huge variety of
systems.  The kernel can know as well as a BIOS how to set up a PCI subsystem.

>    while releaving the kernel of the task of knowing system X, Y and Z's

In this case, so long as you implement the PCI BIOS bits - these include
query callbacks to discover the PCI topology - then this is a perfectly
valid approach.  Its advantage would be that the kernels could remain
(or become) generic.   Of course, you'd still have to port the BIOS but that
couldn't be harder than porting a kernel.

I'm not saying that this is the right approach, but for MILO I embedded real
Linux device drivers into an environment that was a cut-down Linux kernel.
The advantage was the enormous set of device drivers, the disadvantage was
the need to have the code in the kernel in the first place.  If your BIOS
can be simpler then all to the good.  Have you seen uHAL?

Dave

-- 
----------------------------------------------------------------------
David A Rusling			Consulting Engineer
				ARM Limited
				Liberty House,
				Moorbridge Road,
				Maidenhead, SL6 8LT

				Tel: UK-(0)1628-427754
				Fax: UK-(0)1628-780551
				e-mail: [email-masked]
----------------------------------------------------------------------
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: christophe leroy <[email-masked]>
Date: Wed, 24 Feb 1999 09:35:30 +0000

>    while releaving the kernel of the task of knowing system X, Y and Z's

As far as I understand PCI, it seems that only IRQs are
backplane-specific. The other things are common to all PCI
implementations.
So I agree that we shouldn't do specific stuff in kernel,
so we could simply tell the kernel how card is wired and let it do
the remaining.

Only specific inits should be done in a mini bios. 

And couldn't we detect IRQ used by a PCI card, just like the  
detect them with ISA cards ?

Christophe

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 24 Feb 1999 10:10:33 +0000

>detect them with ISA cards ?

Err, no.   ISA IRQs are hardwired, unless you use plug and pray
where you tickle the card and see what wiggles (roughly speaking).
PCI IRQs relate to which pin on the device is used for interrupts,
which slot the PCI card is plugged into and which bus the slot is
attached to.   Interrupts are routed to an interrupt controller 
(eventually).  How those interrupts are routed is system/board
specific (slot 5, Pin A on bus 0 -> IRQ N).   Interrupts routed
through PCI-PCI bridges are twizzled (A->B, B->C, C->D, D->A).
The BIOS undestands this board specific interrupt routing and
writes the IRQ number into the PCI config header for the device.
It is read from there by the device driver and handed to the kernel
in request_irq().  The kernel's (board specific) interrupt handler
figures out which IRQ went ping and turns it into a number that 
matches the one that the BIOS wrote.  It's a symbiotic relationship.

Dave

ps I wrote how this works in my LDP book 'The Linux Kernel', 
chapter 6.

---

From: Philip Blundell <[email-masked]>
Date: Wed, 24 Feb 1999 13:17:40 +0000

>detect them with ISA cards ?

Not really.  PCI allows shared IRQs which rather knocks on the head any hope 
of being able to reliably probe for them.  Autoprobing IRQs never worked 
properly for ISA systems anyway and one of the advantages of PCI is that it 
provides a way to avoid this.  Going back to relying on autoprobe would 
definitely be a retrograde step.

p.

---

From: Russell King <[email-masked]>
Date: Wed, 24 Feb 1999 15:16:15 +0000 (GMT)

> systems.  The kernel can know as well as a BIOS how to set up a PCI

There are currently two implementations of the PCI interrupt fixup in the
kernel as it stands - one for EBSA285 in an EBSA285 backplane, and the other
for the CATS boards.  The CATS boards do not use the PCI pin designation
as far as I know, so the two are not mixed.

However, if you have an EBSA285 card plugged into joe bloggs backplane,
how do you discover how it's got the interrupt pins mapped?  You shouldn't
autoprobe the IRQs (since PCI isn't supposed to be autoprobed), and there's
nothing you can read to find out about the backplane.

> > 2. a freebios could set up the PCI bus how we wanted it in the first
> >    place, while releaving the kernel of the task of knowing system X,
> >    Y and Z's peculiarities.
> 

The PCI BIOS bits are already and have been implemented from the very
start.  There is no 'so long as' here - it's an always has been.

> I'm not saying that this is the right approach, but for MILO I embedded
> real Linux device drivers into an environment that was a cut-down Linux
> kernel.  The advantage was the enormous set of device drivers, the
> disadvantage was the need to have the code in the kernel in the first
> place.  If your BIOS can be simpler then all to the good.

The bios can be simpler, and does not actually require the complexities of
interrupts, process management etc operation at all.  In fact, it's probably
better because you could start with a core that is known stable, and get on
with the real job of porting the kernel rather than having to find ways of
loading kernels onto the EBSA285 board.

> Have you seen uHAL?

Yes.

PS, Am I right in saying that the Angel initialisation code does not probe
for the size of the SDRAMs?  I didn't notice any change in the setup of the
SDRAMs when I change the SDRAMs fitted.

---

From: Philip Blundell <[email-masked]>
Date: Wed, 24 Feb 1999 15:34:16 +0000

>The CATS boards do not use the PCI pin designation
>as far as I know,

As far as the kernel's concerned, yes that's right.

p.

---

From: christophe leroy <[email-masked]>
Date: Wed, 24 Feb 1999 16:29:52 +0000

> SDRAMs when I change the SDRAMs fitted.

There is a routine in target.s (angel sources) that is supposed
to detect memory size. It should be used by angel

christophe

---

From: Dave Baukus <[email-masked]>
Date: Thu, 25 Feb 1999 07:45:40 -0600

Any quick thoughts on the following NFS errors encountered during init
(rc.sysinit):

kernel: 2.2.1-rmk3, platform: ebsa285,root file system is NFS

Initializing random number generator             [  OK  ]
INIT: Entering runlevel: 3
Bringing up interface lo                         [  OK  ]
__nfs_fhget: inode 552755 busy, i_count=2, i_nlink=1
nfs_free_dentries: found subsys/random, d_count=0, hashed=1
nfs_dentry_delete: subsys/random: ino=552755, count=2, nlink=1
Starting portmapper:                             [  OK  ]
Mounting remote filesystems                      [  OK  ]
Initializing random number generator             [  OK  ]
Starting system loggers: nfs_refresh_inode: inode 121037 mode changed, 0144755
to 0020666
  syslogd: cannot create /dev/log: Input/output error
nfs_lookup_validate: dev/log has dud inode
__nfs_fhget: inode 121037 busy, i_count=2, i_nlink=1
nfs_free_dentries: found dev/log, d_count=1, hashed=0
__nfs_fhget: inode 121037 still busy, i_count=2
__nfs_fhget: killing dev/log filehandle

=========
Secondly, is it possible to swap to a NFS file via the loop device ?
Are patchs required ?

Thanks,

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 25 Feb 1999 20:00:45 +0000 (GMT)

> kernel: 2.2.1-rmk3, platform: ebsa285,root file system is NFS

Root-NFS'd filesystems do tend to produce more debug output from the NFS
client code.

> nfs_lookup_validate: dev/log has dud inode

Oops.  That tends to indicate that inode numbers are changing on the server.
What is your NFS server, and are there any other systems using this export?

> Secondly, is it possible to swap to a NFS file via the loop device ?

No.  The loopback device does not work on NFS filesystems.
   _____