Buffalo ARM9 Kernel Port

From NAS-Central Buffalo - The Linkstation Wiki
Revision as of 20:49, 3 October 2007 by Goat (Talk | contribs)

Jump to: navigation, search

4033.jpg


Contents

Stock Kernel

Linux version 2.6.12.6-arm1 (root@develop) (gcc version 3.4.4 (release) 
(CodeSourcery ARM 2005q3-2)) #75 Sun Jun 11 14:33:24 JST 2006

GPL

http://downloads.nas-central.org/LSPro_ARM9/GPL/gpl_ls-gl.zip
the GPL-source seems to be quite patched compared to the vanilla kernel.


About

We are trying to create a patch for the vanilla kernel so we can download and compile the kernel.org kernel sources for the arm9-buffalo-boxes easily.

As all the major reported bugs seem to have been resolved (with the exception of XFS), the kernel is now available for the general community to test. Please be advised, this kernel is still a work in progress, and by no means should be used in a work environment until declared stable.

Unlike other projects, the kernel source will no longer be placed in the Development Section of downloads. However, pre-built binaries will only be placed in either svn (will move to git shortly), or in the Development Section until the kernel is stable. Two reasons are given for this: the first is that it is too difficult to build binaries for every revision, as revisions are constantly being made, the second being that we want to discourage unexperienced users from using this kernel. If you know how to build the kernel, you probably are knowledgeable enough to fix problems that might arise. Of course, this policy is subject to change, and the entire community will be encouraged to try the kernels, as the project moves into it's final stable stage.

Note: By using the kernels from svn, users are still subject to the LinkstationWiki BetaTesters ToS and Disclaimer (Not trying to scare people, just warning newbies).

Bugs ought to be posted in the bugtracker, developmental posts should continue to be posted here.

Where You Can Help!

We need c coders 
to help assist in the cleanup of /arch/arm/mach-mv88fxx81 and /include/asm-arm/arch-mv88fxx81
We need help in creating a Kernel Project Roadmap 
including what's been done, and what needs to be done (lyakh's request). Also, a description of buffalo specific drivers, in both the kernel and firmwares is needed.
We need a volunteer developer to help recode a standard uboot for the LSPro/Live/KuroboxPro/TSPv2. 
It should be based on LNI's ppc builds, in terms of "EM Mode" setup.

Port Info

The arm9 kernel is being prepared for standard vanilla submission, however much work is still needed. Developers are encouraged to focus on 2.6.22, unless major bugs arise, in an effort to make the standardization process more efficient. Note, Tzachi from Marvell is preparing the mv88f5182 vanilla support package, and changes in the svn version will reflect those changes as they are made.

Standardization Process

The Standardization Process should follow these guidelines:

  1. Break apart the Marvell LSP Drivers, and place them in the proper locations.
  2. Move board specific defines to a single board header (i.e. linkstation.h or maxtor.h).
  3. Drivers ought to be board (not necessarily arch) independent as possible. If the drivers truly will only work for the Marvell board, the drivers should then be marked accordingly in the kconfigs (i.e. depends on config_mv88fxx81).
  4. Irrelevant garbage from other Marvell boards ought to be removed. If someone wants to add standard support for another board (i.e. mv881151, let them do it properly).
  5. Rewrite Marvell style of driver coding, i.e. MV_ type registers. See the appropriate linux mailing lists for more details.


Extra Details

  • The kernel is expected to work on the LSPro/Live, Kurobox Pro, and Terastation Pro, however only the LSPro/Live are known to be fully supported.
  • Luca has reported an XFS issue, that must be verified. XFS for Logical Partitions is not yet verified to be bug free.
  • The i2c driver, for which the Real Time Clock (RTC) depends on is incomplete. Developers are requested to help finish the driver.
  • The Kurobox Pro requires a modified U-Boot environment in order to boot. The stock flash appears to prohibits the booting of newer kernels. Check this thread for updates.
  • Kernel is reported to have booted on the Maxtor MSS-II.
  • Need verification if kernel works on the TSPv2.


