linuxsh-dev

Re: [linuxsh-dev] [linux-sh:01255] Re: ROMable image

[Jesper S. <js...@re...>]

>>>>> "Greg" == Greg Banks <gb...@po...> writes:
Greg>   I tried a small test: the 59K of .data sections in my current
Greg> kernel image gzip's down to a measly 8K, which is pretty good
Greg> compression.  But a quick inspection reveals why: about 48K of
Greg> that 59K are zero bytes.  So I suspect there are a lot of
Greg> variables which could sensibly go into .bss instead of
Greg> cluttering up .data, even a compressed .data.  Once you consider
Greg> the code needed to uncompress the .data, it may well be that the
Greg> more useful optimisation would be to move variables to .bss
Greg> instead of compressing .data.  In any case I think it would be
Greg> useful to investigate.

Somewhat related to that, it may be possible to save some space by
rearranging sections - there are some pretty big alignments (8k & 4k)
in there which probably leave big holes in the image.

Jesper

Re: [linuxsh-dev] [linux-sh:01255] Re: ROMable image

[Greg B. <gb...@po...>]

NIIBE Yutaka wrote:
> 
> To do that, it's good to define the meaning of vmlinux, the Kernel
> Image.  I'd like to keep this image as the one after "loaded".
> Specifically, don't change the LMA of vmlinux for ROM here.  It's
> better to have another step getting ROM image from vmlinux, and
> let the loader to load data section into RAM.
> 
> Why?  I'm thinking about the case where we compress the image of data
> section on ROM, people may introduce such feature when ROM is small.

  So the idea is to have the .text and .rodata uncompressed and linked
for XIP, but the .data compressed in ROM and copied to RAM?  Interesting.

  I tried a small test: the 59K of .data sections in my current kernel
image gzip's down to a measly 8K, which is pretty good compression.  But a
quick inspection reveals why: about 48K of that 59K are zero bytes.  So I
suspect there are a lot of variables which could sensibly go into .bss
instead of cluttering up .data, even a compressed .data.  Once you consider
the code needed to uncompress the .data, it may well be that the more useful
optimisation would be to move variables to .bss instead of compressing
.data.  In any case I think it would be useful to investigate.

  This is perhaps a little off-topic, but Mitch found the following
interesting article on reducing the size of the kernel's .data and .bss
sections.  We haven't actually tried any of these things, but mostly they
sound feasible.  The author claims to have achieved a .data of 41K and a
.bss of 15K (!!).  For comparison the figures for the kernel I'm currently
running are 59K and 134K respectively.

> 
> 
> 
>      Subject: 
>              Re: [Handhelds] Linux may be abandoned for WinCE here.
>        Date: 
>              19 Jul 2000 08:52:02 +0200
>        From: 
>              lars brinkhoff <la...@no...>
>          To: 
>              ow...@ca...
>          CC: 
>              han...@ha..., la...@la..., lin...@wa...
>  Newsgroups: 
>              comp.os.linux.development.system, comp.os.linux.misc, comp.os.linux.advocacy
> 
> 
> 
> The following message is a courtesy copy of an article
> that has been posted to comp.os.linux.development.system,comp.os.linux.misc,comp.os.linux.advocacy
> as well.
> 
> *** I'd be very interested in hearing about work done by others ***
> *** to reduce the size of Linux.  I already know about Graham   ***
> *** Stoney's CONFIG_MESSAGES and dead function optimisation     ***
> *** patches.                                                    ***
> 
> Wallace Owen wrote:
> > Can anyone tell me what files in the Linux kernel have data
> > declarations whose dimensions can be safely reduced?  My efforts
> > at producing a small kernel have got the code segment down below
> > half a meg, but the data segment is 1.5 megabytes.
> 
> I started a port of Linux 2.3.99 to our MIPS R3000-ish device (IDT
> RC32064, really).  This device usually has 2M flash and 4M RAM.
> 
> To reduce the size of the text and data sections, I sorted the output
> of the "size" command and investigated the files with the largest
> sections.
> 
> These are the memory-saving changes I arrived at.  They are not really
> tested, so some of them may break some functionality.
> 
> fs/dcache.c
> 
>         Changed HASH_BITS from 14 to 8.  This reduces the size of the
>         cache from 128K to 2K.
> 
> fs/inode.c
> 
>         Changed HASH_BITS from 14 to 8.  This reduces the size of the
>         cache from 128K to 2K.
> 
> include/linux/blk.h
> 
>         Changed NR_REQUEST from 256 to 16.  This reduces the number of
>         requests that can be queued.  The size of the queue is reduce
>         from 16K to 1K.
> 
> include/linux/major.h
> 
>         Changed MAX_BLKDEV and MAX_CHRDEV from 256 to 10 and 20,
>         respectively.  This reduces the number of block and character
>         devices and saves about 40K.
> 
> kernel/printk.c
> 
>         Changed LOG_BUF_LEN from 16384 bytes to 2048 bytes.
> 
> include/linux/tty.h
> 
>         Changed NR_PTYS and NR_LDISCS from 256 and 16, respectively,
>         to 16 and 4, respectively.  Saved about 12K.
> 
>         Warning: this change may break the pty driver, in which
>         case further modifications will have to be done to
>         drivers/char/pty.c.
> 
> kernel/panic.c
> 
>         Changed a buffer from 1024 bytes to 200 bytes.
> 
> include/linux/sched.h
> 
>         Changed PIDHASH_SZ from 1024 to 16, which saves
>         1008 bytes.
> 
> arch/mips/kernel/entry.S
> 
>         (Has 21184 bytes of data which might be trimmed?)
> 
> include/linux/mmzone.h
> 
>         NR_GPFINDEX from 0x100 to 0x10.  Saves 4800 bytes,
>         but I'm not sure it doesn't break anything.
> 
> net/Makefile, net/socket.c, net/nosocket.c
> 
>         Replacing socket.c with nosocket.c, a file containing
>         dummy replacement functions for those in socket.c, saves
>         about 24K.
> 
>         Warning: this disables the socket API entirely, but it
>         is currently not used in our product.
> 
> net/Makefile, net/network.a, net/core
> 
>         Excluding net/core/core.o from net/network.a doesn't save
>         anything.  I guess core.o isn't referenced by anything
>         in the rest of the kernel (except maybe socket.c, see
>         above).
> 
> mm/Makefile, mm/swapfile.c, mm/swap_state.c, mm/noswapfile.c, mm/noswap_state.c
> 
>         Replacing swapfile.c with noswapfile.c, and swap_state.c with
>         noswap_state.c saves about 12K.  The no*.c files contains empty
>         replacement functions.
> 
>         Warning: this disables swapping of anonymous memory, which isn't
>         used in our product.  But note that demand paging of executables
>         still works.
> 
> mm/Makefile, mm/mmap.c
> 
>         The functions in mmap.c could probably also be replaced by
>         empty functions.  Estimated saving: 9K (not included in the
>         grand total below).
> 
> *, CONFIG_MESSAGES
> 
>         Applying the CONFIG_MESSAGES patch and disabling all
>         kernel messages saves about 80K.
> 
>         The CONFIG_MESSAGES patch was written by Graham Stoney
>         <gr...@re...>.
> 
> With all of the above, and only this enabled in .config:
>         CONFIG_EXPERIMENTAL=y
>         CONFIG_CPU_R3000=y
>         CONFIG_CPU_LITTLE_ENDIAN=y
>         CONFIG_ELF_KERNEL=y
>         CONFIG_BINFMT_ELF=y
>         CONFIG_MODULES=y
>         CONFIG_MODVERSIONS=y
>         CONFIG_KMOD=y
>         CONFIG_CROSSCOMPILE=y
> , the kernel is down to about 550K.
> 
> Here is the output of "size vmlinux".  I think this is without the
> CONFIG_MESSAGES patch (it was many months since I worked with this).
> 
> text    data    bss     dec     hex     filename
> 572128  41964   15860   629952  99cc0   vmlinux
> 
> --
> To unsubscribe from this list, send a message to maj...@wa...
> with the command "unsubscribe linux-embedded" in the message body.
> For more information, see <http://waste.org/mail/linux-embedded>.
> 


Greg.
-- 
These are my opinions not PPIs.

