Ok, we've got some new stuff for you guys to play with -

Features:
· new buildroot (much cleaner sources)
· new kernel (2.4.29 - thx wbx)
· based on the 3.37 firmware (that means v2.2 support)
· support for jffs2 only layout (vs squashfs + jffs2 overlay)
· much more ...

DOWNLOAD:
http://openwrt.org/downloads/experimental/

NOTE:
The experimental stuff is just that, experimental. This is NOT a release canidate, it's simply a demo of some things we're working on.

If you get a 'disk full' error after loading, REBOOT.

Cool.  I like this flatter and consistently formed directory structure.  It's going to be a lot easier to add the stuff involving kernel patching with the 2.4.29 kernel...  Nice work.

That release has made me to drop some tears... AMAZING

Compiling it right now...let you know this afternoon how it went on a v1.1 or a v1.0

Very nice, guys. I just *have* to tinker with this.

The downside is that it's likely that some packages need to be rebuild :-/

On a side note, are there any (documented)differences in this firmware which are of importance to package builders?

the experimentell release is for testing the base system.
(kernel 2.4.29, jffs2 root, squashfs-lzma-root, buildsystem,
new hardware support)

There are plans to change the menu for the packages, to
tristate (embed, ipkg, no build).

But I think nbd or nico can tell more about this.

This looks really nice. I have some questions though.

There are multiple options for binutils. Why is this? What is the recommended version and why would I want to use another one?

Also, can you give an idea about the size/speed difference of squashfd-lzma? Is it really much better than the zlib based one?

S.

will it make it's way back to cvs?

Size:
squashfs:
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.2M      1.2M         0 100% /

squashfs-lzma:
Filesystem                Size      Used Available Use% Mounted on
/dev/root               960.0k    960.0k         0 100% /

Tell me something about the speed, when you use it :}

I just want to say thank you!

I have been looking for a way to reliably integrate the newer drivers into OpenWRT and this is amazing.  I get a menu to config what i want made, type make and even use a script to upload the firmware.

This is a HUGE step to making all this more "user friendly"  I am just amazed!

I look forward to testing this this weekend...

Mmm, my v1.1 does not run yet... will check why...

(default options used -ie gcc 3.3.5 & binutils 2.14.90)

Speaking of compression, is there a good reason why it's still using gzip'ed kernel (vmlinuz) as opposed to bzip2'ed one (bzImage) out-of-the-box?