Sources

  • Current kernel sources:
http://linkstationwiki.svn.sourceforge.net/viewvc/linkstationwiki/kernel_arm9/trunk/src/linux-2.6.22/
  • Current configs (make sure to use the right ones):
http://linkstationwiki.svn.sourceforge.net/viewvc/linkstationwiki/kernel_arm9/trunk/configs/


Compilation Instructions

  • Obtain the sources:
svn co https://linkstationwiki.svn.sourceforge.net/svnroot/linkstationwiki/kernel_arm9/trunk/src/linux-2.6.22/
  • Copy config to the toplevel source directory, and rename to .config.
  • Install either a native or cross toolchain. Cross-compiling with a Codesourcery toolchain is recommended. Change the toplevel Makefile var "CROSS_COMPILE" to equal the full path of your toolchain, i.e.
CROSS_COMPILE ?=/home/jon/toolchain/arm-2006q3/arm-none-linux-eabi-
  • download mkimage to somewhere in your path:
http://downloads.nas-central.org/LSPro_ARM9/DevelopmentTools/CrossToolchains/mkimage
  • Run the following command to make any changes to the config file (including any ReiserFS or JFS support):
make menuconfig
  • Run
make uImage
  • After kernel is finished compiling, find it in /arch/arm/boot/uImage and copy to your /boot directory on the Linkstation/Kuro. Make sure to rename it to uImage.buffalo.
  • If necessary, compile modules and be sure if you are cross compiling not to set the install path to the hosts root:
make modules
make modules_install INSTALL_MOD_PATH=/<absolute/dir/loc/not/root/dir>
  • copy lib/ directory that is created to / of linkstation
  • Please report in this poll here, if the kernel worked or not. :-P

List of drivers that need to be redone eventually

  • i2c
  • RTC
  • ...
  • ...
  • ...

XFS Arm Issues

There is currently a problem with XFS on the Linkstation Pro (and most likely all other ARM9 based devices). The problems are reproducible on stock Buffalo kernels (2.6.12 and 2.6.16) and the latest version of this port (2.6.22). The XFS code in the kernels is unchanged from the mainline kernel and the problems do not occur on x86 and x86_64 hardware.

Steps to Reproduce

On the older stock kernels, this bug rarely occurs and even on 2.6.22 only a few users have had problems. The best way to reproduce is to use the quality assurance tests provided by XFS. You have to get these from the CFS repository at SGI:

export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs'
cvs login
cvs checkout xfs-cmds
cd xfs-cmds
make

These tests require two XFS formatted partitions and mount points. All data on these partitions will most likely be destroyed. If you have two partitions /dev/sda7 and /dev/sda8 and two mount points /mnt/sda7 and /mnt/sda8, add your hostname and settings to xfstests/common.config:

known_hosts()
{
    case "$HOST" in
        ls1)
            SCRATCH_MNT=/mnt/sda8
            SCRATCH_DEV=/dev/sda8
            TEST_DIR=/mnt/sda7
            TEST_DEV=/dev/sda7
            ;;
        vimes)
            ...

There are a total of 180 tests, some of them will run but leave the partitions in an inconsistent and irreparable state, some tests will cause the Linkstation to panic and shutdown. To run test 1:

cd xfstests
./check 001

More detail can be gained by compiling XFS in DEBUG mode, to do this add the following to fs/xfs/Kconfig, enable the option in the .config, recompile and boot with the resulting kernel

config XFS_DEBUG
        bool "XFS Debugging"
        depends on XFS_FS
        help
          Debug

This is the assertion that fails when test 001 is run in DEBUG mode.