Re: [linuxsh-dev] [linux-sh:01255] Re: ROMable image

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

Jesper Skov wrote:
 > eXecute In Place - it's the usual phrase used to describe executing
 > from ROM. At least it's used a lot in Cygnus/Red Hat (full of embedded
 > developers) and I also noticed it in the PCMCIA documentation the
 > other day. I think XIP is the proper word to use.

Thanks for the information.  I'd like to incorporate the changes to
support kernel "eXecute In Place" on the ROM.

To do that, it's good to define the meaning of vmlinux, the Kernel
Image.  I'd like to keep this image as the one after "loaded".
Specifically, don't change the LMA of vmlinux for ROM here.  It's
better to have another step getting ROM image from vmlinux, and
let the loader to load data section into RAM.

Why?  I'm thinking about the case where we compress the image of data
section on ROM, people may introduce such feature when ROM is small.

I'll try to do that with linker script.  Will send the patch to discuss
further.
-- 

Re: [linuxsh-dev] [linux-sh:01255] Re: ROMable image

[Jesper S. <js...@re...>]

>>>>> "NIIBE" == NIIBE Yutaka <gn...@ch...> writes:

NIIBE> Jesper Skov wrote:
>> I have now uploaded the simple patch below to the patch manager at
>> sourceforge.

NIIBE> Interesting.  I've incorporated non-XIP part of the changes.

NIIBE> I'm not sure the word "XIP" is good or not.  If I remember
NIIBE> correctly, it doesn't mean "kernel text on ROM".  It's
NIIBE> something about execution format like ELF, a.out.

NIIBE> What's up here?

eXecute In Place - it's the usual phrase used to describe executing
from ROM. At least it's used a lot in Cygnus/Red Hat (full of embedded
developers) and I also noticed it in the PCMCIA documentation the
other day. I think XIP is the proper word to use.

Jesper

[linuxsh-dev] [linux-sh:01255] Re: ROMable image

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

Jesper Skov wrote:
 > I have now uploaded the simple patch below to the patch manager at
 > sourceforge.

Interesting.  I've incorporated non-XIP part of the changes.

I'm not sure the word "XIP" is good or not.  If I remember correctly,
it doesn't mean "kernel text on ROM".  It's something about execution
format like ELF, a.out.

What's up here?
-- 

[linuxsh-dev] linux SH3 MMU queries

[Santosh E. <sa...@so...>]

>
>Hi,
>I have a few questions on the h/w interface part of memory mgmt in Linux.
>
>If any of u can can shed some light on the questions below(prefixed with 
>a >>>>Q)
>it will be most helpful.
>If any one can give an example as to how the address translation is done 
>it will be most helpful.
>Thanks a lot
>
>Memory Map of Linux on SH3
>[ P0/U0 (virtual) ]                     0x00000000<------ User space
>[ P1 (fixed)   cached ]               0x80000000<------ Kernel space
>[ P2 (fixed)  non-cachable]       0xA0000000<------ Physical access
>[ P3 (virtual) cached]                0xC0000000<------ not used
>[ P4 control   ]                           0xE0000000
>
>SH3 provides 2MB for User space and 2 MB for kernel space
>Hence PAGE_OFFSET =0x80000000
>TASK_SIZE should be equal to PAGE_OFFSET but SH3 says we can't use
>0x7c000000--0x7fffffff ==>pg 209 SH h/w manual
>Hence TASK_SIZE= 0x7c000000UL
> >>>>>Q: Is this correct??
>
>#define PAGE_SHIFT     12
>#define PAGE_SIZE        (1UL << PAGE_SHIFT) ==>4096
>Page size =4K
>On a 32 bit machine, the Linux kernel usually resides at virtual address 
>0xc0000000 and virtual addresses from 0xc0000000 to 0xffffffff are 
>reserved for kernel text/data and I/O space.
>CONFIG_MEMORY_START 0x0c000000
>#define __MEMORY_START          CONFIG_MEMORY_START
> >>>>>Q:In the map above this address range is shown as unused??
>
>As IX bit in MMUCR is 1, TLB index is computed by ex oring ASID bits 0-4 
>in PTEH and VPN bits 16-12.
>VPN is upper 20 bits of virtual address for a 4K page
>TTB->base address of current page table
>bits 16-12 of VPN is exored with ASID and forms index into TLB. Hence 
>these are not stored in the TLB.
>This can be obtained by exoring with the ASID present in the PTEH register.
> >>>>Q:Where is this exoring done in Linux? I don’t see any mask to get 
> the VPN16-12 for indexing?
> >>>>Q:How is TLB "way" selection done in Linux?
> >>>>Q:Can a page overlap two sections eg P1 & P2?
>
>#define PAGE_OFFSET             (0x80000000)
>#define __pa(x)                 ((unsigned long)(x)-PAGE_OFFSET)
>#define __va(x)                 ((void *)((unsigned long)(x)+PAGE_OFFSET))
>#define MAP_NR(addr)            ((__pa(addr)-__MEMORY_START) >> PAGE_SHIFT)
>
>pa/va =gives the physical address/virtual address.
> >>>>Q:Whats the math behind the -/+ PAGE_OFFSET.
> >>>>Does this mean that the address in Kernel space are the same as 
> physical address.
> >>>>What about the address in P2 and P3 area?
> >>>>Q:Does MAP_NR give the total number of pages?
>
>PTRS_PER_PMD    1
>PTRS_PER_PGD    1024
>PTRS_PER_PTE    1024
>
>
>Virtual address
>31 …22 21 …12 11…0
>DIR       TABLE  OFFSET
>1024 entries1024 entries
>
>
>Physical address is then computed as:
>CR3 + DIR  points to the table_base
>table_base + TABLE  points to the page_base
>physical_address  page_base + OFFSET
>
>DIR=swapper_pg_dir[1024]; This is the kernel pg table.
>There is only one kernel page table.
>Each user program have their own page tables.
>
>The register CR3 contains the physical base address of the page directory 
>and is stored as part of the TSS in the task_struct and is therefore 
>loaded on each task switch.
> >>>>Q:what is it on SH3?
>
>#define MMU_PAGE_ASSOC_BIT      0x80
>#define MMU_CONTEXT_VERSION_MASK        0xffffff00
>#define MMU_CONTEXT_FIRST_VERSION       0x00000100
> >>>>Q:What is the purpose of MMU_PAGE_ASSOC_BIT
> >>>>Q:What is this version referred to?

Thanks

--
Santosh Eraniose
-----------------------------------------------
Member Technical
Sony Software Architecture Lab
Bangalore
-----------------------------------------------

[linuxsh-dev] Re: XIP

[Jesper S. <js...@re...>]

[please write proper English. I'm getting too old to find the
short'n'cute form cool anymore - now it's just annoying]

>>>>> "Manoj" == Manoj Kumar <man...@so...> writes:

Manoj> Hello Jesper, Thanx for ur response regarding the XIP patch for
Manoj> SH-3 on the mailing list.

Manoj> I have a few doubts.

Manoj> 1. My understanding of XIP is that the kernel image (which
Manoj> includes the text + data) sits in the ROM and executes from
Manoj> there.  Can u plz explain this scheme a bit more in detail?

That is correct. Worth noting is that there is no MMU mapping
(page-wise) of that area: we rely on the direct mapping available in
kernel space.

Manoj> 2. From ur explanation in the mail,i see that 2Megs of RAM is
Manoj> used for kernel text+initrd and 5Megs for mapping.  The kernel
Manoj> text starts at CONFIG_XIP_ROM_START=0c100000,which is a RAM
Manoj> address.  Since in the XIP scheme,the kernel sits in the
Manoj> ROM,why r u placing it in the RAM area?  I could be wrong in my

For debugging purpose. Setting breakpoints in ROM is hard :)

For a proper XIP configuration, you'd select
CONFIG_XIP_ROM_START=00100000 (which is in ROM) and
CONFIG_MEMORY_START=0x0c100000.

Build the image and program it into the ROM at that address (or
rather, at 0x00101000). Start it by jumping to 0x80102000. It will
copy the data to 0x0c100000 and start executing...

Manoj> interpretation of the entire thing.  What is the
Manoj> CONFIG_MEMORY_START for?Is it the starting address of the area
Manoj> which will be used by the Linux kernel.