Also, is lzma'ed kernel loader coming around?  Lzma'ed kernel should give us at least 2 blocks (128KB) of freespace, may be 3 depending on the kernel+rootfs size.  (I was thinking of doing it myself for fun, but I guess someone's working on it, right?)

The saving you'll get with bzip2'd kernel is less than one mtd block, so there's no guaranteed freespace increase, but you might get a precious 64KB if you are lucky.

Under the legacy fs configuration (squashfs(-lzma)+jffs2), the kernel no longer looks at the squashfs header, which avoids this problem, however, you might be wasting 64KB freespece because of double padding done by mksquashfs and trx, again, depending on you kernel+rootfs size.  I initially fixed the checksum error in the same ways as this new buildroot, but I didn't like it because I actually was wasting a block.

Well, this will become a moot point once someone adds LZMA compression to jffs2, though.

Yes, that and the fact that those nasty recursive includes get removed will make customizing and building OpenWrt a lot easier.
When it's included, I will write some docs on how you can easily port over your old packages.

Did you built it with dropbear enabled?  I'm seeing the initial dropbear config getting stuck while it's generating the keys.  I haven't had a chance to verify this yet, but my first guess is a /dev/random entropy stuff. (change it to /dev/urandom in option.h)

I also saw bunch of "nvram (utility) not found" errors along with failures to start up the network interfaces with legacy (ro+rw) rootfs config.

Anyway, it's fun for the weekend.

Addressing mtakahar's laundry list of complaints -

This is an experimental build, not a release. There are things that are broken and there are things that aren't implemented yet.

bzImage does not stand for "bzipped image", it stands for "big zImage"

We added bzip2 support to our kernels a long time ago, yes bzip2 save space, unfortunately almost all the space gained is lost in the bzip2 decompression utility needed to actually boot the kernel.

An lzma kernel loader is being investigated but wasn't included in this release.

I'll look into the legacy filesystem block allocation later, but it seems like you're fixing  symptoms and not the problem. The trx utility pads the firmware size to be a multiple of 4096, if what you're saying is true then the trx padding is not needed or is calculated incorrectly, not an issue with the partition layout in the kernel.

Funny, bricked a v1.0 too

Has anybody else tried this experimental build on a v1.x successfully?

Sorry about my bad English if it sounded that way.  No intention of offense or complaints at all.

Yes, I am fully aware of that.  I'll just shut up if you guys didn't want to hear this kind of feedback/comments.

That's not what I meant...  I just brought up these names because these are the actual files created using gzip and bzip2.  The one built with gzip is used and the other one is just sitting there unused.

I asked because I just couldn't find any mentioning of it coming in this forum or in the tarball.

Well, I had already verified the padding behavior of mksquasfs and trx before posting the patch.  It wasn't cause of the problem.
mksquash pads the image using the beginning of the squashfs itself as the starting point, which is not guaranteed to be aligned on the 4k boundary because trx just doesn't do it.  It aligns beginning of the squashfs image on 4 byte boundary instead.

Hi!

I've tried to flash my wrt54g v2.2 with this build - the device is not coming up and power-led is flashing!

Compiled everything with default-values ... so no idea what i'm doing wrong.

Somebody out there with more luck?

greetz
-k

Is there any condition that would make these new features official ? Is there a dead line to release an official including all these interesting features ?

Thanks for your huge work, it's getting really interesting to work with this new buildroot

That is not a really useful bug report.

Which kind of root-filesystem you use?
Can you ping the router? Did you try to boot failsafe?

I use the experimental stuff successful on three routers. wrt54gs v1.0, wrt54g v2.2 and asus wl-500g. See docs/hardware
for dmesg, /proc/cpuinfo and more.

Wbx,
I am trying to get the experimental version installed on a WRT54GS version 1.1.  Right now the unit will let me tftp new firmware with boot_wait on, but after the upload and reboot I cannot get any response from it (ping etc.). 

My next thought was to try failsafe which has saved me with previous upgrades, but when I boot the unit, I see the power LED flash during boot_wait, but the DMZ light is not turning on.  Did anything with failsafe change with experimental?

Should my step be to edit preinit and force failsafe?

BTW, I have tried both jffs2 root filesystem as well as  sqaushfs with the same results.

Any suggestions are appreciated.
Cletus

Hi!

I've tried severals ways to flash the firmware on different brand-new WRT54G v2.2 (original linksys-firmware on it - boot_wait activated) - with no success.

The power-led keeps flashing after transmitting the firmware via tftp! (Tried it with self-compiled firmware, with fixes from mbm and the provided bin-file!)

I really don't know what firmware should be used for these devices! Right now I made the best experiences with the freifunk-firmware - but with an activated pptp-dialin I get random reboots (never happend with v2.0-Devices).

I hope that won't be a hopeless case!

Any suggestions?

Thanks!

-k

Weird.

An older version of experimental works fine on one of my wrt54g v2.2. See the docs/hardware directory for dmesg.

Now I tried the binary's from mbm, the openwrt-gs-code.bin on my wrt54gs v1.0 works fine. The openwrt-g-code.bin on another wrt54g v2.2 has the same issues you mentioned.

AVOID openwrt-g-code.bin at the moment!!

I tracked down the issues that was keeping experimental from working on the wrt54g units; turns out that it's mostly my fault for overlooking a few details.

The jffs2 image needs to be setup differently depending on the flash chip used (specially the jffs2 block size needs to match the chip's erase size). I've patched buildroot and uploaded new snapshots which address the issue.

Please try the current images and post any complaints/criticism/etc ...

http://openwrt.org/downloads/experimental/

notes:

W54G - the wrt54g image (v1.0 - v2.2, probably v3.0)
W54S - the wrt54gs image (v1.0 - v1.1, probably v2.0)

You'll need a reboot before jffs2 will show the actual capacity

Since there is no squashfs partition, firstboot is not needed and should not be run.

Just tested the Motorola experimental bin on my Moto WR850G.  Booted okay, but the filesystem is read-only, no matter how many reboots I do.  Full log attached, starts after erasing the linux partition and rebooting.

EDIT: Seems the important error line is this:

mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only

EDIT-again: mbm got me all fixed up.  Everything works now!

Hi!

Ok, this time my wrt54g v2.2 is booting fine after flashing 

But ... if I try to load the mppe_mppc-kernel-module I get:

root@OpenWrt:/lib/modules/2.4.29# insmod ppp_mppe_mppc.o
Using ppp_mppe_mppc.o
insmod: unresolved symbol crypto_alloc_tfm
insmod: unresolved symbol crypto_free_tfm

Something wrong with the crypto-api? ... I think I saw a patch somewhere in the forum?

greetz
-k