Assertion failed: (char *)sfep - (char *)sfp == dp->i_d.di_size, file: fs/xfs/xfs_dir2_sf.c, line: 647
kernel BUG at fs/xfs/support/debug.c:82!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c5888000
[00000000] *pgd=06254031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
Modules linked in: nfs nfsd exportfs lockd nfs_acl sunrpc reiserfs fuse
CPU: 0    Not tainted  (2.6.22 #7)
PC is at __bug+0x20/0x2c
LR is at 0x60000013
pc : [<c002937c>]    lr : [<60000013>]    psr: 60000013
sp : c678fba0  ip : c678fad0  fp : c678fbac
r10: c606fd40  r9 : c01a6aac  r8 : 00000008
r7 : c606fda8  r6 : 00000000  r5 : 00000030  r4 : c606fdae
r3 : 00000000  r2 : 00000000  r1 : 0000223a  r0 : 0000002c
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: a005317f  Table: 05888000  DAC: 00000015
Process mkdir (pid: 1522, stack limit = 0xc678e260)
Stack: (0xc678fba0 to 0xc6790000)
fba0: c678fbbc c678fbb0 c01ab70c c002936c c678fbe4 c678fbc0 c015d6e0 c01ab6ec
fbc0: 00000000 c63b8290 c606fd40 00000000 00000008 c678fd04 c678fc1c c678fbe8
fbe0: c015d760 c015d5f4 c00c48a8 c678fc20 c678fc0c 00000000 c63b8290 c606fd40
fc00: 00000000 00000008 c01a6aac c678fd04 c678fca4 c678fc20 c015205c c015d748
fc20: c63b8290 00000004 c678ff00 00000008 c160e498 062d19b9 00000000 00000000
fc40: c606fd40 00000000 00000000 00000000 00000000 00000000 00000008 00000000
fc60: 000005f2 c018f22c 00000000 00000000 00000000 00000000 01000000 00000000
fc80: 00000000 00000000 c606fd60 c63b8238 c606fd40 c678fcf8 c678fce4 c678fca8
fca0: c018f244 c0151f48 c678fcf8 c016bec0 00000000 00000008 00460000 00000000
fcc0: 00000008 00460000 00000000 c606fd60 c606fd40 c63b8238 c678fd34 c678fce8
fce0: c01953b4 c018f1e4 c678fd04 c678fcf8 00000010 c678fd44 c678e000 000200d2
fd00: c678fd2c c678fd10 c678fd2c c63b8238 00000000 c61a2458 c678fdb0 c678fda4
fd20: c1714aa0 c6070e40 c678fd5c c678fd38 c01a6aac c019530c 00000000 00000000
fd40: c61a2458 c678fdb0 c678fec0 c63b8238 c678fd94 c678fd60 c009639c c01a6a68
fd60: c678e000 c6070eac c678fdcc c678fda4 c5e7700e 00000107 c678fec0 c5e77000
fd80: c678e000 00000000 c678fde4 c678fd98 c00981c0 c0096230 c678e000 00000001
fda0: c678fdc4 00c27168 00000004 c5e7700a c1714aa0 c61a2458 c678fdf4 c678fec0
fdc0: c17141a0 c678fec0 c78ba598 c5e77000 c678e000 c678fde8 c678fe5c c678fde8
fde0: c0098914 c00979a0 c78ba598 c17141a0 00000017 4013c000 c678ff3c 00000001
fe00: 00000001 00000000 c678ffb0 4013c058 0c678ffac c678ff00
fe20: c0024230 c002c6b0 c5889000 c5a64b64 c678ff10 00000002 c678fec0 c0552200
fe40: c5e77000 00000001 c0025794 009000c3 c678fe6c c678fe60 c0098a18 c0098894
fe60: c678fe9c c678fe70 c0098c40 c0098a04 c678fe9c c678fe80 c5e77000 00000001
fe80: c678fec0 ffffff9c c0025794 009000c3 c678febc c678fea0 c0099748 c0098b90
fea0: bebde6c4 c678ff40 c678fec0 000000c3 c678ff2c c678fec0 c0092184 c0099714
fec0: c61a2458 c1714aa0 00000017 4013c000 c678ff3c 00000001 00000001 00000000
fee0: c678ffb0 4013c058 00000000 40149000 c678ffac c678ff00 c0024230 c002c6b0
ff00: c5889000 c5a64b64 c678ff10 00000002 00000000 bebde6c4 c678ff40 bebde911
ff20: c678ff3c c678ff30 c0092274 c0092170 c678ffa4 c678ff40 c002b270 c0092268
ff40: 40017000 c0025794 c678ff64 00000000 00000000 400d9000 40016000 ffffffff
ff60: 00000001 00001fdc 00000001 0001520c 00000000 40149000 c678ff9c c678ff88
ff80: c002c9c0 c002c6b0 ffffffff ffffffff 00000001 00000000 00000000 c678ffa8
ffa0: c0024fa0 c002b260 00000001 00000000 bebde911 bebde6c4 bebde6c4 ffffffff
ffc0: 00000001 00000000 bebde911 bebde7a4 00000003 00000001 000001ed bebde754
ffe0: 400e1300 bebde638 0000984c 400e1310 60000010 bebde911 00000000 00000000
Backtrace:
[<c002935c>] (__bug+0x0/0x2c) from [<c01ab70c>] (assfail+0x30/0x38)
[<c01ab6dc>] (assfail+0x0/0x38) from [<c015d6e0>] (xfs_dir2_sf_check+0xfc/0x154)
[<c015d5e4>] (xfs_dir2_sf_check+0x0/0x154) from [<c015d760>] (xfs_dir2_sf_lookup+0x28/0x360)
[<c015d738>] (xfs_dir2_sf_lookup+0x0/0x360) from [<c015205c>] (xfs_dir_lookup+0x124/0x170)
[<c0151f38>] (xfs_dir_lookup+0x0/0x170) from [<c018f244>] (xfs_dir_lookup_int+0x70/0x134) r7:c678fcf8 r6:c606fd40 r5:c63b8238 r4:c606fd60
[<c018f1d4>] (xfs_dir_lookup_int+0x0/0x134) from [<c01953b4>] (xfs_lookup+0xb8/0x160)
[<c01952fc>] (xfs_lookup+0x0/0x160) from [<c01a6aac>] (xfs_vn_lookup+0x54/0x98)
[<c01a6a58>] (xfs_vn_lookup+0x0/0x98) from [<c009639c>] (do_lookup+0x17c/0x1b8) r5:c63b8238 r4:c678fec0
[<c0096220>] (do_lookup+0x0/0x1b8) from [<c00981c0>] (__link_path_walk+0x830/0xef4)
[<c0097990>] (__link_path_walk+0x0/0xef4) from [<c0098914>] (link_path_walk+0x90/0x170)
[<c0098884>] (link_path_walk+0x0/0x170) from [<c0098a18>] (path_walk+0x24/0x28)
[<c00989f4>] (path_walk+0x0/0x28) from [<c0098c40>] (do_path_lookup+0xc0/0x278)
[<c0098b80>] (do_path_lookup+0x0/0x278) from [<c0099748>] (__user_walk_fd+0x44/0x64)
[<c0099704>] (__user_walk_fd+0x0/0x64) from [<c0092184>] (vfs_stat_fd+0x24/0x54) r7:000000c3 r6:c678fec0 r5:c678ff40 r4:bebde6c4
[<c0092160>] (vfs_stat_fd+0x0/0x54) from [<c0092274>] (vfs_stat+0x1c/0x20) r6:bebde911 r5:c678ff40 r4:bebde6c4
[<c0092258>] (vfs_stat+0x0/0x20) from [<c002b270>] (sys_oabi_stat64+0x20/0x3c)
[<c002b250>] (sys_oabi_stat64+0x0/0x3c) from [<c0024fa0>] (ret_fast_syscall+0x0/0x2c) r5:00000000 r4:00000001
Code: e1a01000 e59f000c eb008188 e3a03000 (e5833000)

Possible Cause/Attempted Fixes

Over three years ago a patch was released that fixed XFS on the ARM. However, this patch was against 2.4.24 and no longer fixes the latest versions. This patch was never accepted by XFS because the code is incorrect for all other platforms.

------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
-------------- next part --------------
--- xfs_dir2_sf.c.org	2004-02-17 14:56:16.000000000 +1000
+++ xfs_dir2_sf.c	2004-02-17 14:55:16.000000000 +1000
@@ -148,6 +148,7 @@
 		/*
 		 * Calculate the new size, see if we should give up yet.
 		 */
+#if 0
 		size = XFS_DIR2_SF_HDR_SIZE(i8count) +		/* header */
 		       count +					/* namelen */
 		       count * (uint)sizeof(xfs_dir2_sf_off_t) + /* offset */
@@ -155,6 +156,13 @@
 		       (i8count ?				/* inumber */
 				(uint)sizeof(xfs_dir2_ino8_t) * count :
 				(uint)sizeof(xfs_dir2_ino4_t) * count);
+#endif
+		size = XFS_DIR2_SF_HDR_SIZE(i8count)		/* header */
+		       + namelen
+		       + (count * (sizeof(xfs_dir2_sf_entry_t) - 1))
+		       - (count * (((i8count == 0) ? 1 : 0) *
+				(sizeof(xfs_dir2_ino8_t) - sizeof(xfs_dir2_ino4_t))));
+			
 		if (size > XFS_IFORK_DSIZE(dp))
 			return size;		/* size value is a failure */
 	}

