Building the custom firmware

[joao]

Oleg, could you please explain how have you found those magic numbers that you use as arguments for 'dd'?
When I do a
hexdump -C wg01060503_WL500g_en.trx | grep Compressed
I get
000ac310 00 00 00 00 43 6f 6d 70 72 65 73 73 65 64 20 52 |....Compressed R|
000ac330 3e af a7 ef 43 6f 6d 70 72 65 73 73 65 64 00 00 |>¯§ïCompressed..|

But AC310 is 705296, so where does your 705256 comes from?
And how did you found the length of the header (28) and trailer (3324)?

And to build busybox did you have to set up a cross-compiler?

Congratulations for your work.

[Technik]

Oleg, Antiloop, thanks a lot for the WL-500b patch update! Now it works fine.

[Antiloop]

Originally posted by Technik
Oleg, Antiloop, thanks a lot for the WL-500b patch update! Now it works fine.

all credits should go to Oleg, not me

[Oleg]

Originally posted by joao
Oleg, could you please explain how have you found those magic numbers that you use as arguments for 'dd'?
When I do a
hexdump -C wg01060503_WL500g_en.trx | grep Compressed
I get
000ac310 00 00 00 00 43 6f 6d 70 72 65 73 73 65 64 20 52 |....Compressed R|
000ac330 3e af a7 ef 43 6f 6d 70 72 65 73 73 65 64 00 00 |>¯§ïCompressed..|

But AC310 is 705296, so where does your 705256 comes from?
And how did you found the length of the header (28) and trailer (3324)?

And to build busybox did you have to set up a cross-compiler?

Congratulations for your work.