CONFIG_MEMORY_START defines RAM start - as in: the area where the
paged mapping of memory begins.

Jesper

[linuxsh-dev] Re: [linux-sh:01233] Re: ROMable image

[Jesper S. <js...@re...>]

>>>>> "Jesper" == Jesper Skov <js...@re...> writes:

>>>>> "Manoj" == Manoj Kumar <man...@so...> writes:
Manoj> Hello all, I want to build a ROMable kernel image.I am using
Manoj> NIIBE's sh-linux 2.4.0.  I am not using a CE device.  Does
Manoj> anyone know about a patch for doing the same?

Manoj> I found a patch in Ludovic's site,but it is for linux2.3.23.

Jesper> I have some XIP patches. I need to clean them up and submit
Jesper> them. Hopefully today, but I need to check that they are OK to
Jesper> publicize - so no guarantees.

I have now uploaded the simple patch below to the patch manager at
sourceforge.

The only real problem with the patch as far as I'm concerned is that
it uses a hack to separate arguments from the empty_zero_page. I had
to do this because (a) I'm using some scripts to write boot parameters
into the start of the boot image and (b) empty_zero_page has to be in
the data section so it will end up in RAM.

I don't know if the patch is worth integrating the public tree before
that issue has been fixed. But even so, there are a few generic fixes
in there as well: Documentation fix + lose module exit functions.

For debugging with the XIP configuration, I configure something like
this (I have 8MB RAM @ 0x0c000000):

 CONFIG_SH_XIP=y
 CONFIG_XIP_ROM_START=0C100000
 CONFIG_MEMORY_START=0C300000
 CONFIG_MEMORY_SIZE=00500000

Thus leaving 2MB @ 0x0c100000 for the boot image (kernel text +
initrd). On startup the data section is copied to MEMORY_START and the
5MB @ 0x0c300000 is mapped as if it was the only RAM in the
system. Then I'm free to still use breakpoints/single-step the kernel
text.

For production I put CONFIG_XIP_ROM_START=00100000, and have the full
8MB of RAM for the system. (the 1MB missing are for the boot monitor).


Cheers,
Jesper


	2000-08-25  Jesper Skov  <js...@re...>

	* arch/sh/Makefile: Select linker script based on XIP config.
	* arch/sh/config.in: Added XIP related and memory default size
	options.
	* arch/sh/vmlinux.lds.S: Added _sdata label. Discard .exitcalls
	from modules.
	* arch/sh/vmlinux.lds.xip.S: [Added] Linker script for XIP
	configuration.
	* arch/sh/kernel/head.S: Copy data to RAM in XIP config. Crufty
	hack to keep arguments at front of image while empty_zero_page ends
	up in RAM.
	* arch/sh/kernel/setup.c (parse_cmdline): Use configurable default
	memory size. empty_zero_page/argument_page XIP hack.
	* arch/sh/mm/init.c (mem_init): Use _sdata instead of _etext for
	size calculation.
	* Documentation/Configure.help: Added descriptions for new
	options. Fixed CPU selection description.
	



Index: Documentation/Configure.help
===================================================================
RCS file: /cvsroot/linuxsh/kernel/Documentation/Configure.help,v
retrieving revision 1.21
diff -u -5 -r1.21 Configure.help
--- Documentation/Configure.help	2000/08/10 01:19:39	1.21
+++ Documentation/Configure.help	2000/08/25 08:48:00
@@ -14818,14 +14818,15 @@
 
 # The following options are for Linux when running on the Hitachi
 # SuperH family of RISC microprocessors.
 
 CPU Selection
-CONFIG_CPU_SUBTYPE_SH7708
+CONFIG_CPU_SUBTYPE_SH7707
   This is the type of your Hitachi SuperH processor. This information is
   used for optimizing and configuration purposes.
 
+  - "SH7707" for SH7707
   - "SH7708" for SH7708, SH7708S, SH7708R
   - "SH7709" for SH7707, SH7709, SH7709A, and SH7729.
   - "SH7750" for SH7750, and possibly SH7751
 
 Physical memory start address
@@ -14837,10 +14838,40 @@
 
   You should set this value to the address of the lowest
   RAM location.
 
   A value of 0c000000 will work for most boards.
+
+Execute-in-place kernel
+CONFIG_SH_XIP
+  Selecting this option (eXecute-In-Place) will allow the kernel text
+  and rodata segments to remain in flash/ROM memory, saving on RAM usage.
+
+  There might be a small performance degradation due to the flash/ROM
+  being slower than DRAM, but since the kernel only uses a fraction of
+  the total CPU time, this should not be a problem. The RAM freed up
+  by running the kernel out of flash/ROM will probably more than
+  counter this slowdown.
+
+XIP text segment start address
+CONFIG_XIP_ROM_START
+  When the XIP option is selected, this option controls where the
+  kernel text segment starts. SuperH processors always have flash/ROM
+  at address zero, but there may be reasons to put the kernel
+  elsewhere:
+
+  Higher up in the flash/ROM, leaving the start of the flash/ROM to a
+  boot monitor which can start Linux.
+
+  In RAM, allowing for debugging. In this case you should adjust the
+  CONFIG_MEMORY_START option as well, leaving a gap for the kernel in
+  RAM.
+
+Memory size
+CONFIG_MEMORY_SIZE
+  The amount of RAM used by Linux can be controlled with a kernel
+  parameter, but this option allows for a configurable default.
 
 Directly Connected Compact Flash support
 CONFIG_CF_ENABLER
   If your board has "Directly Connected" Compact Flash at area 6, 
   you may want to enable this option.  Then, you can use CF as
Index: arch/sh/Makefile
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/Makefile,v
retrieving revision 1.9
diff -u -5 -r1.9 Makefile
--- arch/sh/Makefile	2000/07/31 12:35:55	1.9
+++ arch/sh/Makefile	2000/08/25 08:48:01
@@ -80,14 +80,20 @@
 SUBDIRS += arch/sh/overdrive
 CORE_FILES += arch/sh/overdrive/overdrive.o
 endif
 endif
 
+ifdef CONFIG_SH_XIP
+LINKSCRIPT_SRC = arch/sh/vmlinux.lds.xip.S
+else
+LINKSCRIPT_SRC = arch/sh/vmlinux.lds.S
+endif
+
 vmlinux: arch/sh/vmlinux.lds
 
-arch/sh/vmlinux.lds: arch/sh/vmlinux.lds.S FORCE
-	$(CPP) -C -P -I$(HPATH) -Ush arch/sh/vmlinux.lds.S >arch/sh/vmlinux.lds
+arch/sh/vmlinux.lds: $(LINKSCRIPT_SRC) FORCE
+	$(CPP) -C -P -I$(HPATH) -Ush $(LINKSCRIPT_SRC) >arch/sh/vmlinux.lds
 
 FORCE: ;
 
 zImage: vmlinux
 	@$(MAKEBOOT) zImage
Index: arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/config.in,v
retrieving revision 1.19
diff -u -5 -r1.19 config.in
--- arch/sh/config.in	2000/08/05 07:04:45	1.19
+++ arch/sh/config.in	2000/08/25 08:48:02
@@ -52,16 +52,21 @@
 if [ "$CONFIG_CPU_SUBTYPE_SH7750" = "y" ]; then
    define_bool CONFIG_CPU_SH3 n
    define_bool CONFIG_CPU_SH4 y
 fi
 bool 'Little Endian' CONFIG_CPU_LITTLE_ENDIAN
+bool 'Kernel XIP' CONFIG_SH_XIP
+if [ "$CONFIG_SH_XIP" = "y" ]; then
+    hex 'ROM physical start address' CONFIG_XIP_ROM_START 08100000
+fi
 if [ "$CONFIG_SH_SOLUTION_ENGINE" = "y" -o "$CONFIG_SH_HP600" = "y" -o \
      "$CONFIG_SH_OVERDRIVE" = "y" ]; then
   define_hex CONFIG_MEMORY_START 0c000000
 else
   hex 'Physical memory start address' CONFIG_MEMORY_START 08000000
 fi
+hex 'Memory size' CONFIG_MEMORY_SIZE 00400000
 endmenu
 
 mainmenu_option next_comment
 comment 'General setup'
 