I was pointed to a debian bug by esandeen in #xfs which has a testcase to demonstrate the "special" structure alignment on the ARM. esandeen reccomended that I compare structure sizes and their member offsets between x86 and ARM. After modifying over 40 structures by adding __attribute__((packed)) the problem is still there. I also tried compiling with -mstructure-size-boundary=8 but this also made no difference. Searching for typedef struct produced over two hundred structures in the XFS code, I compared the size and member offsets between x86 and arm by running gdb fs/xfs/xfs.o and using the following gdb defines:

define si
p sizeof( $arg0 )
end
define offsetof
print ((unsigned long) &((struct $arg1 *)0)->$arg0)
end

Out of these structs, the following table lists those that are different:

file struct x86 size arm size notes
xfs_mount.h xfs_mount_t 852 864 Fixed with __attribute__((packed)) and int __attribute__((aligned (2))) m_dirblksize;
xfs_mod_sb.h xfs_mod_sb_t 12 16 Fixed with __attribute__((packed))
xfs_da_btree.h xfs_da_args_t 92 96 Fixed with __attribute__((packed))
xfs_da_btree.h xfs_da_state_blk_t 28 32 Fixed with __attribute__((packed))
xfs_da_btree.h xfs_da_state_path_t 144 168 Fixed with __attribute__((packed))
xfs_da_btree.h xfs_da_state_t 336 392 Fixed with __attribute__((packed)) and unsigned char __attribute__((aligned (2))) extraafter;
xfs_trans.h xfs_log_item_t 44 48 Fixed with __attribute__((packed))
xfs_trans.h xfs_trans_t 652 656 Fixed with __attribute__((packed))
xfs_dir2_data.h xfs_dir2_data_entry_t 12 16 Fixed with __attribute__((packed))
xfs_dir2_data.h xfs_dir2_data_t 28 32 Fixed with __attribute__((packed))
xfs_type.h xfs_dirent_t 20 24 Fixed with __attribute__((packed))
xfs_dir2_block.h xfs_dir2_block_t 44 48 Fixed with __attribute__((packed))
xfs_log_priv.h xlog_rec_header_t 324 328 Fixed with __attribute__((packed))
xfs_bmap_btree.h xfs_bmbt_irec_t 28 32 Adding packed dropped it to 24 on the arm
xfs_inode.h xfs_iocore_t 36 40 Fixed with __attribute__((packed))
xfs_inode.h xfs_chashlist_t 24 32 Fixed with __attribute__((packed))
xfs_inode.h xfs_inode_t 388 408 Fixed with __attribute__((packed))
xfs_btree.h xfs_btree_cur_t 140 144 Fixed with
        union {
                xfs_alloc_rec_incore_t  a;
                xfs_bmbt_irec_t         b;
                xfs_inobt_rec_incore_t  i;
        } __attribute__((aligned (8))) bc_rec;
