Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Wed Aug 15, 2018 1:50 am

All times are UTC+01:00




Post new topic  Reply to topic  [ 120 posts ]  Go to page Previous 14 5 6 7 8 Next
Author Message
PostPosted: Mon Aug 31, 2009 4:07 am 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
shihsung & Bauldrick, I've made some progress w/ getting the kernel to compile in OE under uClibc... and I now have a new 2.6.30.5 initramfs that tftp boots with these commands ...
Code:
tftp 82000000 vmlinuz.gz ; set bootargs 'root=/dev/ram0 netconsole=6666@192.168.11.150/,@192.168.11.149/' ; bootm 82000000

Anyone wishing to try it out can download it here:
vmlinuz-2.6.30.5withtune2fs-DONT_FLASH_INTO_ROM.gz
uhhhmmm, the filename is horrible and not too subtle, but descriptive ... It is simply too large to fit in flash, but is completly safe to boot with from tftp or from the hdd. It needs a bit of work on the networking still (dhcp isn't working), but otherwise it it should help folks getting converted over to the new rtc setup.
It has the tune2fs binary included (to get around the count/date-triggered fsck issue. It also has ext4 support & mkfs.ext4, etc.

I actually have my LS2 set for 2-blink booting of this image from the hdd (I keep it in /boot-em/ , with a symlink called vmlinuz.gz pointing to it. ). Of course my uboot env vars are set a bit differently:
Code:
bootcmd2=run bootemhdd
bootemhdd=ext2load ide 0:1 82000000 /boot-em/vmlinuz.gz ; setenv bootargs=root=/dev/ram0 ; bootm 82000000


shihsung, I have a question for you, about uClibc perhaps. Can you think of anything in a compiler (buggish) that would impose a lower size limit on the kernlel? I can compile in under OpenEMbedded uClibc just fine, but it won't boot if it goes under about 5.4 MB (uncompressed). Any kernel I build w/ sane options will boot as long as it is 5.4MB or larger, but if I either disable too many option, or if I pull them out (as modules) then the kernel no longer boots. Any ideas? (I get the same results w/ gcc 4.3.3 and 4.2.4.)

There is no problem whatsoever compiling it in Buildroot uClibc - it boots at whatever size (with a bootable config, of course).

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Mon Aug 31, 2009 5:50 am 
Offline
Newbie

Joined: Sun Aug 05, 2007 4:15 am
Posts: 36
No, I'm not aware of such thing. Are you sure it's the kernel and not the initrd problem? Kernel is self-contained and doesn't need/use C library.


Top
   
PostPosted: Mon Aug 31, 2009 6:15 am 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
Well, I don't think its the kernel. The kernel itself seems just fine.

It compiles and boots fine when built with:
A-glibc in OpenEmbedded
B-uClibc in Buildroot
C-with the ELDK you recommend

When I build a kernel (just the kernel, not memtioning the rootfs) with uClibc in OE, it seems like it will not boot (no netconsole messages at all - nothing) once I reduce its size a certain amount.

The same minimal config that gives a bootable kernel with either A or C, yields a nonbooting kernel in B.

Also it seems strange that I can't get it to boot unless I have a few things in the Staging Drivers turned on (like Meilhaus). I'm thinking there is a problem with the uClibc toolchain in OpenEmbedded, but I have no clue right now how to track it down.

The problem is that this compiler/glitch, unless solved, will prevent us from building a small enough initramfs image to flash into ROM.

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Mon Aug 31, 2009 6:56 am 
Offline
Newbie

Joined: Sun Aug 05, 2007 4:15 am
Posts: 36
Well, the size of the kernel itself should vary very little whichever toolchain you use to build it. The size of the initrd would vary a lot depending on the libraries used. Have you try booting the kernel built with ELDK with the rootfs built with OE-uClibc toolchains?


Top
   
PostPosted: Mon Aug 31, 2009 1:18 pm 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
yes, that works fine. I've tried the OE-uclibc rootfs with the ELDK kernel - that's how I got my first complete boot w/ uclibc, for instance (actually, when I do that I just enable USB-Storage in-kernel and boot the rootfs from a USB pen drive).

The OE toolchain that we use (for foonas-em) is a fork of OE-dev, to be honest, though_very_ close to OE-dev.

Two distinctions/details I should point out:

1. the build system of OE starts truly from scratch, pure source, even for the toolchain. There is no downloading of the toolchain, only downloading of the source packages that are used to build it. First, the native parts (for i686) are built, and then cross-tools, then the target packages are built. The build process/sequence goes : gcc-cross-initial -> uclibc-initial -> gcc-cross-intermediate -> uclibc -> gcc-cross So, if I understand this correctly, the gcc-cross that get built partly depends on uclibc.

SInce each "fresh" run of OE, is from the ground up, in effect I've tried rebuilding the entire toolchain perhaps a 15 or 20 times, and the problem is reproducible each time (if I use one of the reduced kernel configs. the hdhlad-config in /arch/mips/configs is, for example, "too small", as well. But since it works just fine in glibc, I am sure this is a toolchain+uclibc=mayhem issue, not a problem w/ your kernel or your defconfig for the board.

2. The way timtimred set the foonas OE toolchain up for building foonas-emrequires two successive runs
A first build the foonas-em-image (the rootfs + a non-initramfs "bare" kernel)
B second rebuild the kernel and add in the cpio-ed rootfs to get the the initramfs image

When I test these kernels, I check both stages (A-the "bare" non-initramfs kernel, and B-the initramfs image) for bootability. I've also tried building a regular foonas (non-initramfs) kernel, and that results the same if I choose uclibc.



My thought is that I've found a difficult bug in the OE setup or maybe even in gcc 4.2.4. I'm just perplexed as where to start hunting. I did see this https://dev.openwrt.org/ticket/5351 , which make me wonder if I should try gcc 3.x.x, just for kicks. :)

Another thought is that this could be something particular to Ubuntu. Since the entire toolchain is built on our build boxes (and mine is running Jaunty Ubuntu), OE is sometimes sensitive to quirks/problems with what ever distro is installed.
====================

EDIT: I'm trying w/ 4 3.4 now - maybe that will make some difference?

Nope. Nada.

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Mon Aug 31, 2009 5:28 pm 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
shihsung, does anything look missing here? maybe there are some more possibilities for ARCH_CFLAGS= ?


Code:
#
# Automatically generated make config: don't edit
# Tue Jan 29 00:49:19 2008
#
# TARGET_alpha is not set
# TARGET_arm is not set
# TARGET_bfin is not set
# TARGET_cris is not set
# TARGET_e1 is not set
# TARGET_frv is not set
# TARGET_h8300 is not set
# TARGET_hppa is not set
# TARGET_i386 is not set
# TARGET_i960 is not set
# TARGET_ia64 is not set
# TARGET_m68k is not set
# TARGET_microblaze is not set
TARGET_mips=y
# TARGET_nios is not set
# TARGET_nios2 is not set
# TARGET_powerpc is not set
# TARGET_sh is not set
# TARGET_sh64 is not set
# TARGET_sparc is not set
# TARGET_v850 is not set
# TARGET_vax is not set
# TARGET_x86_64 is not set

#
# Target Architecture Features and Options
#
TARGET_ARCH="mips"
FORCE_OPTIONS_FOR_ARCH=y
ARCH_CFLAGS="-mno-split-addresses"
CONFIG_MIPS_O32_ABI=y
# CONFIG_MIPS_N32_ABI is not set
# CONFIG_MIPS_N64_ABI is not set
# CONFIG_MIPS_ISA_1 is not set
# CONFIG_MIPS_ISA_2 is not set
# CONFIG_MIPS_ISA_3 is not set
# CONFIG_MIPS_ISA_4 is not set
CONFIG_MIPS_ISA_MIPS32=y
# CONFIG_MIPS_ISA_MIPS64 is not set
TARGET_SUBARCH=""

#
# Using ELF file format
#
ARCH_ANY_ENDIAN=y
ARCH_LITTLE_ENDIAN=y
# ARCH_WANTS_BIG_ENDIAN is not set
ARCH_WANTS_LITTLE_ENDIAN=y
ARCH_HAS_MMU=y
ARCH_USE_MMU=y
UCLIBC_HAS_FLOATS=y
# UCLIBC_HAS_FPU is not set
UCLIBC_HAS_SOFT_FLOAT=y
DO_C99_MATH=y
KERNEL_HEADERS="/stuff/build/tmp/cross/mipsel-angstrom-linux-uclibc/include"
HAVE_DOT_CONFIG=y

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Wed Sep 02, 2009 4:41 am 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
still none of the uClibc problem solved in OE, but some joy to recount...

the foonas-em/OE toolchain worked great for building the rootfs, and then I used Buildroot uClibc to roll it up into an initramfs...

some folks over at #mipslinux suggest I try a higher binutils uclibc & gcc together, on OE.


=============================================

Also, shihsung, you mention here viewtopic.php?f=12&t=20753&p=132166&hilit=+mtd*#p132166

that one can enable mtd writing :
Quote:
"mtdparts=physmap-flash.0:0x40000(uboot)" to bootargs to enable MTD. This would enable /dev/mtd0 for U-Boot partition. You will need to do "eraseall /dev/mtd0" to erase the partition before flashing it with "dd if=old-u-boot dd=/dev/mtd0".


Is there a way we can have this enabled (by default) for both mtd block? Many of use will be wanting to flash foonas-em 2.6.30.5 to mtd1. :?:

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Thu Sep 03, 2009 2:31 am 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
OK, I just flashed this beta foonas-em-beta to ROM, and it works great, from what I see. Caveats:
1. I flashed it while booted in the OLD 2.6.22.19 foonas-em ... and until the mtd drivers are enabled by default, it would probably be best to tftp or hdd boot into foonas-em 2.6.22.19 again to do any more flashing.
2. As always, flash at your own risk. It worked perfectly for me on one box. It wouldn't flash on the second box, as that box has the "stubborn" flash chip - as expected, that box was not harmed, it just won't accept a flash in mtd1.
3. I can't promise you anything. If something goes wrong during flashing and it bricks, then you'd need JTAG.

What this image has:
- No official authorization as a regular foonas-em release... ;)
- ext4 support in e2fsprogs and in the kernel, so you can attempt fixes of ext4 errors/problems if you have any...
- tune2fs support so that upgraders from the older kernels can turn off date/count-based auto-fsck that causes some problems
- choose booting to this kernel by selecting 3 Flashes from the uboot miniconsole/powerbutton at boot time...
- support for writing and reading uboot env vars with fw_setenv and fw_printenv.

Code:
davygravy@DuoBuntu:~$ telnet 192.168.11.160
Trying 192.168.11.160...
Connected to 192.168.11.160.
Escape character is '^]'.

   ______ _____ _____ __   __  _____  ______
  |   ___|     |     |   \|  |/  _  \|   ___|
 _|   ___|  -  |  -  |       |   _   |\   \
| |__|   |_____|_____|__|\___|__| |__|_\   \
|___________________________________________|

foonas-em for lsmipsel - http://foonas.org

lsmipsel login: root
Password:
foonas-em$ cd /
foonas-em$ dd if=vmlinuz.gz of=/dev/mtdblock1 bs=1k
3367+1 records in
3367+1 records out
foonas-em$ Connection closed by foreign host.
davygravy@DuoBuntu:~$ telnet 192.168.11.160
Trying 192.168.11.160...
Connected to 192.168.11.160.
Escape character is '^]'.

   ______ _____ _____ __   __  _____  ______
  |   ___|     |     |   \|  |/  _  \|   ___|
 _|   ___|  -  |  -  |       |   _   |\   \
| |__|   |_____|_____|__|\___|__| |__|_\   \
|___________________________________________|

foonas-em for lsmipsel - http://foonas.org

lsmipsel login: root
Password:
foonas-em$ uname -a
Linux lsmipsel 2.6.30.5 #1 Wed Sep 2 17:19:23 CDT 2009 mips unknown
foonas-em$ ping yahoo.com         
PING yahoo.com (209.131.36.159): 56 data bytes
64 bytes from 209.131.36.159: seq=0 ttl=55 time=78.938 ms
64 bytes from 209.131.36.159: seq=1 ttl=55 time=78.091 ms
64 bytes from 209.131.36.159: seq=2 ttl=55 time=78.610 ms
64 bytes from 209.131.36.159: seq=3 ttl=55 time=78.190 ms
64 bytes from 209.131.36.159: seq=4 ttl=55 time=78.462 ms
^C
--- yahoo.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 78.091/78.458/78.938 ms
foonas-em$ wget http://downloads.buffalo.nas-central.org/Users/davy_gravy/lsmipsel%20images/lsmipsel-lenny-v4.tar.
gz
Connecting to downloads.buffalo.nas-central.org (140.211.169.172:80)
lsmipsel-lenny-v4.ta  72% |**********************************************                   | 52421k 00:00:42 ETA

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Thu Sep 03, 2009 7:09 am 
Offline
Newbie

Joined: Sun Aug 05, 2007 4:15 am
Posts: 36
Well, I haven't built gcc cross toolchain manually for a long time. The steps I remember are:

1. built target header
2. built cross binutil
3. built bootstrap cross gcc
4. buiilt target glibc
5. built cross gcc

My understanding is that gcc needs the target glibc for building application that uses the standard libraries but doesn't use these target libraries itself. I'm not an export on building cross toolchain. Nowadays, I use crosstools NG or crosstools to build cross toolchains if I need to. :-) Whenever I encountered toolchain problems, the only thing I could do is trial and error until I found a binutil/glibc/gcc combination that works. :-(

Your configuration looks fine to me.


Top
   
PostPosted: Thu Sep 03, 2009 11:36 am 
Offline
Betatester
User avatar

Joined: Thu Jul 14, 2005 4:38 pm
Posts: 941
Location: England
davy_gravy, just flashed it in and seems fine :)

