linuxsh-dev

[linuxsh-dev] [PATCH] Preemptible kernel for SH

[Robert L. <rm...@te...>]

The attached is the fully preemptible linux kernel patch, for the SH
arch.  This work is thanks to Jeremy Siegel of MontaVista.

You will need an SH-patched kernel tree, available from
http://sf.net/projects/linuxsh -- the CVS module "linux" has a drop-in
replacement for 2.4.16.

You will need the base preempt-kernel patch, available from
ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-kernel

Feedback is desired.

	Robert Love

[linuxsh-dev] [PATCH] allow root device to be gdrom

[Robert L. <rm...@te...>]

The following patch allows the gdrom to be specified as a root device
(ie, root=/dev/gdrom on the command line) on the Dreamcast by adding an
identifier for it to the root_dev_names struct.  Thus an initrd is no
longer needed.

It is against my tree but should apply to the current CVS.  Not too sure
why no one ever found it missing before.  I don't know what it takes to
get it merged, but please?

	Robert Love

diff -urN linux-cvs/init/main.c linux/init/main.c
--- linux/init/main.c	Fri Nov  9 17:15:00 2001
+++ linux-dc/init/main.c	Fri Nov 30 01:19:17 2001
@@ -195,6 +195,7 @@
 	{ "scd",     0x0b00 },
 	{ "mcd",     0x1700 },
 	{ "cdu535",  0x1800 },
+	{ "gdrom",   0xFA00 },
 	{ "sonycd",  0x1800 },
 	{ "aztcd",   0x1d00 },
 	{ "cm206cd", 0x2000 },

Re: [linuxdc-dev]Re: [linuxsh-dev] Toolset

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Fri, Nov 30, 2001:

>=20
> > * Michael Grig <mg...@ho...> on Fri, Nov 30, 2001:
> > > Hi,
> > >
> > > Thanks for your quick response to my last message. Indeed upgrading to
> > > 3.0.2 with the lastest patch solved my problem.
>=20
>=20
> If there are new set of, patched, tools, is it worth trying to build QtE =
or=20
> QPE or Konq/E again?
>=20

Not likely, those are the ones I've been using.  It would take dedicated SH
hackers to fix some of the messes (thanks to kaz and NIIBE for their
efforts thus far) in binutils and GCC.

M. R.

Re: [linuxdc-dev]Re: [linuxsh-dev] Toolset

[Adrian M. <ad...@mc...>]

> * Michael Grig <mg...@ho...> on Fri, Nov 30, 2001:
> > Hi,
> >
> > Thanks for your quick response to my last message. Indeed upgrading to
> > 3.0.2 with the lastest patch solved my problem.


If there are new set of, patched, tools, is it worth trying to build QtE or 
QPE or Konq/E again?


Adrian

Re: [linuxsh-dev] Logging in from a serial console

[M. R. B. <mr...@0x...>]

* Michael Grig <mg...@ho...> on Fri, Nov 30, 2001:

> Hi,
>=20
> Thanks for your quick response to my last message. Indeed upgrading to
> 3.0.2 with the lastest patch solved my problem.
> On a related note, why are you guys using the 3.0 series anyway?
> Wouldn't it be better to stick with something stable, like 2.95.3,
> instead of having to continuously track a moving target?
>=20

The SH backend in GCC 2.95.x isn't stable enough.  Check the linux-sh and
linuxsh-dev mailing list archives for more info.

> Anyway, I decided to give the debian dc distro a try. Unfortunatly, as
> I still lack a DC keyboard, I have to log in from the serial terminal.
> (which should be possible according to the distro README).
>=20
> First I tried connecting (using minicom) to an already running system,
> but as that did not work, I devised a new strategy: I connect to the
> bootloader during the boot, interupt it, and issue:
> mount
> load -v /boot/vmlinux
> load -v -r -b 0x8c400000 /boot/initrd.gz
> exec -c "mem=3D16M init=3D/busybox console=3DttySC1,115200 /etc/profile"
>=20
> and it happily redirects all boot messages to the serial console,
> however when it gets to the login, it still issues it on the tty0
> and not on the serial console!!
>=20
> What am I missing here?
>=20

Hit return in minicom and you should see a login prompt.  This will work
even if the system has already booted.  You can see how this works in
/etc/inittab.

M. R.

[linuxsh-dev] Logging in from a serial console

[Michael G. <mg...@ho...>]

Hi,

Thanks for your quick response to my last message. Indeed upgrading to
3.0.2 with the lastest patch solved my problem.
On a related note, why are you guys using the 3.0 series anyway?
Wouldn't it be better to stick with something stable, like 2.95.3,
instead of having to continuously track a moving target?

Anyway, I decided to give the debian dc distro a try. Unfortunatly, as
I still lack a DC keyboard, I have to log in from the serial terminal.
(which should be possible according to the distro README).

First I tried connecting (using minicom) to an already running system,
but as that did not work, I devised a new strategy: I connect to the
bootloader during the boot, interupt it, and issue:
mount
load -v /boot/vmlinux
load -v -r -b 0x8c400000 /boot/initrd.gz
exec -c "mem=16M init=/busybox console=ttySC1,115200 /etc/profile"