xfs_bmap.h xfs_bmap_free_item_t 16 12 This depends on xfs_fsblock_t which is either 32 or 64-bit depending on XFS_BIG_BLKNOS
xfs_bmap.h xfs_bmalloca_t 64 56 This depends on two xfs_fsblock_t's which is either 32 or 64-bit depending on XFS_BIG_BLKNOS
xfs_inode_item.h xfs_inode_log_format_t 52 56 Fixed with __attribute__((packed))
xfs_inode_item.h xfs_inode_log_item_t 148 160 Fixed with __attribute__((packed))
xfs_imap.h xfs_imap_t 20 24 Fixed with __attribute__((packed))
xfs_extfree_item.h xfs_extent_t 12 16 Fixed with __attribute__((packed))</cod
xfs_extfree_item.h xfs_efd_log_format_t 28 32 Fixed with <code>__attribute__((packed))
xfs_extfree_item.h xfs_efi_log_item_t 80 88 Fixed with __attribute__((packed))
xfs_extfree_item.h xfs_efd_log_item_t 80 88 Fixed with __attribute__((packed))
xfs_buf_item.h xfs_buf_log_item_t 88 96 Fixed with __attribute__((packed))
xfs_buf_item.h xfs_buf_cancel_t 20 24 Fixed with __attribute__((packed))
xfs_fs.h xfs_flock64_t 44 48 Fixed with __attribute__((packed))
xfs_fs.h xfs_fsop_geom_v1_t 108 112 Fixed with __attribute__((packed))
xfs_fs.h xfs_growfs_data_t 12 16
xfs_fs.h xfs_growfs_rt_t 12 16 Fixed with __attribute__((packed))
xfs_fs.h xfs_bstat_t 108 112 Fixed with __attribute__((packed))
xfs_fs.h xfs_inogrp_t 20 24 Fixed with __attribute__((packed))
xfs_sb.h xfs_sb_t 204 208 Fixed with __attribute__((packed))
linux-2.6/xfs_vnode.h bhv_vname_t 128 124
linux-2.6/xfs_vnode.h bhv_vattr_t 100 112
linux-2.6/xfs_buf.h xfs_buf_t 180 184 Fixed with __attribute__((packed))
bhv_statvfs_t.h linux-2.6/xfs_vfs.h 84 88
xfs_dinode.h xfs_dinode_t 140 144 Fixed with __attribute__((packed))