Early days, obviously, but are you going to make it compatible with the webui. i.e at the moment it says it is an old version, and won't allow to access the installer side of things. It'd be good if you also tell it to pull in your latest Lenny image, would it make installing openlink from there problematic?

shihsung, is it possible to create with 4 partitions as in previous kernel (from LNI's patch):

+ * We create 4 partitions
+ * 0: bootloader (0x00000000 - 0x0003FFFF) size 0x040000
+ * 1: kernel+ramdisk (0x00040000 - 0x0038FFFF) size 0x350000
+ * 2: configuration area (0x003C0000 - 0x003FFFFF) size 0x040000
+ * 3: all chip (0x00000000 - 0x003FFFFF) size 0x400000


Top
   
PostPosted: Thu Sep 03, 2009 10:54 pm 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
Bauldrick wrote:
davy_gravy, just flashed it in and seems fine :)

Early days, obviously, but are you going to make it compatible with the webui.

1. i.e at the moment it says it is an old version, and won't allow to access the installer side of things.

2. It'd be good if you also tell it to pull in your latest Lenny image, would it make installing openlink from there problematic?

3. shihsung, is it possible to create with 4 partitions as in previous kernel (from LNI's patch):

+ * We create 4 partitions
+ * 0: bootloader (0x00000000 - 0x0003FFFF) size 0x040000
+ * 1: kernel+ramdisk (0x00040000 - 0x0038FFFF) size 0x350000
+ * 2: configuration area (0x003C0000 - 0x003FFFFF) size 0x040000
+ * 3: all chip (0x00000000 - 0x003FFFFF) size 0x400000


1. well, the "old" thing is, I think, just because timtim is about to recycle and move towards a revision of foonas-em. the rootfs is built from what is currently in git, ... the latest source.

2. I'll suggest that, both things, though I'm not sure how well OpenLink would work with a 2.6 kernel. There might be some incompatiblities between the 2.6 and OpenLInk's expectation of a 2.4. Not sure on this.

3. I agree, that would be nice.

Honestly, the only thing I see left is mtd write access (so that we can flash foonas-em into ROM, for instance).

:) awesome work, shihsung...

