Hi all,
Fixed some issues and resend the patch now.
This is the documents patche for Blackfin arch, also includes the
MAINTAINERS file change.
Signed-off-by: Luke Yang <[email protected]>
Acked-by: Alan Cox <[email protected]>
Documentation/blackfin/00-INDEX | 11 ++
Documentation/blackfin/Filesystems | 169 +++++++++++++++++++++++++++++++
Documentation/blackfin/cache-lock.txt | 48 ++++++++
Documentation/blackfin/cachefeatures.txt | 65 +++++++++++
MAINTAINERS | 40 +++++++
5 files changed, 333 insertions(+)
diff -urN linux-2.6.18.patch3/Documentation/blackfin/00-INDEX
linux-2.6.18.patch4/Documentation/blackfin/00-INDEX
--- linux-2.6.18.patch3/Documentation/blackfin/00-INDEX 1970-01-01
08:00:00.000000000 +0800
+++ linux-2.6.18.patch4/Documentation/blackfin/00-INDEX 2006-09-22
12:03:11.000000000 +0800
@@ -0,0 +1,11 @@
+00-INDEX
+ - This file
+
+cache-lock.txt
+ - HOWTO for blackfin cache locking.
+
+cachefeatures.txt
+ - Supported cache features.
+
+Filesystems
+ - Requirements for mounting the root file system.
diff -urN linux-2.6.18.patch3/Documentation/blackfin/Filesystems
linux-2.6.18.patch4/Documentation/blackfin/Filesystems
--- linux-2.6.18.patch3/Documentation/blackfin/Filesystems 1970-01-01
08:00:00.000000000 +0800
+++ linux-2.6.18.patch4/Documentation/blackfin/Filesystems 2006-09-22
12:03:11.000000000 +0800
@@ -0,0 +1,169 @@
+/*
+ * File: Documentation/blackfin/Filesystems
+ * Based on:
+ * Author:
+ *
+ * Created:
+ * Description: This file contains the simple DMA Implementation for Blackfin
+ *
+ * Rev: $Id: Filesystems,v 1.17 2006/08/08 20:46:13 vapier Exp $
+ *
+ * Modified:
+ * Copyright 2004-2006 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ */
+
+ How to mount the root file system in uClinux/Blackfin
+ -----------------------------------------------------
+
+1 Mounting EXT3 File system.
+ ------------------------
+
+ Creating an EXT3 File system for uClinux/Blackfin:
+
+
+Please follow the steps to form the EXT3 File system and mount the same as root
+file system.
+
+a Make an ext3 file system as large as you want the final root file
+ system.
+
+ mkfs.ext3 /dev/ram0 <your-rootfs-size-in-1k-blocks>
+
+b Mount this Empty file system on a free directory as:
+
+ mount -t ext3 /dev/ram0 ./test
+ where ./test is the empty directory.
+
+c Copy your root fs directory that you have so carefully made over.
+
+ cp -af /tmp/my_final_rootfs_files/* ./test
+
+ (For ex: cp -af uClinux-dist/romfs/* ./test)
+
+d If you have done everything right till now you should be able to see
+ the required "root" dir's (that's etc, root, bin, lib, sbin...)
+
+e Now unmount the file system
+
+ umount ./test
+
+f Create the root file system image.
+
+ dd if=/dev/ram0 bs=1k count=<your-rootfs-size-in-1k-blocks> \
+ > ext3fs.img
+
+
+Now you have to tell the kernel that will be mounting this file system as
+rootfs.
+So do a make menuconfig under kernel and select the Ext3 journaling file system
+support under File system --> submenu.
+
+
+2. Mounting EXT2 File system.
+ -------------------------
+
+By default the ext2 file system image will be created if you invoke make from
+the top uClinux-dist directory.
+
+
+3. Mounting CRAMFS File System
+ ----------------------------
+
+To create a CRAMFS file system image execute the command
+
+ mkfs.cramfs ./test cramfs.img
+
+ where ./test is the target directory.
+
+
+4. Mounting ROMFS File System
+ --------------------------
+
+To create a ROMFS file system image execute the command
+
+ genromfs -v -V "ROMdisk" -f romfs.img -d ./test
+
+ where ./test is the target directory
+
+
+5. Mounting the JFFS2 Filesystem
+ -----------------------------
+
+To create a compressed JFFS filesystem (JFFS2), please execute the command
+
+ mkfs.jffs2 -d ./test -o jffs2.img
+
+ where ./test is the target directory.
+
+However, please make sure the following is in your kernel config.
+
+/*
+ * RAM/ROM/Flash chip drivers
+ */
+#define CONFIG_MTD_CFI 1
+#define CONFIG_MTD_ROM 1
+/*
+ * Mapping drivers for chip access
+ */
+#define CONFIG_MTD_COMPLEX_MAPPINGS 1
+#define CONFIG_MTD_BF533 1
+#undef CONFIG_MTD_UCLINUX
+
+Through the u-boot boot loader, use the jffs2.img in the corresponding
+partition made in linux-2.6.x/drivers/mtd/maps/bf533_flash.c.
+
+NOTE - Currently the Flash driver is available only for EZKIT. Watch out for a
+ STAMP driver soon.
+
+
+6. Mounting the NFS File system
+ -----------------------------
+
+ For mounting the NFS please do the following in the kernel config.
+
+ In Networking Support --> Networking options --> TCP/IP networking -->
+ IP: kernel level autoconfiguration
+
+ Enable BOOTP Support.
+
+ In Kernel hacking --> Compiled-in kernel boot parameter add the following
+
+ root=/dev/nfs rw ip=bootp
+
+ In File system --> Network File system, Enable
+
+ NFS file system support --> NFSv3 client support
+ Root File system on NFS
+
+ in uClibc menuconfig, do the following
+ In Networking Support
+ enable Remote Procedure Call (RPC) support
+ Full RPC Support
+
+ On the Host side, ensure that /etc/dhcpd.conf looks something like this
+
+ ddns-update-style ad-hoc;
+ allow bootp;
+ subnet 10.100.4.0 netmask 255.255.255.0 {
+ default-lease-time 122209600;
+ max-lease-time 31557600;
+ group {
+ host bf533 {
+ hardware ethernet 00:CF:52:49:C3:01;
+ fixed-address 10.100.4.50;
+ option root-path "/home/nfsmount";
+ }
+ }
+
+ ensure that /etc/exports looks something like this
+ /home/nfsmount *(rw,no_root_squash,no_all_squash)
+
+ run the following commands as root (may differ depending on your
+ distribution) :
+ - service nfs start
+ - service portmap start
+ - service dhcpd start
+ - /usr/sbin/exportfs
diff -urN linux-2.6.18.patch3/Documentation/blackfin/cache-lock.txt
linux-2.6.18.patch4/Documentation/blackfin/cache-lock.txt
--- linux-2.6.18.patch3/Documentation/blackfin/cache-lock.txt 1970-01-01
08:00:00.000000000 +0800
+++ linux-2.6.18.patch4/Documentation/blackfin/cache-lock.txt 2006-09-22
12:03:11.000000000 +0800
@@ -0,0 +1,48 @@
+/*
+ * File: Documentation/blackfin/cache-lock.txt
+ * Based on:
+ * Author:
+ *
+ * Created:
+ * Description: This file contains the simple DMA Implementation for Blackfin
+ *
+ * Rev: $Id: cache-lock.txt,v 1.17 2006/08/08 20:46:13 vapier Exp $
+ *
+ * Modified:
+ * Copyright 2004-2006 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ */
+
+How to lock your code in cache in uClinux/blackfin
+--------------------------------------------------
+
+There are only a few steps required to lock your code into the cache.
+Currently you can lock the code by Way.
+
+Below are the interface provided for locking the cache.
+
+
+1. cache_grab_lock(int Ways);
+
+This function grab the lock for locking your code into the cache specified
+by Ways.
+
+
+2. cache_lock(int Ways);
+
+This function should be called after your critical code has been executed.
+Once the critical code exits, the code is now loaded into the cache. This
+function locks the code into the cache.
+
+
+So, the example sequence will be:
+
+ cache_grab_lock(WAY0_L); /* Grab the lock */
+
+ critical_code(); /* Execute the code of interest */
+
+ cache_lock(WAY0_L); /* Lock the cache */
+
+Where WAY0_L signifies WAY0 locking.
diff -urN linux-2.6.18.patch3/Documentation/blackfin/cachefeatures.txt
linux-2.6.18.patch4/Documentation/blackfin/cachefeatures.txt
--- linux-2.6.18.patch3/Documentation/blackfin/cachefeatures.txt 1970-01-01
08:00:00.000000000 +0800
+++ linux-2.6.18.patch4/Documentation/blackfin/cachefeatures.txt 2006-09-22
12:03:11.000000000 +0800
@@ -0,0 +1,65 @@
+/*
+ * File: Documentation/blackfin/cachefeatures.txt
+ * Based on:
+ * Author:
+ *
+ * Created:
+ * Description: This file contains the simple DMA Implementation for Blackfin
+ *
+ * Rev: $Id: cachefeatures.txt,v 1.17 2006/08/08 20:46:13 vapier Exp $
+ *
+ * Modified:
+ * Copyright 2004-2006 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ */
+
+ - Instruction and Data cache initialization.
+ icache_init();
+ dcache_init();
+
+ - Instruction and Data cache Invalidation Routines, when flushing the
+ same is not required.
+ _icache_invalidate();
+ _dcache_invalidate();
+
+ Also, for invalidating the entire instruction and data cache, the below
+ routines are provided (another method for invalidation, refer page
no 267 and 287 of
+ ADSP-BF533 Hardware Reference manual)
+
+ invalidate_entire_dcache();
+ invalidate_entire_icache();
+
+ -External Flushing of Instruction and data cache routines.
+
+ flush_instruction_cache();
+ flush_data_cache();
+
+ - Internal Flushing of Instruction and Data Cache.
+
+ icplb_flush();
+ dcplb_flush();
+
+ - Locking the cache.
+
+ cache_grab_lock();
+ cache_lock();
+
+ Please refer linux-2.6.x/Documentation/blackfin/cache-lock.txt for how to
+ lock the cache.
+
+ Locking the cache is optional feature.
+
+ - Miscellaneous cache functions.
+
+ flush_cache_all();
+ flush_cache_mm();
+ invalidate_dcache_range();
+ flush_dcache_range();
+ flush_dcache_page();
+ flush_cache_range();
+ flush_cache_page();
+ invalidate_dcache_range();
+ flush_page_to_ram();
+
diff -urN linux-2.6.18.patch3/MAINTAINERS linux-2.6.18.patch4/MAINTAINERS
--- linux-2.6.18.patch3/MAINTAINERS 2006-09-21 16:03:37.000000000 +0800
+++ linux-2.6.18.patch4/MAINTAINERS 2006-09-22 12:09:32.000000000 +0800
@@ -481,6 +481,46 @@
T: git kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
S: Maintained
+BLACKFIN ARCHITECTURE
+P: Aubrey Li
+M: [email protected]
+P: Bernd Schmidt
+M: [email protected]
+P: Grace Pan
+M: [email protected]
+P: Michael Hennerich
+M: [email protected]
+P: Mike Frysinger
+M: [email protected]
+P: Jean Lv
+M: [email protected]
+P: Jerry Zeng
+M: [email protected]
+P: Jie Zhang
+M: [email protected]
+P: Luke Yang
+M: [email protected]
+P: Robin Getz
+M: [email protected]
+P: Roy Huang
+M: [email protected]
+P: Sonic Zhang
+M: [email protected]
+P: Yi Li
+M: [email protected]
+L: [email protected]
+L: [email protected]
+W: http://blackfin.uclinux.org
+S: Supported
+
+BLACKFIN SERIAL DRIVER
+P: Aubrey Li
+M: [email protected]
+L: [email protected]
+L: [email protected]
+W: http://blackfin.uclinux.org
+S: Supported
+
BLUETOOTH SUBSYSTEM
P: Marcel Holtmann
M: [email protected]
--
Best regards,
Luke Yang
[email protected]
On Fri, Sep 22, 2006 at 01:05:09PM +0800, Luke Yang wrote:
> This is the documents patche for Blackfin arch, also includes the
> MAINTAINERS file change.
>
> Signed-off-by: Luke Yang <[email protected]>
> Acked-by: Alan Cox <[email protected]>
>
> Documentation/blackfin/00-INDEX | 11 ++
> Documentation/blackfin/Filesystems | 169
> +++++++++++++++++++++++++++++++
Your mailer does line-wrapping..
> +cache-lock.txt
> + - HOWTO for blackfin cache locking.
> +
This is a generic enough of a feature that I suspect we should hash out
a common API for it rather than having people roll their own.
> +How to lock your code in cache in uClinux/blackfin
> +--------------------------------------------------
> +
> +There are only a few steps required to lock your code into the cache.
> +Currently you can lock the code by Way.
> +
> +Below are the interface provided for locking the cache.
> +
> +
> +1. cache_grab_lock(int Ways);
> +
> +This function grab the lock for locking your code into the cache specified
> +by Ways.
> +
> +
> +2. cache_lock(int Ways);
> +
> +This function should be called after your critical code has been executed.
> +Once the critical code exits, the code is now loaded into the cache. This
> +function locks the code into the cache.
> +
> +
> +So, the example sequence will be:
> +
> + cache_grab_lock(WAY0_L); /* Grab the lock */
> +
> + critical_code(); /* Execute the code of interest */
> +
> + cache_lock(WAY0_L); /* Lock the cache */
> +
> +Where WAY0_L signifies WAY0 locking.
This seems rather problematic, obviously you're constrained by
sets-per-way in the critical code, which is not mentioned anywhere in
this documentation. Likewise, the user locking in the critical code
should not have any reason to _care_ which way gets selected, or whether
they need to span over to 2 ways or not. Furthermore, the code itself
allows for grabbing the cache 'lock' for multiple ways in one go, which
people will need to use for tracking the total number of sets necessary
to accomodate the critical code. You are also missing an equivalent
cache_unlock().
If you have MMIO access to the cachelines, you would be better off just
having a locked-in page where you would remap the critical bits.
This could also be taken a step further for platforms that support
powering down cache ways for power management (particularly where the
lock-in would inhibit power-down).
Paul indicated:
> > +cache-lock.txt
> > + - HOWTO for blackfin cache locking.
> > +
>
>This is a generic enough of a feature that I suspect we should hash out a
>common API for it rather than having people roll their own.
That sounds like a good idea. From the few people that use this, I think a
much simpler interface would be desirable.
For data, it is easy - something similar to the processor specific
xx_flush_range(start,end) - have a xxx_lock_range(start,end) would be good,
and easy to implement.
The only thing I am not sure of - is how to force things into cache. For
data - it is easy - do a read, and then lock it. For instruction - for
those architectures which have separate instruction cache (like Blackfin)
it is much harder. The only way to get code into cache is to execute it.
(ergo the existing interface).
Normally - what we do when locking things in cache is specific to the hardware.
- to prevent isr polluting cache, we disable interrupts
- If the code to be locked has a possibility of already being in the
instruction cache, we invalidate the entire cache first
- we locks 3/4 of the cache - forcing any code to be put into a specific
location.
- execute the code of interest (once)
- unlock the 3/4 of cache, and lock the 1/4 where the code of interest
is located.
- turn back on interrupts.
Because the algorithm is so specific to the hardware - I am not sure how to
make instruction as generic as data could be.
How does SH cache handle things like this?
-Robin
On Mon, Sep 25, 2006 at 01:51:34AM -0400, Robin Getz wrote:
> Paul indicated:
> >This is a generic enough of a feature that I suspect we should hash out a
> >common API for it rather than having people roll their own.
>
> That sounds like a good idea. From the few people that use this, I think a
> much simpler interface would be desirable.
>
> For data, it is easy - something similar to the processor specific
> xx_flush_range(start,end) - have a xxx_lock_range(start,end) would be good,
> and easy to implement.
>
Yes, xxx_lock_range() (and a corresponding xxx_unlock_range()) would be
ideal for this.
> The only thing I am not sure of - is how to force things into cache. For
> data - it is easy - do a read, and then lock it. For instruction - for
> those architectures which have separate instruction cache (like Blackfin)
> it is much harder. The only way to get code into cache is to execute it.
> (ergo the existing interface).
>
I suppose the first question is to determine whether it's really worth
doing the I-cache locking or simply sticking with a simplistic interface
aimed more at D-cache locking.
The I-cache case is somewhat more problematic, the only way to do it in
an architecture-neutral fashion is likely to expose a code page that is
pre-loaded and kicked down to the lower levels to work out the actual
locking semantics.
> Because the algorithm is so specific to the hardware - I am not sure how to
> make instruction as generic as data could be.
>
> How does SH cache handle things like this?
>
On SH both the I and D caches have MMIO access to the cache lines, so we
can jump to uncached space, clean the relevant cache, and then map the
data we want to lock directly in before jumping back to cached space.
So far we haven't done much with I-cache locking though.