Index: arch/sh/vmlinux.lds.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/vmlinux.lds.S,v
retrieving revision 1.6
diff -u -5 -r1.6 vmlinux.lds.S
--- arch/sh/vmlinux.lds.S	2000/08/05 06:25:22	1.6
+++ arch/sh/vmlinux.lds.S	2000/08/25 08:48:02
@@ -35,10 +35,11 @@
   __start___ksymtab = .;	/* Kernel symbol table */
   __ksymtab : { *(__ksymtab) }
   __stop___ksymtab = .;
 
   _etext = .;			/* End of text section */
+  _sdata = .;			/* Start of data section */
 
   .data : {			/* Data */
 	*(.data)
 	CONSTRUCTORS
 	}
@@ -87,10 +88,11 @@
    * it's a module.
    */
   /DISCARD/ : {
 	*(.text.exit)
 	*(.data.exit)
+	*(.exitcall.*)
 	}
 
   /* Stabs debugging sections.  */
   .stab 0 : { *(.stab) }
   .stabstr 0 : { *(.stabstr) }
Index: arch/sh/vmlinux.lds.xip.S
===================================================================
RCS file: vmlinux.lds.xip.S
diff -N vmlinux.lds.xip.S
--- arch/sh/vmlinux.lds.xip.S	Tue May  5 13:32:27 1998
+++ arch/sh/vmlinux.lds.xip.S	Fri Aug 25 01:48:03 2000
@@ -0,0 +1,155 @@
+/* $Id: vmlinux.lds.xip.S,v 1.3 2000/08/21 14:12:02 jskov Exp $
+ * ld script to make SuperH Linux kernel
+ * Written by Niibe Yutaka
+ */
+
+#include <linux/config.h>
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+OUTPUT_FORMAT("elf32-shl", "elf32-shl", "elf32-shl")
+#else
+OUTPUT_FORMAT("elf32-sh", "elf32-sh", "elf32-sh")
+#endif
+OUTPUT_ARCH(sh)
+ENTRY(_start)
+
+#define ALIGN_LMA 4
+#define ALIGNED_GAP(_section_, _align_) (((ADDR(_section_)+SIZEOF(_section_)+(_align_)-1) & ~((_align_)-1))-ADDR(_section_))
+#define FOLLOWING(_section_, _align_) AT (LOADADDR (_section_) + ALIGNED_GAP(_section_, _align_))
+
+SECTIONS
+{
+  . = 0x80000000 + CONFIG_XIP_ROM_START + 0x1000;
+  _text = .;			/* Text and read-only data */
+  text = .;			/* Text and read-only data */
+  .argument_page : {
+	*(.argument_page)
+	} = 0
+  .text : {
+	*(.text)
+	*(.fixup)
+	*(.gnu.warning)
+	*(.text.init)
+	} = 0x0009
+  .text.lock : { *(.text.lock) }	/* out-of-line lock text */
+  .rodata : { *(.rodata) }
+  .kstrtab : { *(.kstrtab) }
+
+  . = ALIGN(16);		/* Exception table */
+  __start___ex_table = .;
+  __ex_table : { *(__ex_table) }
+  __stop___ex_table = .;
+
+  __start___ksymtab = .;	/* Kernel symbol table */
+  __ksymtab : { *(__ksymtab) }
+  __stop___ksymtab = .;
+
+  _etext = .;			/* End of text section */
+
+  _xip_load = .;		/* Load address of data for RAM */
+  . = 0x80000000 + CONFIG_MEMORY_START;
+  _xip_sdata = .;		/* Start of data section */
+  _sdata = .;			/* Start of data section */
+  .empty_zero_page : FOLLOWING(__ksymtab, 1) {
+	*(.empty_zero_page)
+	} = 0
+  . = ALIGN(4096);
+  .data : FOLLOWING(.empty_zero_page, 4096) {/* Data */
+	*(.data)
+#if 0
+	CONSTRUCTORS
+#endif
+	}
+
+  _edata = .;			/* End of data section */
+
+  . = ALIGN(8192);		/* init_task */
+  .data.init_task : FOLLOWING(.data, 8192) { *(.data.init_task) }
+  /* stack */
+  .stack : { stack = .;  _stack = .; }
+
+  . = ALIGN(4096);		/* Init code and data */
+  __init_begin = .;
+  .data.init : FOLLOWING(.data.init_task, 4096) { *(.data.init) }
+  . = ALIGN(16);
+  __setup_start = .;
+  .setup.init : FOLLOWING(.data.init, 16) { *(.setup.init) }
+  __setup_end = .;
+  __initcall_start = .;
+  .initcall.init : FOLLOWING(.setup.init, 1) { *(.initcall.init) }
+  __initcall_end = .;
+  __machvec_start = .;
+  .machvec.init : FOLLOWING(.initcall.init, 1) { *(.machvec.init) }
+  __machvec_end = .;
+  . = ALIGN(4096);
+  __init_end = .;
+
+#if 0
+  . = ALIGN(4096);
+  .data.page_aligned : FOLLOWING(.setup.init, 4096) { *(.data.idt) }
+#endif
+
+#if 0
+  . = ALIGN(32);
+  .data.cacheline_aligned : FOLLOWING(.data.page_aligned, 32) { *(.data.cacheline_aligned) }
+#else
+  . = ALIGN(4096);
+  .data.cacheline_aligned : FOLLOWING(.initcall.init, 4096) { *(.data.cacheline_aligned) }
+#endif
+
+  . = ALIGN(4);
+
+  _xip_edata = .;		/* End of data that needs to be copied */
+
+  __bss_start = .;		/* BSS */
+  .bss : {
+	*(.bss)
+	}
+  . = ALIGN(4);
+  _end = . ;
+
+  /* When something in the kernel is NOT compiled as a module, the
+   * module cleanup code and data are put into these segments.  Both
+   * can then be thrown away, as cleanup code is never called unless
+   * it's a module.
+   */
+  /DISCARD/ : {
+	*(.text.exit)
+	*(.data.exit)
+	*(.exitcall.*)
+	}
+
+  /* Stabs debugging sections.  */
+  .stab 0 : { *(.stab) }
+  .stabstr 0 : { *(.stabstr) }
+  .stab.excl 0 : { *(.stab.excl) }
+  .stab.exclstr 0 : { *(.stab.exclstr) }
+  .stab.index 0 : { *(.stab.index) }
+  .stab.indexstr 0 : { *(.stab.indexstr) }
+  .comment 0 : { *(.comment) }
+  /* DWARF debug sections.
+     Symbols in the DWARF debugging section are relative to the beginning
+     of the section so we begin .debug at 0.  */
+  /* DWARF 1 */
+  .debug          0 : { *(.debug) }
+  .line           0 : { *(.line) }
+  /* GNU DWARF 1 extensions */
+  .debug_srcinfo  0 : { *(.debug_srcinfo) }
+  .debug_sfnames  0 : { *(.debug_sfnames) }
+  /* DWARF 1.1 and DWARF 2 */
+  .debug_aranges  0 : { *(.debug_aranges) }
+  .debug_pubnames 0 : { *(.debug_pubnames) }
+  /* DWARF 2 */
+  .debug_info     0 : { *(.debug_info) }
+  .debug_abbrev   0 : { *(.debug_abbrev) }
+  .debug_line     0 : { *(.debug_line) }
+  .debug_frame    0 : { *(.debug_frame) }
+  .debug_str      0 : { *(.debug_str) }
+  .debug_loc      0 : { *(.debug_loc) }
+  .debug_macinfo  0 : { *(.debug_macinfo) }
+  /* SGI/MIPS DWARF 2 extensions */
+  .debug_weaknames 0 : { *(.debug_weaknames) }
+  .debug_funcnames 0 : { *(.debug_funcnames) }
+  .debug_typenames 0 : { *(.debug_typenames) }
+  .debug_varnames  0 : { *(.debug_varnames) }
+  /* These must appear regardless of  .  */
+}
Index: arch/sh/kernel/head.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/head.S,v
retrieving revision 1.7
diff -u -5 -r1.7 head.S
--- arch/sh/kernel/head.S	2000/07/04 06:24:39	1.7
+++ arch/sh/kernel/head.S	2000/08/25 08:48:03
@@ -10,12 +10,21 @@
  *
  * Head.S contains the SH exception handlers and startup code.
  */
 #include <linux/linkage.h>
 