=========================================

Eureka! I don't know for sure who the culprit was, but upgrading gcc and uclibc has resulted in a bootable kernel when made from the foonas-OE-ish toolchain. Will try again w/ just uclibc upgraded, since the gcc upgrade seems more likely to have to killed the last step of the initramfs run ... so I only got the bare kernel, no cpio-rolled rootfs tucked inside it...

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Mon Sep 07, 2009 7:24 pm 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
I've updated the kernel package - you can untar this at / and then run depmod -a at /lib/modules/2.6.30.5/ and you should be good to go. The (stupid) Android Memory Killer (that I mistakenly enabled) is off now, and just 2 of the staging drivers (USB IP and Realtek driver) are on from that group. This kernel now has support for just about everything one could possibly use on the LS2.

Network transfer speed tests/numbers would be appreciated.

lsmipsel-kernelupgrade2.6.30.5v2.tar.gz
Also, the unofficial foonas-em image that I rolled up has been successfully flashed into the "unflashable" ST Micro chip. It is now tested in both the Macronix and ST Micro ROM chips, and seems to function just as it should, with built-in support for ext2-4 & tune2fs, and fw_[set,print]env is fixed.
vmlinuz.gz-ext4_tune2fs_fw-setwrite

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Wed Sep 09, 2009 5:57 am 
Offline
Newbie