Next

Since aligning the structs myself has not helped, I will send a report to the XFS mailing list and CC LKML.

Contacts

Current developers include lb_worm, lyakh, and jonli447. Please contact one of us if you're interested in joining the efforts.

Roadmap

  • We want to work on Buffalo ARM9 system support in the Linux kernel together with Marvell developers, specifically, Tzachi Perelstein has submitted a series of patches to support Marvell feroceon and orion SoCs, and we want to base our future work on his patches and co-ordinate our work with him.
  • Our goal is the inclusion of orion support in the mainline kernel, therefore we want to organise our work in a way that would make the future merge as simple as possible. One of implications of this decision is that we want to use git as our VCS.
  • We will install a git kernel tree on the server and select a maintainer for it.
  • This tree will be created by cloning the Linus' tree from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
  • Then we will create a branch holding the current development state (import from svn). This branch will be called something like "fubbalo." This branch will be frozen, all new development will be based on the next branch:
  • Another branch will be created, based on the latest patches from Tzachi. It will be called "marvell." This is where our main development will take place.
  • Having created the "marvell" branch, it might make sense to put our own patches on a further sub-branch.
  • As for the development process, the maintainer of this tree will be accepting patches / pull requests from other developers and merge them (after a due review:-)) into the public tree.
  • The patches shall be prepared in accordance with Linux kernel patch requirements, i.e., as described in Documentation/SubmittingPatches. This will insure "easy" integration in the mainline in the future...