+#ifdef CONFIG_SH_XIP
 	.section	.empty_zero_page, "aw"
 ENTRY(empty_zero_page)
+	.long	0
+
+	.section	.argument_page, "aw"
+ENTRY(argument_page)
+#else
+	.section	.empty_zero_page, "aw"
+ENTRY(empty_zero_page)
+#endif
 	.long	1		/* MOUNT_ROOT_RDONLY */
 	.long	0		/* RAMDISK_FLAGS */
 	.long	0x0200		/* ORIG_ROOT_DEV */
 	.long	1		/* LOADER_TYPE */
 	.long	0x00360000	/* INITRD_START */
@@ -58,10 +67,21 @@
 #endif
 	!			Enable cache
 	mov.l	6f, $r0
 	jsr	@$r0
 	 nop
+#ifdef CONFIG_SH_XIP
+	!			Copy data to RAM
+        mov.l   10f,$r0
+        mov.l   11f,$r1
+        mov.l   12f,$r2
+9:      mov.l   @$r0+,$r3               ! get word from ROM
+        mov.l   $r3,@$r1                ! store in RAM
+        add     #4,$r1
+        cmp/eq  $r1,$r2                 ! compare
+        bf      9b                      ! loop if not yet done
+#endif
 	!			Clear BSS area
 	mov.l	3f, $r1
 	add	#4, $r1
 	mov.l	4f, $r2
 	mov	#0, $r0
@@ -80,6 +100,11 @@
 4:	.long	SYMBOL_NAME(_end)
 5:	.long	SYMBOL_NAME(start_kernel)
 6:	.long	SYMBOL_NAME(cache_init)
 #if defined(__SH4__)
 7:	.long   SYMBOL_NAME(fpu_init)
+#endif
+#ifdef CONFIG_SH_XIP
+10:	.long	SYMBOL_NAME(_xip_load)
+11:	.long	SYMBOL_NAME(_xip_sdata)
+12:	.long	SYMBOL_NAME(_xip_edata)
 #endif
Index: arch/sh/kernel/setup.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/setup.c,v
retrieving revision 1.11
diff -u -5 -r1.11 setup.c
--- arch/sh/kernel/setup.c	2000/08/05 06:25:23	1.11
+++ arch/sh/kernel/setup.c	2000/08/25 08:48:04
@@ -69,11 +69,16 @@
 static struct sh_machine_vector* __init get_mv_byname(const char* name);
 
 /*
  * This is set up by the setup-routine at boot-time
  */
+#ifndef CONFIG_SH_XIP
 #define PARAM	((unsigned char *)empty_zero_page)
+#else
+extern unsigned char argument_page;
+#define PARAM	((unsigned char *)&argument_page)
+#endif
 
 #define MOUNT_ROOT_RDONLY (*(unsigned long *) (PARAM+0x000))
 #define RAMDISK_FLAGS (*(unsigned long *) (PARAM+0x004))
 #define ORIG_ROOT_DEV (*(unsigned long *) (PARAM+0x008))
 #define LOADER_TYPE (*(unsigned long *) (PARAM+0x00c))
@@ -202,12 +207,12 @@
 	/* Save unparsed command line copy for /proc/cmdline */
 	memcpy(saved_command_line, COMMAND_LINE, COMMAND_LINE_SIZE);
 	saved_command_line[COMMAND_LINE_SIZE-1] = '\0';
 
 	memory_start = (unsigned long)PAGE_OFFSET+__MEMORY_START;
-	/* Default is 4Mbyte. */
-	memory_end = (unsigned long)PAGE_OFFSET+0x00400000+__MEMORY_START;
+	/* Default is specified by the configuration */
+	memory_end = (unsigned long)PAGE_OFFSET+CONFIG_MEMORY_SIZE+__MEMORY_START;
 
 	for (;;) {
 		/*
 		 * "mem=XXX[kKmM]" defines a size of memory.
 		 */
Index: arch/sh/mm/init.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/init.c,v
retrieving revision 1.6
diff -u -5 -r1.6 init.c
--- arch/sh/mm/init.c	2000/08/16 08:34:04	1.6
+++ arch/sh/mm/init.c	2000/08/25 08:48:04
@@ -176,11 +176,11 @@
 	show_buffers();
 }
 
 /* References to section boundaries */
 
-extern char _text, _etext, _edata, __bss_start, _end;
+extern char _text, _etext, _sdata, _edata, __bss_start, _end;
 extern char __init_begin, __init_end;
 
 pgd_t swapper_pg_dir[1024];
 
 /* It'd be good if these lines were in the standard header file. */
@@ -251,11 +251,11 @@
 		 * Only count reserved RAM pages
 		 */
 		if (PageReserved(mem_map+tmp))
 			reservedpages++;
 	codesize =  (unsigned long) &_etext - (unsigned long) &_text;