Joined: Sun Aug 05, 2007 4:15 am
Posts: 36
Quote:
+ * We create 4 partitions
+ * 0: bootloader (0x00000000 - 0x0003FFFF) size 0x040000
+ * 1: kernel+ramdisk (0x00040000 - 0x0038FFFF) size 0x350000
+ * 2: configuration area (0x003C0000 - 0x003FFFFF) size 0x040000
+ * 3: all chip (0x00000000 - 0x003FFFFF) size 0x400000


MTD is supported already. To create the above partitions, just add the following to the kernel command line:

mtdparts=physmap-flash.0:0x40000(u-boot),0x350000(kernel),0x40000@0x3c0000(config),0x400000@0(all)

Then, make sure the corresponding device nodes exist.

Quote:
90 char Memory Technology Device (RAM, ROM, Flash)
0 = /dev/mtd0 First MTD (rw)
1 = /dev/mtdr0 First MTD (ro)
...
30 = /dev/mtd15 16th MTD (rw)
31 = /dev/mtdr15 16th MTD (ro)


Top
   
PostPosted: Wed Sep 09, 2009 12:26 pm 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
shihsung wrote:

MTD is supported already. To create the above partitions, just add the following to the kernel command line:

mtdparts=physmap-flash.0:0x40000(u-boot),0x350000(kernel),0x40000@0x3c0000(config),0x400000@0(all)

...

thanks shihsung... I had suspected as much, but had never used those command options...

...I had spoken with lyakh (who moved the PPC LinkStation kernels into vanilla/mainline), and he explained to me (to which I expressed my surprise - I hadn't realized this was now more common) that partitions are now more commonly defined only @ the command line.

It looks like you've anticipated yet another question from us, shihsung, and you already had it answered before we asked you. ;)

@Bauldrick: maybe we can just define mtdparts in uboot env vars and pass it that way - it would require just a tweak to the already-present bootcmds.

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Fri Sep 11, 2009 3:26 am 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
hmm... tried 2.6.31 ... everything is fine except for the rtc ...

lsmipsel:~# dmesg | grep rtc0
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)


I didn't see any pertinent changes in the the log for 2.6.31 at kernelnewbies.org... ?

I missed something?

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 120 posts ]  Go to page Previous 14 5 6 7 8 Next

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited