Alright, good news, and also, a lot of it.
First off, I would like to extend a lot of thanks to Lennert Buytenhek. He worked with me and Dirk for hours to get the WRT350n working. What marvellous support from Marvell! 
With a lot of help from Lennert, we have been able to get, well, everything working on the WRT350n. I currently have 2.6.26-rc4 running on it. We think it's ready to run openwrt, as soon as we figure out how create an image that can be flashed via the standard interface.
According to Lennert, the work he did to create a working wrt350n_setup.c, will be included in the next major mainline kernel, probably 2.6.27. Until then, you will need to get the kernel from the marvell GIT repository. This is of course very good news, because for a large part the wrt350n will work out of the box with a generic kernel in the not too distant future!
What works: Almost everything, it seems. LAN, WiFi, USB, writing new rootfs/kernel to flash, booting from Squash-LZMA filesystem in flash. Also Lennert has mapped the GPIO's (leds and buttons) for future use.
What doesn't: n-mode for WiFi, booting the SquashFS-LZMA rootfs that normally comes with the wrt350n, because SquashFS 3.3 seems to be backwards incompatible with 3.0, which is what was used to create the stock rootfs. Since the rootfs can easily be overwritten, this doesn't really matter.
First I'll just sum up the steps that were taken to get everything work, then I'll elaborate on the important ones more in-depth.
1. Get the latest GIT checkout from the marvell GIT repository
2. Download patch for cfi_cmdset_0002.c and apply it to the kernel
3. Patch 2.6.26-rc4 to have SquashFS-LZMA (needs patching to make it 2.6.26 compatible)
4. Build the kernel
5. Get the latest madwifi, point it to the new kernel and build it (needs a few patches as well)
6. Patch the zImage with the correct machine type id and build the uImage
7. Boot the uImage through the Marvell bootloader.
8. Load the madwifi modules
Now for the more detailed explanations:
The cfi_cmdset_0002.c patch
Somewhere along the line between 2.6.12 (linksys sources) and now, a check was added for the version of the CFI chip. This check enforces that the version can only be between 1.0 and 1.4. This presents a problem, because the WRT350N reports version 0.0. This patch modifies the check to allow 0.0 as well as 1.0 to 1.4. With this patch applied, the flash can be mapped just fine.
Patching 2.6.26-rc4 with SquashFS-LZMA
Patching a kernel newer than 2.6.24.3 presents a problem, because there are only patches up to this version as of the time of writing. 2.6.25 and later need you to manually patch the kernel. I will outline this process here. When SquashFS-LZMA gets ported to the newer kernel by the author, this section will be obsoleted.
Following the instructions at http://www.squashfs-lzma.org/, get all the files in the menu on the left (except for the kernel, obviously). Note: I didn't apply the 'cvsfix' patches.
Then follow the guide here: http://www.squashfs-lzma.org/dl/sqlzma.txt.
Note: use the 2.6.24 patch to patch the kernel
Note 2: you don't need to do the Makefile stuff or actually run make
Now do the following things:
1. From where you unpacked sqlzmaXXX-XXX.tar.bz2, copy sqlzma.h to <kernelsrc>/fs/squashfs
2. From where you unpacked sqlzmaXXX-XXX.tar.bz2, copy sqmagic.h to <kernelsrc>/fs/squashfs
3. From where you unpacked lzmaXXX.tar.bz2, copy C/Compress/LZMA/uncomp.c to <kernelsrc>/fs/squashfs
4. From where you unpacked lzmaXXX.tar.bz2, copy C/Compress/LZMA/LzmaDecode.c to <kernelsrc>/fs/squashfs
5. From where you unpacked lzmaXXX.tar.bz2, copy C/Compress/LZMA/LzmaDecode.h to <kernelsrc>/fs/squashfs
6. From where you unpacked lzmaXXX.tar.bz2, copy C/Compress/LZMA/LzmaTypes.h to <kernelsrc>/fs/squashfs
7. From where you unpacked lzmaXXX.tar.bz2, copy C/Compress/LZMA/kmod/module.c to <kernelsrc>/fs/squashfs
8. Apply this patch to <kernelsrc>/fs/squashfs/inode.c
9. Apply this patch to <kernelsrc>/fs/squashfs/Makefile
10. Edit <kernelsrc>/fs/squashfs/module.c, change "#include "../LzmaDecode.c" to "#include "LzmaDecode.c"
Now enable SquashFS in the kernel (file systems, miscellaneous, squashfs, builtin). Now the kernel has SquashFS-LZMA support.
Compiling madwifi modules
Get the latest madwifi SVN version from http://svn.madwifi.org/madwifi/trunk. To build madwifi, I had to apply some hacks to the source. Your mileage may vary. Anyway, this is what I did. Since this is SVN, there's probably not a lot of use in creating patches for it, so I'll just walk through it step by step.
NOTE! For compiling this, I used this toolchain. I used a newer one for the kernel but that one completely failed to compile madwifi.
1. From where you checked out madwifi, edit hal/public/armv4-le-elf.inc. All the way at the bottom, where it says "COPTS+= -march=armv4 -mlittle-endian \", change this to "COPTS+= -march=armv5te -mlittle-endian \"
2. Try to compile madwifi, it may just work. If you get errors about functions iowrite32be/ioread32be like I did, continue.
3. From where you checked out madwifi, edit ath_hal/ah_os.h.
4. Find the comment about "The register accesses are done using target-specific" (for me, line 195).
5. Go down a bit to where it says the following:
#define _OS_REG_WRITE(_ah, _reg, _val) do { \
is_reg_le(_reg) ? \
iowrite32((_val), (_ah)->ah_sh + (_reg)) : \
iowrite32be((_val), (_ah)->ah_sh + (_reg)); \
} while (0)
6. Change this to/replace this with:
#define _OS_REG_WRITE(_ah, _reg, _val) do { \
iowrite32((_val), (_ah)->ah_sh + (_reg)); \
} while (0)
7. Right below that, there should be this:
#define _OS_REG_READ(_ah, _reg) \
(is_reg_le(_reg) ? \
ioread32((_ah)->ah_sh + (_reg)) : \
ioread32be((_ah)->ah_sh + (_reg)))
8. Change this to/replace this with:
#define _OS_REG_READ(_ah, _reg) \
ioread32((_ah)->ah_sh + (_reg))
9. Now compile madwifi. It should now work.
10. Install the modules somewhere where your WRT350N will be able to access them (in your rootfs, /lib/modules somewhere).
Patching the zImage with the correct machine type id
You can either do this manually every time you build a kernel or have it be done for you. I'm going to assume you prefer the latter.
Apply this patch to your kernel. This changes the arch/arm/boot/Makefile so it puts the machine id in the zImage before it creates the uImage. Many thanks to mindbender and Lennert for this one.
These are, I think, all the steps needed to create an image with the very latest kernel that will boot on wrt350n. You will have support for everything. Just for the sake of completeness, I will include here the config that was used build a working kernel after these steps.
What's left to do?
The next thing will be to figure out how to create an image which can be used to flash a new firmware to the wrt350n without needing the serial console.
(Last edited by StrikerNL on 31 May 2008, 17:08)
, marvell is to blame for that)....can you please post the console output?