-	datasize =  (unsigned long) &_edata - (unsigned long) &_etext;
+	datasize =  (unsigned long) &_edata - (unsigned long) &_sdata;
 	initsize =  (unsigned long) &__init_end - (unsigned long) &__init_begin;
 
 	printk("Memory: %luk/%luk available (%dk kernel code, %dk reserved, %dk data, %dk init)\n",
 		(unsigned long) nr_free_pages() << (PAGE_SHIFT-10),
 		max_mapnr << (PAGE_SHIFT-10),

[linuxsh-dev] sh-sci 57600 support

[Bryan R. <br...@ix...>]

Hi guys,

I patched in kernel support for 57600 bps, if any of you are interested.
Since it is what we are using internally it would be great to get this
into the main tree. IMO this should have been in sh-sci.[c|h] in the
first place. Here's the diff:

-----

--- kernel.virgin/drivers/char/sh-sci.c Thu Aug 24 13:16:05 2000
+++ kernel/drivers/char/sh-sci.c        Thu Aug 24 13:17:39 2000
@@ -329,6 +329,9 @@
        case 38400:
                t = BPS_38400;
                break;
+       case 57600:
+               t = BPS_57600;
+               break;
        default:
                printk(KERN_INFO "sci: unsupported baud rate: %d, using
115200 instead.\n", baud);
        case 115200:

--- kernel.virgin/drivers/char/sh-sci.h Thu Aug 24 13:16:05 2000
+++ kernel/drivers/char/sh-sci.h        Thu Aug 24 13:17:10 2000
@@ -289,5 +289,6 @@
 #define BPS_9600       SCBRR_VALUE(9600)
 #define BPS_19200      SCBRR_VALUE(19200)
 #define BPS_38400      SCBRR_VALUE(38400)
+#define BPS_57600      SCBRR_VALUE(57600)
 #define BPS_115200     SCBRR_VALUE(115200)

-----

I don't really deserve CVS write access for this ;-), but it would be
great if somebody else chose to import it.

Regards,

Bryan Rittmeyer
mailto:br...@ix...

Re: [linuxsh-dev] mmu problems?

[Bryan R. <br...@ix...>]

Greg Banks wrote:

> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00001c24  a0000000  a0000000  00001000  2**12
>                             ^
>                           a not 0

I had this section located at the right spot (a0000000). However,

>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .data         00000001  ac000000  ac000000  00003000  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .bss          000008a4  ac000004  ac000004  00003004  2**2
>                   ALLOC
>   3 .stack        00000600  ac000a00  ac000a00  00003a00  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   4 .stab         0000258c  ac000004  ac000004  00004000  2**2
>                   CONTENTS, READONLY, DEBUGGING
>   5 .comment      00000072  ac002590  ac002590  0000658c  2**0
>                   CONTENTS, READONLY
>   6 .stabstr      00000c65  ac002602  ac002602  000065fe  2**0
>                   CONTENTS, READONLY, DEBUGGING

All of these were linked at variations of 08000000. I have changed
the leading 0 to an a and will try again.

> 2.  Your kernel configuration variable CONFIG_GDB_STUB_VBR has
>     the top nibble set to `a', e.g. `a0000000'.

This variable was set correctly.

Thanks,

Bryan Rittmeyer
mailto:br...@ix...

AW: AW: [linuxsh-dev] printf

[Studencki (e. P. <Paw...@er...>]

> >Assuming he was using 38400 with a 25 MHz clock (my 
> assumptions, since
> >he mentioned t=19 fixed the problems) my correction 
> generates the proper
> >result, whereas the define in sourceforge CVS's sh-sci.h does not (it
> >generates 20) It's slight, and RS-232C is pretty tolerant (+-2% is
> >guaranteed safe, but usually up to 5-10% still works), but I believe
> >sh-sci.h is incorrect.
> >
> 
> in my environment, both generates correct value 19 in this case.

Hi,

it's my fault :) I'm using kernel 2.3.99-test7 (you are talking about newest
snapshot from CVS...)
"PCLK" in file drivers/char/sh-sci.h is differently defined as in kernel
2.4.0-test5:
#define  PCLK(current_cpu_data.module_clock)

So the problem is not with the formula but with value for PCLK.

My kernel 2.4.0 doesn't work, so I can't say, it's corect for my platform
(SH3) or not. I hope it will be working.

regards
Pawel

[linuxsh-dev] Hello1

[Greg B. <gb...@po...>]

G'day

I've received a couple of off-list requests for the source of the trivial
usermode program Mitch & I used to help bootstrap the kernel on our board.
You can get it at

ftp://linuxsh.sourceforge.net/pub/linuxsh/hello1-20000824.tar.gz

Greg.
-- 
These are my opinions not PPIs.

Re: [linuxsh-dev] mmu problems?

[Greg B. <gb...@po...>]

Bryan Rittmeyer wrote:
> 
> Hello linuxsh-dev,
> 
> I have been working with the latest CVS kernel sources, putting in
> printk statements as reach points trying to figure out why the only
> thing I am getting in GDB is the kernel banner. It looks like the
> problem lies in setup_arch, called right after printk(linux_banner).
> That routine executes fine, until  it calls paging_init (at the last
> line of setup_arch). As soon as the MMU is brought up, printk stops
> working:
> 
> [from arch/sh/mm/init.c:paging_init]
> 
>         printk("paging here 1\n");
> 
>         /* Enable MMU */
>         ctrl_outl(MMU_CONTROL_INIT, MMUCR);
> 
>         /* The manual suggests doing some nops after turning on the MMU
> */
>         asm volatile("nop;nop;nop;nop;nop;nop;");
> 
>         printk("paging here 2\n");
> 
> All I get with GDB is "paging here 1" and then nothing else. As I
> mentioned before if I exit GDB and go into a terminal program, the
> sh-ipl menu is back up as if GDB mode exited (suggesting the kernel
> died/returned). Of course I have no way of knowing how much of the
> kernel executed since printk stops working. I am not passing a console
> parameter to the kernel.
> 
> Is it normal for LinuxSH BIOS-based printk to break after bringing up
> the MMU? 

  No, this is a configuration bug.  Mitch & I struggled with exactly
this problem some weeks ago.  What is wrong is that the gdb stub's
exception handling table, to which the kernel delegates BIOS calls,
is located at an address which has the top nibble 0x0.  This works
fine until the kernel enables paging because the address is not
translated; after that there is no mapping for the address and an
attempt to call the BIOS will double-fault.

  You need to check two things.

1.  Your gdb stub is linked at the right address.  The easiest way is
    to use the `sh-linux-gnu-objdump --headers' command on the .exe
    produced when you built the stub.  You should see numbers like this:

gnb@felix 1031> sh-linux-gnu-objdump --headers sh-stub.exe 

sh-stub.exe:     file format elf32-shl

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00001c24  a0000000  a0000000  00001000  2**12
                            ^
                          a not 0

                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000001  ac000000  ac000000  00003000  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          000008a4  ac000004  ac000004  00003004  2**2
                  ALLOC
  3 .stack        00000600  ac000a00  ac000a00  00003a00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .stab         0000258c  ac000004  ac000004  00004000  2**2
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000072  ac002590  ac002590  0000658c  2**0
                  CONTENTS, READONLY
  6 .stabstr      00000c65  ac002602  ac002602  000065fe  2**0
                  CONTENTS, READONLY, DEBUGGING

2.  Your kernel configuration variable CONFIG_GDB_STUB_VBR has
    the top nibble set to `a', e.g. `a0000000'.

    BTW this variable will go away in the next few days when I
    get around to checking in my auto-vbr patch.

> If so, how do I fix it--I would like all console output to go
> into GDB. And if I am having MMU problems, could that be the result of
> incorrect sh-ipl init_bsc code?

  Probably not.  At least, these particular symptoms don't indicate it.


Greg.
-- 
These are my opinions not PPIs.

Re: AW: [linuxsh-dev] printf

[<su...@it...>]

At 16:52 00/08/23 -0700, Bryan Rittmeyer wrote:
>
>Maybe I'm crazy, but I think there is a problem in sh-sci.h:
>
>#define SCBRR_VALUE(bps) ((PCLK+16*bps)/(32*bps)-1)
>
>Looks like most of the active people on this list (all of which know
>more than I do) had their hands in sh-sci.h at some point, but
>nonetheless I suspect this is more correct:
>
>#define SCBRR_VALUE(bps) ((PCLK)/(32*bps)-1)
>
>I am not sure where that +16*bps term came from, but I have not used it
>for my calculations and it seems to just introduce a slight error (When
>PCLK is something like 50000000, 16*bps introduces about a 2% addition
>at 57600) At lower clock frequencies and high baud rates, this factor
>becomes more important... but if I recall correctly it is NOT listed in
>the SH4 data sheet. So what's going on with SCBRR_VALUE?
>

I think +16*bps means 'round to nearest value'.
usually on integer division, result is rounded toward 0.
adding half of divider before division, changes this behavior.
So I think sh-sci.h is correct.

>Hitachi SH4 datasheet h14th003d5.pdf (the Hardware Manual) lists this on
>page 534:
>
>N = [PCLK / (64 * 2^((2*n)-1) * bps)]-1
>
>n=0 for our case, so that is clearly N = [PCLK / (32 * bps)] - 1
>
>Assuming he was using 38400 with a 25 MHz clock (my assumptions, since
>he mentioned t=19 fixed the problems) my correction generates the proper
>result, whereas the define in sourceforge CVS's sh-sci.h does not (it
>generates 20) It's slight, and RS-232C is pretty tolerant (+-2% is
>guaranteed safe, but usually up to 5-10% still works), but I believe
>sh-sci.h is incorrect.
>

in my environment, both generates correct value 19 in this case.

Regards,

----
Sugioka Toshinobu

Re: AW: [linuxsh-dev] printf

[Bryan R. <br...@ix...>]

"Studencki (external) Pawel" wrote:

> ========================================================
> Greg, I've put put some printks to debug function sci_set_baud and
> SCSMR = 0
> t = 26
> 
> I'm not sure, are these settings correct for my platform. According to
> hardware manual, I have to know "operating frequency for periphelar devices"
> to set SCBRR correct. Is this value showed at booting of kernel?

Maybe I'm crazy, but I think there is a problem in sh-sci.h:

#define SCBRR_VALUE(bps) ((PCLK+16*bps)/(32*bps)-1)

Looks like most of the active people on this list (all of which know
more than I do) had their hands in sh-sci.h at some point, but
nonetheless I suspect this is more correct:

#define SCBRR_VALUE(bps) ((PCLK)/(32*bps)-1)

I am not sure where that +16*bps term came from, but I have not used it
for my calculations and it seems to just introduce a slight error (When
PCLK is something like 50000000, 16*bps introduces about a 2% addition
at 57600) At lower clock frequencies and high baud rates, this factor
becomes more important... but if I recall correctly it is NOT listed in
the SH4 data sheet. So what's going on with SCBRR_VALUE?

Hitachi SH4 datasheet h14th003d5.pdf (the Hardware Manual) lists this on
page 534:

N = [PCLK / (64 * 2^((2*n)-1) * bps)]-1

n=0 for our case, so that is clearly N = [PCLK / (32 * bps)] - 1

Assuming he was using 38400 with a 25 MHz clock (my assumptions, since
he mentioned t=19 fixed the problems) my correction generates the proper
result, whereas the define in sourceforge CVS's sh-sci.h does not (it
generates 20) It's slight, and RS-232C is pretty tolerant (+-2% is
guaranteed safe, but usually up to 5-10% still works), but I believe
sh-sci.h is incorrect.