Yes, you will need to setup the crosscompiler. The simplest way to get it - is just to download the wrt54g sources from the linksys site.
Regarding the starting offsets - they are all encoded in the trx header (it's 28 bytes in size as you mention), and defined as follows (btw, old trx header have offsets set to zero, so the right offsets was 0x1c & 0xc0000):

typedef struct {
uint32 magic; /* "HDR0" */
uint32 len; /* Length of file including header */
uint32 crc32; /* 32-bit CRC from flag_version to end of file */
uint32 flag_version; /* 0:15 flags, 16:31 version */
uint32 offsets[3]; /* Offsets of partitions from start of header */
} TRXHDR, *PTRXHDR;

705256 - is the real offset to cramfs image, 0xac310 just an offset inside the cramfs header (consult linux kernel sources) for detail.

As for trailer length - it's just a guess. To find it I've packed the rootfs using the mkcramfs and when found the difference (possibly trailer length depends on the size of kernel, to align the entire trx size to 4k boundary, cause the cramfs 4k aligned by it's self). Also, please note - old asus firmwares has 64 bytes trailer...

[Technik]

Originally posted by Antiloop
all credits should go to Oleg, not me

I know but you posted a link to updated file.
BTW I think Oleg could take a control of WL-500b/g updates over ASUS yet!

[zomk3]

Originally posted by Oleg
Michael, I've not rebuild kernel, I've used the kernel & the modules supplied by ASUS. WRT54G kernel & modules can't be used directly - they have different ethernet interfaces, led drivers and possibly more. The closest kernel should be from the wap54 & wrt55. Asus also has the modules, which we can't recompile using the Linksys sources - the things related to parallel port (parport_splink), splink_led (it's pretty simple). And the main problem is the debugging of the newely build kernel.

BTW, I'm was able to build some modules to use with existing kernel using the wrt54g config (I've added the ext2, loop, nfs and the friends). I'm was able to mount nfs share.

I just looked in some of the kernel sources and some kernel boot outputs of the Linksys and the Asus Router.
The usb port is supported by the linksys modified kernel and they use the usb-ohci module for it..
The Ethernet ports are part of the broadcom chip, so they are also supported by the linksys sources.
Also broadcom only provides the binary kernel modules which should be ok. We can use those binary modules also in custom firmwares.
What is different is that Asus uses a other switch chip than linksys but this doesn't care, its outside of the linux stuff.
The Prt port is an Attansic at7601F, which they claim as IBM PC Compatible Printer Port (see http://www.attansic.com.tw/english/p...df/at7601f.pdf ).
So it should run with the standard parport module.

One of the things we need to find out to be able to compile the kernel correct is what modules are enabled in the ASUS kernel, Antiloop has posted this already. There we will get the messages which drivers were loaded. I will take a more detailed look myself, but my delivered WL500 was broken and i had to send it back.
I hope my replacement will be delivered soon.

As i said already Antiloop has posted the dmesg of the asus router in the openwrt thread, so we can see the the most of the modules the router uses.

What do you guys think of setting up a own Project on sourceforge ? We could use the provided cvs for storage of files and having a bugtracking aso. ?
We could also join Kaloz project in adopting the openwrt to the WL500.

I agree with you regarding the debug problem. But how do you debug a broken linux kernel on your pc ? Are you a real kernel hacker, i must admit that i can not do this. I can just try the things i compiled in and use them. If an error occures i just can upload a old working kernel.

[Antiloop]

Originally posted by zomk3

What do you guys think of setting up a own Project on sourceforge ? We could use the provided cvs for storage of files and having a bugtracking aso. ?
We could also join Kaloz project in adopting the openwrt to the WL500.

I agree with you regarding the debug problem. But how do you debug a broken linux kernel on your pc ? Are you a real kernel hacker, i must admit that i can not do this. I can just try the things i compiled in and use them. If an error occures i just can upload a old working kernel.

if in need of space chupa.nl has enough for now,

if you want to share bigger files send them through email to forum@chupa.nl, and i'll upload them at the site

i'm planning to create a upload page soon, so it can be uploaded to the site directly.

[zomk3]

Originally posted by Antiloop
if in need of space chupa.nl has enough for now,

if you want to share bigger files send them through email to forum@chupa.nl, and i'll upload them at the site

i'm planning to create a upload page soon, so it can be uploaded to the site directly.

I am not talking of binary files, i was thinking of the sources. cvs is a very usable tool for this. But if you'd like to set up a cvs or similar system ond chupa.nl that would be great. But think of maintenance and all the administrative stuff.

[Oleg]

Originally posted by zomk3
The Ethernet ports are part of the broadcom chip, so they are also supported by the linksys sources.

....
So it should run with the standard parport module.

Once again, linksys (cybertan) wrt54g use different approach for the eth interfaces: they're using one physical ethernet port for both lan & wan and then drive two different connectors using the vlan tagging & built it switch chip. wl500g and all other similar things from dell, trendnet, buffalo and linksys wrt55 uses 2 physical enternet ports (this is reference design). BTW, there is not a big deal for compiling the kernel, which properly support ethernet ports (one of the linksys packages has original sources from broadcom with no vlan tagging dano by cybertan). But do you really need this new kernel right now? If you need additional features - compile these as modules.
As for parport - there are two modules loaded - parport & parport_splink, which uses parport. Don't know what parport_splink doing...
This is suffucient to start digging, but do we really need jffs on the flash? It's more resonable to use external USB disk for the purpose, saving the flash... WRT54G does not have usb port, so they decided to make the jffs partion.

[Oleg]

As for debuging - I think it's possible to code the loader which will run just from the telnet shell and will boot the new kernel from the usb disk or so. No need to flash the firmware until it's fully debugged.
Just a thought: as an output solution - just use the parallel printer port for the console output , and it's also possible to use the parallel port as i/o port right in the windows (just how null modem does).

[Ark+]

Since we now have both ftp to upload files and telnet to control the router, why not install a full development environment on the USB disk ?

We have to install gcc and then use the wl-500g to compile its new binaries, and gdb to debug them.
First, it will avoid cross-compilers...
Second, we shall share the same environment.

Another wish will be to install traffic control (tc) or iproute2 on the wl-500g in order to add QoS functionality.

[zomk3]

Originally posted by Oleg
As for debuging - I think it's possible to code the loader which will run just from the telnet shell and will boot the new kernel from the usb disk or so. No need to flash the firmware until it's fully debugged.
Just a thought: as an output solution - just use the parallel printer port for the console output , and it's also possible to use the parallel port as i/o port right in the windows (just how null modem does).

Just as an idea. Isn't there a diagonistic port on the side of the board ? I think i have seen something like this on the pictures.
But then we would need to open the device and loose the guarantee. A parallel port diagnostic wouldn't be too bad. The usb disk as storage is a very good idea. Independant of the size its easier to replace it after too many writes to the flash.

[zomk3]

Originally posted by Ark+
Since we now have both ftp to upload files and telnet to control the router, why not install a full development environment on the USB disk ?

We have to install gcc and then use the wl-500g to compile its new binaries, and gdb to debug them.
First, it will avoid cross-compilers...
Second, we shall share the same environment.

Another wish will be to install traffic control (tc) or iproute2 on the wl-500g in order to add QoS functionality.

Do you think its a good idea to compile something like the kernel on a 125Mhz Box with only 16M RAM?

Regarding the Environment i already mentioned to use something like sourceforge, so everybody can use cvs to share their sources. More important a diff/merge functionality is provided in many clients.

If we use the memory stick to store our extra software on it, we can easily compile it on linux and upload it. Very important is to use the same guidlines (e.g for directories, config files...)

[joao]

Do you think its a good idea to compile something like the kernel on a 125Mhz Box with only 16M RAM?

Compiling a kernel on the wl-500g might cause overheating
And there is also the Broadcom binary modules issue. Aren't they compiled for that specific kernel version (2.4.5)? Is there a way to make them work with a higher kernel version? What do you think Oleg?

[Oleg]

Originally posted by joao
And there is also the Broadcom binary modules issue. Aren't they compiled for that specific kernel version (2.4.5)? Is there a way to make them work with a higher kernel version? What do you think Oleg?

Asus firmware uses the 2.4.20 kernel with broadcom modules compiled for 2.4.20. There are also some modules compiled for 2.4.5 by Asus itself - so they are using a mix. They are to lazy to recompile everything. As for using with newer kernels - seems any kernel from the 2.4.x (x >= 20) can be used safely (we just need to make a patch from against the stock 2.4.20) and also we can recompile most of the parts (except the wireless stuff, which can be safely taken as is from linksys sources). As for wireless, can't recall exactly, broadcom uses open source compatibilty layer for their drivers (they are layed out as a set of compiled .o files) and links it to the final module.
As for connecting to the diagnostic port - yes it's possible, but there are no info on the port itself. Possibly it's JTAG, but who knows...