and it happily redirects all boot messages to the serial console,
however when it gets to the login, it still issues it on the tty0
and not on the serial console!!

What am I missing here?

Thanks,
Mag.

Re: [linuxsh-dev] Kernel Compilation Problem: Invalid option `no-implicit-fp'

[M. R. B. <mr...@0x...>]

* Michael Grig <mg...@ho...> on Thu, Nov 29, 2001:

>=20
> The other kernel, the one that works, does "-m4-nofpu" instead of "-m4=20
> -mno-implicit-fp"
>=20
> So I guess my question is, is it a bug? Or am I doing something wrong?=20
> If so than what?
>=20

You need a recently patched GCC.  You can find one here:

  ftp://ftp.m17n.org/pub/super-h/testing/

M. R.

[linuxsh-dev] Kernel Compilation Problem: Invalid option `no-implicit-fp'

[Michael G. <mg...@ho...>]

Hi,

I am having some trouble compiling the kernel for my dreamcast (sh4). I 
got the binutils and the gcc going and I was can compile a kernel from 
the sources that I got from LinuxDC project, but the source that I got 
from your CVS won't compile.

I do:
mag@q:~/dreamcast/linux$ make ARCH=sh CROSS_COMPILE=sh4-linux- clean 
oldconfig dep zImage