Comments?

Regards,

Bryan Rittmeyer
mailto:br...@ix...

[linuxsh-dev] mmu problems?

[Bryan R. <br...@ix...>]

Hello linuxsh-dev,

I have been working with the latest CVS kernel sources, putting in
printk statements as reach points trying to figure out why the only
thing I am getting in GDB is the kernel banner. It looks like the
problem lies in setup_arch, called right after printk(linux_banner).
That routine executes fine, until  it calls paging_init (at the last
line of setup_arch). As soon as the MMU is brought up, printk stops
working:

[from arch/sh/mm/init.c:paging_init]

        printk("paging here 1\n");

        /* Enable MMU */
        ctrl_outl(MMU_CONTROL_INIT, MMUCR);

        /* The manual suggests doing some nops after turning on the MMU
*/
        asm volatile("nop;nop;nop;nop;nop;nop;");
        
        printk("paging here 2\n");

All I get with GDB is "paging here 1" and then nothing else. As I
mentioned before if I exit GDB and go into a terminal program, the
sh-ipl menu is back up as if GDB mode exited (suggesting the kernel
died/returned). Of course I have no way of knowing how much of the
kernel executed since printk stops working. I am not passing a console
parameter to the kernel.

Is it normal for LinuxSH BIOS-based printk to break after bringing up
the MMU? If so, how do I fix it--I would like all console output to go
into GDB. And if I am having MMU problems, could that be the result of
incorrect sh-ipl init_bsc code?

Thanks,

Bryan Rittmeyer
mailto:br...@ix...
[slowing getting this SH4 board running Linux]

Re: [linuxsh-dev] kernel bootstrapping

[Bryan R. <br...@ix...>]

Stuart Menefy wrote:

> Bryan
> 
> I see similar things when the initrd image is loaded outside the memory
> space the kernel knows about. For example, I normally have 32M RAM from
> 0c00,0000 to 0cff,ffff, and load the initrd image at 0d00,0000.

I assume you mean 32M from 0c000000 to 0dffffff... OK.

> However if I lie, and tell the kernel I only have 16M, then the initrd
> image is outside the memory the kernel knows about, and so as it reserves
> the pages the initrd image occupies, I see the error message:
>   hm, page 01000000 reserved twice.
> for every page in the image (remember the address is an offset from
> CONFIG_MEMORY_START).

Hrm. Should I be specifying the initrd position as an offset from
CONFIG_MEMORY_START, or is it absolute as suggested by the sample
.gdbinits
in the CVS kernel source? And for the size argument, do I specify the
actual
length of the compressed image (~1k), the size of the decompressed image
(~64k), 
or the ramdisk size I'd like (~2MB)?

> If you're not deliberatly loading an initrd image, perhaps the parameters
> the kernel is seeing for where one should be are not being initialised?
> These are poked in by the .dbginit script, at offsets 0x1010 (base addr)
> and 0x1014 (size).

I have set both of these to zero now, and no longer get errors. Right
on.

A question though, how much output should I see when booting a kernel
with no
root device (IE telling it IDE when there is no IDE hardware, or telling
it
a ramdisk with 0 size in 0x1014). All I get now is this the banner:

Linux version 2.4.0-test7 (bryan@mtdew) (gcc version 2.95.2 19991024
(release)) #1 Wed Aug 23 12:00:22 PDT 2000

And then GDB just blocks... if I exit GDB and load up a terminal
program, the sh-ipl stub is back
at the menu system--indicating the kernel has exited! (returned) This is
with early printk and GDB debugging enabled, loading the kernel in with
sh-ipl/GDB. Right now the only kernel command line I
am passing is "mem=15M" (I have 16M physical SDRAM, but need to use a
small chunk of it for the gdb stub; so I load the kernel at 0x08002000
and give it to 08F02000, 15MB).

I know there is no root device, but still, wouldn't you expect more
output? No news is good news, but I want full debugging information in
GDB, if only to show my superiors more than a one line kernel banner.
:-)

Thanks for the reply,

Bryan Rittmeyer
mailto:br...@ix...

Re: [linuxsh-dev] bootmem.c/newlib

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

Bryan

I see similar things when the initrd image is loaded outside the memory
space the kernel knows about. For example, I normally have 32M RAM from
0c00,0000 to 0cff,ffff, and load the initrd image at 0d00,0000.

However if I lie, and tell the kernel I only have 16M, then the initrd
image is outside the memory the kernel knows about, and so as it reserves
the pages the initrd image occupies, I see the error message:
  hm, page 01000000 reserved twice.
for every page in the image (remember the address is an offset from
CONFIG_MEMORY_START).

If you're not deliberatly loading an initrd image, perhaps the parameters
the kernel is seeing for where one should be are not being initialised?
These are poked in by the .dbginit script, at offsets 0x1010 (base addr)
and 0x1014 (size).

Stuart

On Aug 22,  4:51pm, br...@ix... wrote:
> Subject: [linuxsh-dev] bootmem.c/newlib
> 
> Hello again linuxsh-dev,
> 
> I am now having some trouble getting the latest CVS kernel to boot. It
> gets past the Linux banner and then generates hundreds of lines of
> paging errors. Here is the GDB output:
> 
> bryan@mtdew:~/cvs/sh/kernel$ sh-linux-gnu-gdb
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "--host=i686-pc-linux-gnu
> --target=sh-linux-gnu".
> 0xa00018c6 in ?? ()
> Loading section .empty_zero_page, size 0x1c lma 0xa8003000
> Loading section .text, size 0x63ac8 lma 0xa8004000
> Loading section .rodata, size 0xdd23 lma 0xa8067ac8
> Loading section __ex_table, size 0x1208 lma 0xa80757f0
> Loading section .data, size 0x6ab8 lma 0xa80769f8
> Loading section .exitcall.exit, size 0x14 lma 0xa807d4b0
> Loading section .data.init_task, size 0x2000 lma 0xa807e000
> Loading section .text.init, size 0x5878 lma 0xa8080000
> Loading section .data.init, size 0x2db lma 0xa8085878
> Loading section .setup.init, size 0x88 lma 0xa8085b60
> Loading section .initcall.init, size 0x34 lma 0xa8085be8
> Loading section .machvec.init, size 0x2f8 lma 0xa8085c1c
> Loading section .data.cacheline_aligned, size 0xac0 lma 0xa8086000
> Start address 0xa8004000 , load size 532130
> Transfer rate: 29157 bits/sec.
> (gdb) cont
> Continuing.
> Linux version 2.4.0-test6 (bryan@mtdew) (gcc version 2.95.2 19991024
> (release)) #2 Tue Aug 22 16:38:28 PDT 2000
> kernel BUG at bootmem.c:83!
> hm, page 00f00000 reserved twice.
> hm, page 00f01000 reserved twice.
> hm, page 00f02000 reserved twice.
> hm, page 00f03000 reserved twice.
> hm, page 00f04000 reserved twice.
> hm, page 00f05000 reserved twice.
>  .
> .
>  .
> 
> And so on indefinitely through every page in the memory space. I get the
> same results with Linux-2.4.0-test6 and the CVS kernel. Anyone seen this
> before or know what may cause it?
> 
> Thanks,
> 
> Bryan Rittmeyer
> mailto:br...@ix...
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
>-- End of excerpt from br...@ix...

re: [linuxsh-dev] printf

[Studencki (e. P. <Paw...@er...>]

>   Can you please do this for me?

Greg, anything You want :))))) Thanks a lot! :)) it works!

I've changed ctrl_outb(19,SCBRR);  19 is for my platform with operating
frequency 25MHz - that wasn't a really problem.

But thanks to Your tip, simple thing :), "loop forever" - I see, that
everything works fine, also "sash". 

thank You very much,

Grateful :))
Pawel

Re: AW: [linuxsh-dev] printf

[Greg B. <gb...@po...>]