and when it gets to the zImage target I get:
sh4-linux-gcc -D__KERNEL__ 
-I/home/mag/dreamcast/kernel/kernel.cvs/linux/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
-fno-strict-aliasing -fno-common -ml -m4 -mno-implicit-fp -pipe   -c -o 
init/main.o init/main.c
cc1: Invalid option `no-implicit-fp'
make: *** [init/main.o] Error 1

The other kernel, the one that works, does "-m4-nofpu" instead of "-m4 
-mno-implicit-fp"

So I guess my question is, is it a bug? Or am I doing something wrong? 
If so than what?

Thanks in advance,
Mag.

[linuxsh-dev] Kernel Update Permission?

[NIIBE Y. <gn...@m1...>]

Thanks, Jeremy and Paul.  For me, no problem at all.  Go ahead for
drop'in tree.

Jeremy Siegel wrote:
 > so are there any objections to an attempt to update the current
 > drop-in tree?

No.

 > I'd expect to do something like:
 >   1. Tag the current 2.4 branch as 13-pre2.
 >   2. Check in changes in the 2.4 branch for 2.4.15, updating AGAINST too.
 >   3. Tag the 2.4 branch as 2.4.15.
 >   4. Check in changes in the 2.4 branch for 2.4.16.
 >   5. Check in same changes as (2) in 2.5 branch, update AGAINST as needed.
 > 
 > Seem reasonable?

Yes.  I don't care for 2.4.1[45].

 > Is there some reason to wait?

I don't think we have.

BTW, someone sent me the note about we should _not_ use SourceForge
anymore for the sake of freedom, but I don't think it's relevant for
our usage.

			*	*	*

I haven't been able to doing for SuperH kernel things for a while,
sorry for no response.

While we're working for submitting patches to GCC list, well, everyone
knows, I've found it's quite hard to maintain patches and keep it
up-to-date against _current_ GCC.

I have been learning (somewhat special) CVS usage to avoid patch being
obsolete and losing someware, that is, mirroring CVS, using local branch
such as 1.1.999.  I'm not sure how it works, but I think that all the
changes required for GCC is now well maintained (better).
-- 

[linuxsh-dev] Kernel Update Permission?

[Jeremy S. <js...@mv...>]

Hi folks,

Some weeks ago Paul Mundt and I sent a tarball to SourceForge to replace
the
current drop-in tree with a nearly identical version including the old
history; I
expected to check in a 2.4.14 update when that happened.

However, it hasn't happened yet and we've no indication when it will; so
are
there any objections to an attempt to update the current drop-in tree?
I've not
done this before but I think it's straightforward CVS; no vendor imports
and
such like the old kernel module, just a few shared files which change.

I'd expect to do something like:
  1. Tag the current 2.4 branch as 13-pre2.
  2. Check in changes in the 2.4 branch for 2.4.15, updating AGAINST too.
  3. Tag the 2.4 branch as 2.4.15.
  4. Check in changes in the 2.4 branch for 2.4.16.
  5. Check in same changes as (2) in 2.5 branch, update AGAINST as needed.

Seem reasonable?  Or should I skip the 2.4.15 in the 2.4 branch
altogether?
(Alternatively, I could add a 2.4.14 check-in and tag, I suppose.)  Is
there
some reason to wait?  Would someone else prefer to do this?

Thanks for any feedback,

--Jeremy Siegel

Re: [linuxsh-dev] How to use an initrd?

[Stuart M. <Stu...@st...>]

On Nov 22,  7:55pm, cs/internet////////RFC-822/cs#a#emlix#f#com@hemloc wrote:
> Subject: Re: [linuxsh-dev] How to use an initrd?
> Hi Stuart,
> 
> On Thu, 22 Nov 2001, Stuart Menefy wrote:
> 
> [..]
> > One thing I did forget to mention, which may be causing some confusion.
> > The final ram disk size is fixed (ie it does not expand to accomodate
> > whatever data you put in it), although the memory it occupies is only
> > allocated as required.
> > 
> > The default size is chosen when you configure the kernel
> > (CONFIG_BLK_DEV_RAM_SIZE) and is usually 4M. However it can also be
> > overridden from the kernel command line with the "ramdisk_size=xxx" option,
> > where xxx is the size in K.
> 
> That option is *not* parsed in arch/sh/kernle/setup.c.

It is however parsed in drivers/block/rd.c

> > One other thing I should have mentioned. There is a good description
> > of how to create the initrd image in Documentation/initrd.txt in the
> > kernel source tree.
> 
> Yes, I've found that, but was wondering how to set things up without the help
> of a LILO.

Sorry, my mistake. I should have said Documentation/ramdisk.txt. What
I was referring to was simply the bit at the end which describes how
to create the ramdisk image.

> Besides all the great tips, initrd doesn't work for me....
> Here's my empty_zero_page setup (arch/sh/kernel/head.S):
> 
>        .section		  .empty_zero_page, "aw"
> ENTRY(empty_zero_page)
> 	.long	1		/* MOUNT_ROOT_RDONLY */
> 	.long	0		   /* RAMDISK_FLAGS */
> 	.long	0x0100		      /* ORIG_ROOT_DEV */
> 	.long	1			 /* LOADER_TYPE */
> 	.long	0x00300000		 /* INITRD_START */
> 	.long	0x00100000		 /* INITRD_SIZE */
> 	.long	0
> 	
> #ifdef CONFIG_CMDLINE_BOOL
>        .balign 0x100,0,0x100	/* COMMAND_LINE */
>        .string "mem=16m console=ttyS0,115200n8 init=/bin/sh"
> !      .string CONFIG_CMDLINE
> #endif /* CONFIG_CMDLINE_BOOL */
>        
>        .balign 4096,0,4096
> 
> My problem is, that the ezp somehow is not filled correctly after
> decompressing the kernel. I put a hexdump right at the top of
> arch/sh/kernel/setup_arch() and there's still some text strings from the
> bootloader... (no commandline either). Anyone an idea, why?

If you are using the compressed kernel, then one of the things which
happens while compressing the kernel code, is that the ezp gets stripped
off. Have a look for the objcopy in arch/sh/boot/compressed/Makefile.

Either:
 - boot the uncompressed kernel
 - modify the Makefile to not strip ezp (and remember to change the 
   initial value of output_ptr to reflect the fact that the kernel should
   be decompressed lower into memory)
 - hack misc.c to init the ezp
 - or get your loader to initialise ezp.

> Therefore all initrd setup with INITRD_START, etc. goes wrong. But even if I
> hardcode the above values to INITRD_START and INITRD_SIZE, which leads to
> correct values in the calls to reserve_bootmem_node(), the loading fails. 
> 
> What I found ist that in initrd_load() the offset for rd_load_image() is taken
> from rd_image_start, which in turn of the broken ezp is also broken. Why is
> rd_image_start relevant for an initrd?

This code was origionally written to support loading of a ramdisk from
a floppy disk. So rd_image_start is the offset (in blocks) into the device
which holds the ramdisk image. For an initrd image this must be 0.

This is initialised in arch/sh/kernel/setup.c from RAMDISK_FLAGS, which
is read from ezp + 0x04.

So if your ezp is not being set up, I suspect this value is ending up
as non-zero, and when trying to decompress the ramdisk image the kernel
is not looking at the beginning of the image but at some offset into it.

Stuart

Re: [linuxsh-dev] How to use an initrd?

[Alessandro R. <ru...@gn...>]

>> That should work. If you or someone else is interested in my
>> implementation, I'll post the real code and script tomorrow.
> 
> Yes, please.

Ok. This morning I managed to populate my ramdisk and boot, it works
fine, however the SCIF interrupts are not registered so I can't send
input to my shell (I only see SCI in /proc/interrupts). This is because
I use SCIF as console, and is independent of the ramdisk problem.

  BTW: can someone please point me to a libc suited for cross-compiling?
  Building one is tedious, and with the available packages I only managed
  to compile with horrible -I and -L arguments to the target, but
  only statical linking was possible. Thanks.

Like you, I have no full-featured boot loader, yet. I boot via an eprom
tailoerd for vxworks and I can only load a single ELF file from disk.

At the end you find the short patch that I used to make initrd work. To
convert the ramdisk to object file, use this Makefile:

    all: ramdisk.o
	    cp $^ linux/arch/sh/boot
    
    ramdisk.o: ramdisk.gz
	    sh4eb-linux-ld -r -T ramdisk.lds -b binary \
		      -o $@ $^
    
    ramdisk.gz: ramdisk
	    gzip < $^ > $@

ramdisk.lds is here:

    OUTPUT_FORMAT("elf32-shbig-linuxs")
    OUTPUT_ARCH(sh)
    SECTIONS
    {
      .data :
      {
	     __rd_start = .;
	     *(.data)
	     __rd_end = .;
      }
    }

The patch does what I described last time, plus it disables freeing
the ramdisk because it isn't aligned (I know it can be aligned
somehow, I just didn't go further on that path), so such freeing
released valuable memory as well and the kernel locked hard right
after mounting the fs; most likely because some allocation overwritten
valuable data.  Please note that the patch uses a new CONFIG option
for the platform we are using.

It's pretty dirty stuff, but it works fine to boot with a single file
if you can't do anything else.

--- ./arch/sh/kernel/Makefile.orig	Thu Nov 22 02:04:17 2001
+++ ./arch/sh/kernel/Makefile	Thu Nov 22 02:05:07 2001
@@ -23,6 +23,8 @@
 obj-$(CONFIG_SH_RTC)            += rtc.o
 obj-$(CONFIG_SH_DMA)		+= dma.o
 obj-$(CONFIG_SH_STANDARD_BIOS)	+= sh_bios.o
+obj-$(CONFIG_BLK_DEV_INITRD)    += ../boot/ramdisk.o
+
 
 ifeq ($(CONFIG_PCI),y)
 ifeq ($(CONFIG_SH_DREAMCAST),y)
--- ./arch/sh/kernel/setup.c.orig	Thu Nov 22 02:08:16 2001
+++ ./arch/sh/kernel/setup.c	Thu Nov 22 02:18:05 2001
@@ -438,6 +438,15 @@
 	reserve_bootmem_node(NODE_DATA(0), __MEMORY_START, PAGE_SIZE);
 
 #ifdef CONFIG_BLK_DEV_INITRD
+#ifdef CONFIG_SH_GX8TSU
+	{
+        extern void * __rd_start, * __rd_end;
+
+        initrd_start = (unsigned long)&__rd_start;
+        initrd_end = (unsigned long)&__rd_end;
+        initrd_below_start_ok = 1;
+	}
+#else
 	if (LOADER_TYPE && INITRD_START) {
 		if (INITRD_START + INITRD_SIZE <= (max_low_pfn << PAGE_SHIFT)) {
 			reserve_bootmem_node(NODE_DATA(0), INITRD_START+__MEMORY_START, INITRD_SIZE);
@@ -452,6 +461,7 @@
 			initrd_start = 0;
 		}
 	}
+#endif /* GX8TSU */
 #endif
 
 #if 0
--- ./arch/sh/mm/init.c.orig	Thu Nov 22 16:04:36 2001
+++ ./arch/sh/mm/init.c	Thu Nov 22 16:05:32 2001
@@ -193,6 +193,7 @@
 #ifdef CONFIG_BLK_DEV_INITRD
 void free_initrd_mem(unsigned long start, unsigned long end)
 {
+#if 0 /* GX8 tmp hack */
 	unsigned long p;
 	for (p = start; p < end; p += PAGE_SIZE) {
 		ClearPageReserved(virt_to_page(p));
@@ -201,6 +202,7 @@
 		totalram_pages++;
 	}
 	printk ("Freeing initrd memory: %ldk freed\n", (end - start) >> 10);
+#endif
 }
 #endif
 

Re: [linuxsh-dev] How to use an initrd?

[Cord S. <cs...@em...>]

Hi Alessandro,

On Thu, 22 Nov 2001, Alessandro Rubini wrote:

> 
> > I've to use S-records, which I generate with objcopy. But the loader only
> > permits one upload with one start address. Guess, I've to combine two
> > S-records into one file. That should work, shouldn't it?
> 
> You can also link the ramdisk inside the kernel. I've done that for
> mips one year ago (it was the standard for PDA devices), and I'm going
> to it today or tomorrow on my sh box.
> 
> What you should do is this:
> - convert the ext2/whatever image to an object file with
> 	objcopy and set the __rd_start and __rd_end symbols
> - link it in by adding the object file to the Makefile
> - add this in place of the code that uses the empy_zero_page header:
> 
>         extern void * __rd_start, * __rd_end;
>         initrd_start = (unsigned long)&__rd_start;
>         initrd_end = (unsigned long)&__rd_end;
>         initrd_below_start_ok = 1;
> 
> That should work. If you or someone else is interested in my
> implementation, I'll post the real code and script tomorrow.

Yes, please.

Since I'm having wired problems with initrd (see my response to Stuart), I
would try your way next.

Is the SH port perhaps missing something for initrd to work?

	Cord

Re: [linuxsh-dev] How to use an initrd?

[Cord S. <cs...@em...>]

Hi Stuart,

On Thu, 22 Nov 2001, Stuart Menefy wrote:

[..]
> Yep, S-records have the address for each line, so simply concatinating
> them should work fine.

Yes, works. I just need to manipulate S0 and S7 records.

> > >    The image needs to be loaded into memory which the kernel knows about,
> > >    so don't try and load the image into what, for the kernel's point of
> > >    view, is unused memory.
> > 
> > The address is not important? I.e. right after the compressed image or near
> > the upper limit of RAM? How does the kernel know where to move the
> > uncompressed data to? Can it be compressed at all? At offset 0x14 below, the
> > initrd size corresponds to the image in RAM after uploading, doesn't it?
> 
> Correct, the address is not important. However it does need to be above
> the kernel text and data, plus the kernel's page map, so near the top of
> memory is good.
> 
> The way this works:
>  - kernel sets up free page list for the whole of memory. Initially all
>    pages are free, so the next thing it does is mark the kernel code and
>    data pages, plus the pages the page list itself occupies, as in use.
>  - the kernel then marks the initrd memory as in use (which is why it needs
>    to be part of the known memory map).
>  - the image is then decompressed, pages for the decompressed image just
>    being allocated as normal from the free page list.
>  - finally the initrd memory is marked as free

That makes things more clear, thanks. But there're still problems (s. below).

> So the decompressed image can be anywhere in memory, you don't need to
> known or care.
> 
> Yes, it can be compressed, just use gzip.

Ah, I had a closer look and found the autodetection routine.

> The initrd size at offset 0x14 corrisponds to the compressed size (it
> is this which is used to mark the initrd pages as occupied in the second
> step above).
> 
> One thing I did forget to mention, which may be causing some confusion.
> The final ram disk size is fixed (ie it does not expand to accomodate
> whatever data you put in it), although the memory it occupies is only
> allocated as required.
> 
> The default size is chosen when you configure the kernel
> (CONFIG_BLK_DEV_RAM_SIZE) and is usually 4M. However it can also be
> overridden from the kernel command line with the "ramdisk_size=xxx" option,
> where xxx is the size in K.

That option is *not* parsed in arch/sh/kernle/setup.c.

> One other thing I should have mentioned. There is a good description
> of how to create the initrd image in Documentation/initrd.txt in the
> kernel source tree.

Yes, I've found that, but was wondering how to set things up without the help
of a LILO.

> > >  - telling the kernel where the image is simply involves modifying
> > >    a few workds of memory near the start of the kernel image. These
> > >    corrispond to the C symbol empty_zero_page, which is 4K from the
> > >    start of kernel memory:
> > > 
> > >       empty_zero_page + 0x00: mount root read only
> > >                       + 0x04: ramdisk flags
> > >                       + 0x08: root device
> > >                       + 0x0c: loader type
> > >                       + 0x10: initrd start
> > >                       + 0x14: initrd size
> > >                       + 0x100: kernel command line
> > > 
> > >    The only words you should need to modify are:
> > >      + 0x0c: loader type - set to 1
> > >      + 0x10: initrd start - set to the offset of the image from the start
> > >              of kernel memory (CONFIG_MEMORY_START)
> > >      + 0x14: initrd size - size of the initrd image
> > 
> > Yes, I've found the ezp, but I thought it would be more difficult ;-)

Besides all the great tips, initrd doesn't work for me....
Here's my empty_zero_page setup (arch/sh/kernel/head.S):

       .section		  .empty_zero_page, "aw"
ENTRY(empty_zero_page)
	.long	1		/* MOUNT_ROOT_RDONLY */
	.long	0		   /* RAMDISK_FLAGS */
	.long	0x0100		      /* ORIG_ROOT_DEV */
	.long	1			 /* LOADER_TYPE */
	.long	0x00300000		 /* INITRD_START */
	.long	0x00100000		 /* INITRD_SIZE */
	.long	0
	
#ifdef CONFIG_CMDLINE_BOOL
       .balign 0x100,0,0x100	/* COMMAND_LINE */
       .string "mem=16m console=ttyS0,115200n8 init=/bin/sh"
!      .string CONFIG_CMDLINE
#endif /* CONFIG_CMDLINE_BOOL */
       
       .balign 4096,0,4096

My problem is, that the ezp somehow is not filled correctly after
decompressing the kernel. I put a hexdump right at the top of
arch/sh/kernel/setup_arch() and there's still some text strings from the
bootloader... (no commandline either). Anyone an idea, why?

Therefore all initrd setup with INITRD_START, etc. goes wrong. But even if I
hardcode the above values to INITRD_START and INITRD_SIZE, which leads to
correct values in the calls to reserve_bootmem_node(), the loading fails. 

What I found ist that in initrd_load() the offset for rd_load_image() is taken
from rd_image_start, which in turn of the broken ezp is also broken. Why is
rd_image_start relevant for an initrd?

Any ideas? Thanks.

	Cord

Re: [linuxsh-dev] How to use an initrd?

[Alessandro R. <ru...@gn...>]

> I've to use S-records, which I generate with objcopy. But the loader only
> permits one upload with one start address. Guess, I've to combine two
> S-records into one file. That should work, shouldn't it?

You can also link the ramdisk inside the kernel. I've done that for
mips one year ago (it was the standard for PDA devices), and I'm going
to it today or tomorrow on my sh box.

What you should do is this:
- convert the ext2/whatever image to an object file with
	objcopy and set the __rd_start and __rd_end symbols
- link it in by adding the object file to the Makefile
- add this in place of the code that uses the empy_zero_page header:

        extern void * __rd_start, * __rd_end;
        initrd_start = (unsigned long)&__rd_start;
        initrd_end = (unsigned long)&__rd_end;
        initrd_below_start_ok = 1;

That should work. If you or someone else is interested in my
implementation, I'll post the real code and script tomorrow.

/alessandro

Re: [linuxsh-dev] How to use an initrd?

[Stuart M. <Stu...@st...>]

On Nov 21,  9:42pm, cs/internet////////RFC-822/cs#a#emlix#f#com@hemloc wrote:
> Subject: Re: [linuxsh-dev] How to use an initrd?
> Hi Stuart,
> 
> many thanks for the detailed help. Still some questions, s. below:
> 
> On Wed, 21 Nov 2001, Stuart Menefy wrote:
> 
> > Cord
> > 
> > Its pretty simple. Assuming you have a ramdisk image, you simply need
> > to load it into memory, and tell the kernel where it is:
> > 
> >  - loading will depend on what tools you are using to download your kernel.
> >    If you have a loader which supports the downloading of binary files,
> >    that it simple. If you are using a tool like gdb, which only supports
> >    the downloading of elf files, or a loader which can only use S-records
> >    or similar, ld or objcopy can be used to convert to the appropriate
> >    format.
> 
> I've to use S-records, which I generate with objcopy. But the loader only
> permits one upload with one start address. Guess, I've to combine two
> S-records into one file. That should work, shouldn't it?

Yep, S-records have the address for each line, so simply concatinating
them should work fine.

> >    The image needs to be loaded into memory which the kernel knows about,
> >    so don't try and load the image into what, for the kernel's point of
> >    view, is unused memory.
> 
> The address is not important? I.e. right after the compressed image or near
> the upper limit of RAM? How does the kernel know where to move the
> uncompressed data to? Can it be compressed at all? At offset 0x14 below, the
> initrd size corresponds to the image in RAM after uploading, doesn't it?

Correct, the address is not important. However it does need to be above
the kernel text and data, plus the kernel's page map, so near the top of
memory is good.

The way this works:
 - kernel sets up free page list for the whole of memory. Initially all
   pages are free, so the next thing it does is mark the kernel code and
   data pages, plus the pages the page list itself occupies, as in use.
 - the kernel then marks the initrd memory as in use (which is why it needs
   to be part of the known memory map).
 - the image is then decompressed, pages for the decompressed image just
   being allocated as normal from the free page list.
 - finally the initrd memory is marked as free

So the decompressed image can be anywhere in memory, you don't need to
known or care.

Yes, it can be compressed, just use gzip.

The initrd size at offset 0x14 corrisponds to the compressed size (it
is this which is used to mark the initrd pages as occupied in the second
step above).

One thing I did forget to mention, which may be causing some confusion.
The final ram disk size is fixed (ie it does not expand to accomodate
whatever data you put in it), although the memory it occupies is only
allocated as required.

The default size is chosen when you configure the kernel
(CONFIG_BLK_DEV_RAM_SIZE) and is usually 4M. However it can also be
overridden from the kernel command line with the "ramdisk_size=xxx" option,
where xxx is the size in K.

One other thing I should have mentioned. There is a good description
of how to create the initrd image in Documentation/initrd.txt in the
kernel source tree.


> >  - telling the kernel where the image is simply involves modifying
> >    a few workds of memory near the start of the kernel image. These
> >    corrispond to the C symbol empty_zero_page, which is 4K from the
> >    start of kernel memory:
> > 
> >       empty_zero_page + 0x00: mount root read only
> >                       + 0x04: ramdisk flags
> >                       + 0x08: root device
> >                       + 0x0c: loader type
> >                       + 0x10: initrd start
> >                       + 0x14: initrd size
> >                       + 0x100: kernel command line
> > 
> >    The only words you should need to modify are:
> >      + 0x0c: loader type - set to 1
> >      + 0x10: initrd start - set to the offset of the image from the start
> >              of kernel memory (CONFIG_MEMORY_START)
> >      + 0x14: initrd size - size of the initrd image
> 
> Yes, I've found the ezp, but I thought it would be more difficult ;-)
> 
> >    Again, how you do this depends of what tools you are using. You might
> >    want to have a look at the gdb start up scripts which are part of the
> >    CVS kernel sources, in the root of the kernel sources - .gdbinit-dmida
> >    is a well commented example.
> 
> I'll look at it.
> 
> > Hope this helps
> 
> Definitely. Thanks again!
> 	Cord
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> 
> 
>-- End of excerpt from cs/internet////////RFC-822/cs#a#emlix#f#com@hemloc

Re: [linuxsh-dev] How to use an initrd?

[Cord S. <cs...@em...>]

Hi Stuart,

many thanks for the detailed help. Still some questions, s. below:

On Wed, 21 Nov 2001, Stuart Menefy wrote:

> Cord
> 
> Its pretty simple. Assuming you have a ramdisk image, you simply need
> to load it into memory, and tell the kernel where it is:
> 
>  - loading will depend on what tools you are using to download your kernel.
>    If you have a loader which supports the downloading of binary files,
>    that it simple. If you are using a tool like gdb, which only supports
>    the downloading of elf files, or a loader which can only use S-records
>    or similar, ld or objcopy can be used to convert to the appropriate
>    format.

I've to use S-records, which I generate with objcopy. But the loader only
permits one upload with one start address. Guess, I've to combine two
S-records into one file. That should work, shouldn't it?

>    The image needs to be loaded into memory which the kernel knows about,
>    so don't try and load the image into what, for the kernel's point of
>    view, is unused memory.

The address is not important? I.e. right after the compressed image or near
the upper limit of RAM? How does the kernel know where to move the
uncompressed data to? Can it be compressed at all? At offset 0x14 below, the
initrd size corresponds to the image in RAM after uploading, doesn't it?

>  - telling the kernel where the image is simply involves modifying
>    a few workds of memory near the start of the kernel image. These
>    corrispond to the C symbol empty_zero_page, which is 4K from the
>    start of kernel memory:
> 
>       empty_zero_page + 0x00: mount root read only
>                       + 0x04: ramdisk flags
>                       + 0x08: root device
>                       + 0x0c: loader type
>                       + 0x10: initrd start
>                       + 0x14: initrd size
>                       + 0x100: kernel command line
> 
>    The only words you should need to modify are:
>      + 0x0c: loader type - set to 1
>      + 0x10: initrd start - set to the offset of the image from the start
>              of kernel memory (CONFIG_MEMORY_START)
>      + 0x14: initrd size - size of the initrd image

Yes, I've found the ezp, but I thought it would be more difficult ;-)

>    Again, how you do this depends of what tools you are using. You might
>    want to have a look at the gdb start up scripts which are part of the
>    CVS kernel sources, in the root of the kernel sources - .gdbinit-dmida
>    is a well commented example.

I'll look at it.

> Hope this helps

Definitely. Thanks again!

	Cord

Re: [linuxsh-dev] How to use an initrd?

[Stuart M. <Stu...@st...>]

Cord

Its pretty simple. Assuming you have a ramdisk image, you simply need
to load it into memory, and tell the kernel where it is:

 - loading will depend on what tools you are using to download your kernel.
   If you have a loader which supports the downloading of binary files,
   that it simple. If you are using a tool like gdb, which only supports
   the downloading of elf files, or a loader which can only use S-records
   or similar, ld or objcopy can be used to convert to the appropriate
   format.

   The image needs to be loaded into memory which the kernel knows about,
   so don't try and load the image into what, for the kernel's point of
   view, is unused memory.

 - telling the kernel where the image is simply involves modifying
   a few workds of memory near the start of the kernel image. These
   corrispond to the C symbol empty_zero_page, which is 4K from the
   start of kernel memory:

      empty_zero_page + 0x00: mount root read only
                      + 0x04: ramdisk flags
                      + 0x08: root device
                      + 0x0c: loader type
                      + 0x10: initrd start
                      + 0x14: initrd size
                      + 0x100: kernel command line

   The only words you should need to modify are:
     + 0x0c: loader type - set to 1
     + 0x10: initrd start - set to the offset of the image from the start
             of kernel memory (CONFIG_MEMORY_START)
     + 0x14: initrd size - size of the initrd image

   Again, how you do this depends of what tools you are using. You might
   want to have a look at the gdb start up scripts which are part of the
   CVS kernel sources, in the root of the kernel sources - .gdbinit-dmida
   is a well commented example.

Hope this helps

Stuart



On Nov 21,  6:01pm, cs...@em... wrote:
> Subject: [linuxsh-dev] How to use an initrd?
> Hi everyone,
> 
> I'm new to Linux on SH and try to get a custom board running. I am using the
> 2.4.13 kernel from the LinuxSH CVS and can load it up to my board. I managed
> to hack the serial console to come out on the HD64465 UART (the only serial
> line connected on my board). The kernel boots and find some minimal hardware.
> Since I don't have network yet, I want to load an initrd/ramdisk with the
> kernel image. Can anyone provide me with some hints on how to do this for the
> SH environment?
> 
> Thanks for any help.
> 
> 	Cord
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> 
> 
>-- End of excerpt from cs...@em...

Re: [linux-sh:02005] Re: [linuxsh-dev] New in the group

[Fabio G. <fg...@ti...>]

Ok. Thanks.

On Wednesday 21 November 2001 15:46, Greg Banks wrote:
> fabio giovagnini wrote:
> > > > > 4) Is anyone using the SED 1355 framebuffer device?
> >
> > Did you test it?
>
>   No.
>
> > Is it working
>
>   Presumably it works for the author.  See the comment in
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linuxsh/linux/drivers/video/
>epson1355fb.c?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup
>
> > >   Yes.  There are drivers for it in CVS.  I also have a different
> > > driver for it that I'm unable to release for reasons I don't want to go
> > > into.
> >
> > Did you test it, too?
>
>   Yes.
>
> > Could you send me a copy?
>
>   No. I wish I could.
>
> Greg.

[linuxsh-dev] How to use an initrd?

[Cord S. <cs...@em...>]

Hi everyone,

I'm new to Linux on SH and try to get a custom board running. I am using the
2.4.13 kernel from the LinuxSH CVS and can load it up to my board. I managed
to hack the serial console to come out on the HD64465 UART (the only serial
line connected on my board). The kernel boots and find some minimal hardware.
Since I don't have network yet, I want to load an initrd/ramdisk with the
kernel image. Can anyone provide me with some hints on how to do this for the
SH environment?

Thanks for any help.

	Cord

Re: [linux-sh:02004] Re: [linuxsh-dev] New in the group

[Greg B. <gn...@al...>]

fabio giovagnini wrote:
> 
> > >
> > > > 4) Is anyone using the SED 1355 framebuffer device?
> > >
> Did you test it? 

  No.

> Is it working

  Presumably it works for the author.  See the comment in
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linuxsh/linux/drivers/video/epson1355fb.c?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup


> >   Yes.  There are drivers for it in CVS.  I also have a different driver
> > for it that I'm unable to release for reasons I don't want to go into.
> 
> Did you test it, too?

  Yes.

> Could you send me a copy?

  No. I wish I could.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

Re: [linux-sh:02002] Re: [linuxsh-dev] New in the group

[fabio g. <fg...@ti...>]

----- Original Message -----
From: "Greg Banks" <gn...@al...>
To: "Jeremy Siegel" <js...@mv...>
Cc: <fg...@ti...>; <lin...@li...>;
<lin...@m1...>
Sent: Wednesday, November 21, 2001 6:31 AM
Subject: Re: [linux-sh:02002] Re: [linuxsh-dev] New in the group


> Jeremy Siegel wrote:
> >
> >
> > > 4) Is anyone using the SED 1355 framebuffer device?
> >
Did you test it? Is it working

>
>   Yes.  There are drivers for it in CVS.  I also have a different driver
> for it that I'm unable to release for reasons I don't want to go into.

Did you test it, too?
Could you send me a copy?

Fabio

>
> Greg.
> --
> the price of civilisation today is a courageous willingness to prevail,
> with force, if necessary, against whatever vicious and uncomprehending
> enemies try to strike it down.    - Roger Sandall, The Age, 28Sep2001.
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>

Fw: [linuxsh-dev] epson card e09

[fabio g. <fg...@ti...>]

----- Original Message ----- 
From: "fabio giovagnini" <fg...@ti...>
To: "stephan knabe" <sk...@sy...>
Sent: Wednesday, November 21, 2001 8:54 AM
Subject: Re: [linuxsh-dev] epson card e09


> 
> ----- Original Message ----- 
> From: "stephan knabe" <sk...@sy...>
> To: "fabio giovagnini" <fg...@ti...>
> Cc: <lin...@li...>
> Sent: Tuesday, November 20, 2001 6:43 PM
> Subject: Re: [linuxsh-dev] epson card e09
> 
> 
> > fabio giovagnini wrote:
> > 
> > > Were you able to boot with sh-ipl+g and sh-lilo?
> > 
> > these are the next steps on my list. until now i am able to run my own
> > sbr which loads stuff from cf and starts it.
> 
> If I understand good, you boot directly form CF. Don't you need a BIOS?
> Are you using native BIOS of the card (WinCE BIOS) ?
> 
> Let me know.
> 
> Regards?
> 
> 
> >  
> > > If  I'll know somthing I'll write to you.
> > 
> > i'll do so too.
> > 
> > stephan knabe
> > mailto: sk...@sy...
> > 
> > _______________________________________________
> > linuxsh-dev mailing list
> > lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> > 
> 

Re: [linux-sh:02002] Re: [linuxsh-dev] New in the group

[Greg B. <gn...@al...>]

Jeremy Siegel wrote:
> 
> 
> > 4) Is anyone using the SED 1355 framebuffer device?
> 

  Yes.  There are drivers for it in CVS.  I also have a different driver
for it that I'm unable to release for reasons I don't want to go into.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

Re: [linuxsh-dev] New in the group

[Jeremy S. <js...@mv...>]

Fabio Giovagnini wrote:

> 1) in linuxsh.sourceforge.net I can find CVS-web with:
>         kernel/
>         linux/
>         linuxsh-web/
>         sh-boot/
>
> Could anyone describe the meaning of these ones (kernel is the shlinux
> kernel, if I understand good);

I assume you've gotten a response already, but just in case here's all I know:

Yes, the kernel module is the full shlinux kernel.  It has no CVS branch structure
I'm aware of (so your description of how to get it is accurate).  The linux module
is a "drop-in" tree, i.e. files you "drop-in" over a generic (e.g. kernel.org) kernel
(easily done using the linux/scripts/treelink.sh script).  The current linux module
has two CVS branches (current 2.4 and future 2.5), however there is a request in
progress [as far as we know!] to replace it with a new one which will include the
kernel module history, and likely won't branch until 2.5 actually starts.

You can use either; both are effectively at the 2.4.13-pre2 level for now.  See the
mailing list archives from October/November for a better idea of status.

As you must have seen, linuxsh-web is the website source, and sh-boot is a copy
of sh-ipl+g (though I don't think it's kept up-to-date with versions at m17n.org).
I don't think there's a later version of the website docs, but they may not be fully
up-to-date.

> 4) Is anyone using the SED 1355 framebuffer device?

Not me.  Talk to the Dreamcast folk (Marcus?)

> 5) Can I use the gcc-core 3.0.1 the compile the kernel?

If you've heard nothing else, check www.sh-linux.org and
maybe m17n.org/linux-sh.

--Jeremy Siegel