"Studencki (external) Pawel" wrote:
> 
> Hello,
> 
> Greg, thanks for Your answer.
> 
> > > what's more.. when I put some lines like "write(fd,"hello
> > world",15);", than
> > > I could not even see the output form "printf"...
> >
> >   Sorry, I don't quite understand your statement.  Are you calling
> > printf() or write()?
> 
> I've put "write" in init thread in init/main.c, before /sbin/init is
> started. It seems like the "write" outputs have blocked printf... which
> comes from RAM disk.
> User programm is:
> #include<stdio.h>
> #include<sys/types.h>
> #include<fcntl.h>
> int main (void)
> {
> int i,fd;
> 
>         for(i=0;i<4;i++){

  Can you try making this loop forever?

  It could be (I'm guessing here) that your usermode program is exiting
before the kernel has finished writing its output to the serial port.
Bad things happen when the first usermode process dies.


> 
>         printf("--- H E L L O   W O R L D  ***  \n");
> 
>         }
> fflush(NULL);
> 
> return 1;
> }
> ========================================================
> Greg, I've put put some printks to debug function sci_set_baud and
> SCSMR = 0
> t = 26
> 
> I'm not sure, are these settings correct for my platform.

  That depends.  What is your platform?

> According to
> hardware manual, I have to know "operating frequency for periphelar devices"
> to set SCBRR correct. Is this value showed at booting of kernel?

   Yes, it's the one listed under `Module clock'.  In the CVS kernel,
the BPS_* numbers are expressions calculated from the module clock; in older
versions (before Stuart's changes) they were constants conditionally
defined.

> I'm a little bit confused about all these problems, because I had allready
> working RAM disk with init, bash ...I don't see any reason for these
> troubles.

  So what did you change?

> I've also tried to start with new kernel 2.4.0, I've modified in
> arch/sh/kernel/setup.c line for
> #define COMMAND_LINE "console=ttySC1,38400" and set correct baud rate. I
> cannot see any boot messages. 

  Can you please do this for me?

cd your-kernel-directory
grep CONFIG_SH_ .config
grep CONFIG_CPU_SUBTYPE .config


Greg.
-- 
These are my opinions not PPIs.

AW: [linuxsh-dev] printf

[Studencki (e. P. <Paw...@er...>]

Hello,

Greg, thanks for Your answer.

> > what's more.. when I put some lines like "write(fd,"hello 
> world",15);", than
> > I could not even see the output form "printf"...
> 
>   Sorry, I don't quite understand your statement.  Are you calling
> printf() or write()?

I've put "write" in init thread in init/main.c, before /sbin/init is
started. It seems like the "write" outputs have blocked printf... which
comes from RAM disk.
User programm is:
#include<stdio.h>
#include<sys/types.h>
#include<fcntl.h>
int main (void)
{
int i,fd;

        for(i=0;i<4;i++){

        printf("--- H E L L O   W O R L D  ***  \n");

        }
fflush(NULL);

return 1;
}
========================================================
Greg, I've put put some printks to debug function sci_set_baud and 
SCSMR = 0
t = 26

I'm not sure, are these settings correct for my platform. According to
hardware manual, I have to know "operating frequency for periphelar devices"
to set SCBRR correct. Is this value showed at booting of kernel?

I'm a little bit confused about all these problems, because I had allready
working RAM disk with init, bash ...I don't see any reason for these
troubles.

I've also tried to start with new kernel 2.4.0, I've modified in
arch/sh/kernel/setup.c line for
#define COMMAND_LINE "console=ttySC1,38400" and set correct baud rate. I
cannot see any boot messages. SO I think, I have to use GDB Stub (SH-IPL+g)
to get possibility really debbuging the code


thanks for tips,

Pawel

Re: [linuxsh-dev] printf

[Greg B. <gb...@po...>]

"Studencki (external) Pawel" wrote:
> 
> Hi,
> 
> I'm still trying to get working kernel 2.3.99 with a RAM disk.
> Boot messages:
> ------------------
> RAMDISK: ext2 filesystem found at block 0
> RAMDISK: Loading 1024 blocks [1 disk] into ram disk... done.
> Freeing initrd memory: 1024k freed
> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 28k freed
>  --- H E L     <------- it's from "hello world" program in RAM disk

  Ok, so you've got *some* output from a usermode program!

  Any chance you could share the source for this hello world program
so I can see what it was supposed to do?  It's hard for me to comment
on this log by itself.

> 
> ---- that's all...
> 
> Greg, is this the same problem with system calls, which did You and Mitch
> had?

  No.  The symptoms of that problem were a complete and total silence
from user space.  Not a single system call worked.  From your log above
it appears that at least one system call has worked.

> I'm looking for a errors or bugs, but I'm not sure, is this a system call
> problem (so I _have_ to change the  kernel to 2.4.0-test) or this could be a
> problem with initial serial port ( I've changed some things in sh-sci.c,
> because I was getting output like this:
> K<ó{´óK;KCt·L¼·L7´·Lw¿3<³Dt7Ä3KKCË4EUR´´´´EUR<ó Ct;<ûË7KóD3<<<´0fü»»»EUR0´ÿ)
> 
> in function sci_set_termios_cflag
> 
>  - ctrl_out(0x00, SCSCR);  /* TE=0, RE=0, CKE1=0 */
>  + /*ctrl_out(0x00, SCSCR);*/  /* TE=0, RE=0, CKE1=0 */
> 
> and in function sci_set_baud
>  - ctrl_outb(t, SCBRR);
>  + /*ctrl_outb(t, SCBRR);*/

  These sound like a really bad idea in the long run.  You're basically
relying on the boot program to setup the SCI right.

> i can at least read console with these modifications...

  Preventing the kernel from setting the SCSCR register is only
going to result in grief, sooner or later.

  At this point I'd like to recommend again that you upgrade to the
latest kernel in CVS and the appropriate glibc.  It's only going to
get harder for people on this list to help you with older kernels.

> what's more.. when I put some lines like "write(fd,"hello world",15);", than
> I could not even see the output form "printf"...

  Sorry, I don't quite understand your statement.  Are you calling
printf() or write()?

Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] printf

[Studencki (e. P. <Paw...@er...>]

Hi,

I'm still trying to get working kernel 2.3.99 with a RAM disk. 
Boot messages:
------------------
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 1024 blocks [1 disk] into ram disk... done.
Freeing initrd memory: 1024k freed
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 28k freed
 --- H E L     <------- it's from "hello world" program in RAM disk


---- that's all...

Greg, is this the same problem with system calls, which did You and Mitch
had?
I'm looking for a errors or bugs, but I'm not sure, is this a system call
problem (so I _have_ to change the  kernel to 2.4.0-test) or this could be a
problem with initial serial port ( I've changed some things in sh-sci.c,
because I was getting output like this:
K<ó{´óK;KCt·L¼·L7´·Lw¿3<³Dt7Ä3KKCË4EUR´´´´EUR<ó Ct;<ûË7KóD3<<<´0fü»»»EUR0´ÿ)

in function sci_set_termios_cflag

 - ctrl_out(0x00, SCSCR);  /* TE=0, RE=0, CKE1=0 */
 + /*ctrl_out(0x00, SCSCR);*/  /* TE=0, RE=0, CKE1=0 */

and in function sci_set_baud 
 - ctrl_outb(t, SCBRR);
 + /*ctrl_outb(t, SCBRR);*/

i can at least read console with these modifications...
what's more.. when I put some lines like "write(fd,"hello world",15);", than
I could not even see the output form "printf"...

any ideas?

regards 
pawel

[linuxsh-dev] [linux-sh:01239] linuxsh-cvs mailing list

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

Greg Banks wrote:
 > I've just set up sourceforge's CVS to send CVS checkin logs to
 > the linuxsh-cvs mailing list.  To subscribe to that mailing
 > list, go to 
 > 
 > http://lists.sourceforge.net/mailman/listinfo/linuxsh-cvs

Wow, good!  Thanks for the effort.

Besides, I'd like to encourage all of developpers to record ChangeLog.
While E-mail is the tool for the communication, it's good to record
the things in the ChangeLog file.
-- 

[linuxsh-dev] linuxsh-cvs mailing list

[Greg B. <gb...@po...>]

G'day

I've just set up sourceforge's CVS to send CVS checkin logs to
the linuxsh-cvs mailing list.  To subscribe to that mailing
list, go to 

http://lists.sourceforge.net/mailman/listinfo/linuxsh-cvs

Greg.
-- 
These are my opinions not PPIs.