I have a WL-520GU with a Broadcom BCM5354 SoC. Using Kamikaze_8.09_rc1 I can successfully boot using brcm-2.4.

However when I try to boot using the 2.6 kernel (brcm47xx) I get :

Loader:raw Filesys:raw Dev:flash0.os File: Options:(null)
Loading: .. 3760 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000

and then it hangs.

If I gzip the 2.6 kernel, attach the squashfs and put the TRX headers on and load this, 2.6 works. This suggests the kernel is fine. (It works quite well, except for the size constraint)

This suggests it has something to do with the lzma-loader. I notice slight differences in the file size of lzma-loader for the 2.4 and 2.6. I've done a diff on both lzma-loaders for 2.4 and 2.6 and at a source level they appear to be identical. I suspected it could be a byte-alignment issue, but the flags used to compile each version is the same, so I can only assume a library is different (unless I have missed something).

Before I dig further into this, does anyone have the same problem or better still a solution?

Actually I see there is a patch in the trunk to fix CFE detection. Just giving it a go now, but I suspect this should be the fix I'm after.

Hi. Just want to know if you've got it work or not...? I tried using the 2.6 on a WBR2-G54 but it doesn't boot as well. The 2.4 kernel works through.

BTW, how you got the logs and knew where the kernel is struck...? Is it via JTAG or something else?

Thanks in advance!

I have a serial cable connected to mine to get the console messages. I would love JTAG, but my $52 el cheapo "development" board doesn't have JTAG broken out

I was successful in getting RC1 to work - The 800-fix_cfe_detection.patch adds a patch to target/linux/brcm47xx/patches-2.6.25/ which in turns patches arch/mips/bcm47xx/prom.c during build time, or at least that is the plan. I noticed the 2nd patch during build time didn't apply properly, so I applied it by hand.

Initially I gave up on RC1 and moved straight across to the trunk which already had the fix. I'm now running R13191 but I notice that doesn't work either. Looking at prom.c, it also appears to be broken but there is no reject file left behind as evidence. I've let to sit down and work out what is going wrong with the patch in the trunk.

Now off to look at the b43 wireless driver on RC1 . . .

Guess I'll wait for RC2 then... Thanks alot! : )

Glad someone else is working on getting 8.09 working on a wl-520gu.

Could you explain how you adapted the patch?  So far I haven't been able to get it to boot until I uncomment these lines in arch/mips/bcm47xx/prom.c:

void __init prom_init(void)
{
        if (prom_init_cfe() == 0) {
                //prom_init_console_cfe();
                //prom_init_cmdline_cfe();
                __prom_putchar = prom_putchar_cfe;
        }

        prom_init_mem();
}

And of course, once it does come up, it immediately reboots when trying to load the b43 driver

br-lan: port 1(eth0.0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 1(eth0.0) entering forwarding state
b43-phy0: Broadcom 5354 WLAN found
Decompressing..........done


CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: Mon Apr 16 14:41:05 CST 2007 (root@localhost.localdomain)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.

I found that the patch didn't apply properly, so I just manually patched my prom.c. What I'll do shortly is do a diff and post a patch that is likely to apply better.

I still don't believe the patch provided is perfect. I notice on a 2.6 kernel (when it works) I get the version/gcc info, followed by SSB info. e.g.

Loading: ........ 2482299 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000
Linux version 2.6.25.17 (cpeacock@max.beyondlogic.org) (gcc version 4.1.2) #1 Tue Nov 11 21:24:25 EST 2008
console [early0] enabled
CPU revision is: 00029029 (Broadcom BCM3302)
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x14, vendor 0x4243)
ssb: Core 1 found: Fast Ethernet (cc 0x806, rev 0x09, vendor 0x4243)
ssb: Core 2 found: MIPS 3302 (cc 0x816, rev 0x08, vendor 0x4243)
ssb: Core 3 found: USB 2.0 Host (cc 0x819, rev 0x02, vendor 0x4243)
ssb: Core 4 found: MEMC SDRAM (cc 0x80F, rev 0x04, vendor 0x4243)
ssb: Core 5 found: IEEE 802.11 (cc 0x812, rev 0x0D, vendor 0x4243)
ssb: Core 6 found: Roboswitch (cc 0x81C, rev 0x02, vendor 0x4243)
ssb: Initializing MIPS core...
ssb: set_irq: core 0x0806, irq 2 => 2
ssb: set_irq: core 0x0819, irq 4 => 3
ssb: set_irq: core 0x0812, irq 0 => 4
ssb: Sonics Silicon Backplane found at address 0x18000000
Serial init done.
Determined physical RAM map:
 memory: 01000000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
  Normal          0 ->     4096
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->     4096
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4064
Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,jffs2 init=/etc/preinit noinitrd console=ttyS0,115200
Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 bytes
Synthesized clear page handler (26 instructions).
Synthesized copy page handler (46 instructions).
PID hash table entries: 64 (order: 6, 256 bytes)
console handover: boot [early0] -> real [ttyS0]
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 13668k/16384k available (1995k kernel code, 2716k reserved, 302k data, 128k init, 0k highmem)
Mount-cache hash table entries: 512

This appears to be something to do with an early console. Now with the patched prom.c all I get is :

Loading: .. 3768 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 13668k/16384k available (1995k kernel code, 2716k reserved, 302k data, 128k init, 0k )
Mount-cache hash table entries: 512

I'm just working on this now. It appears the device reboots when it calls b43_write16(0x80829000, 0x03e6, 0x0000) as part of the b43_switch_analog() function in main.c

I also see USB is not working. If I load either EHCI or OHCI, I get zip activity on the USBus (checked with a protocol analyser)  and hence it never finds any USB devices. That might be next weekend's task

Isn't the USB problem solved by the patch described here http://wiki.openwrt.org/OpenWrtDocs/Har … /WL500GPV2 (see section Patching Kamikaze to Work With the BCM5354) :
an available here:  https://dev.openwrt.org/cgi-bin/trac.fc … i-25.patch ?
I had a problem with my BCM5354 based Asus WL500gP V2, and this patch has solved it...

(Last edited by wzab on 17 Nov 2008, 09:19)

Cool, thanks for that wzab.

Jim, how reliable have you found booting is after commenting out functions prom_init_console_cfe(); & prom_init_cmdline_cfe(); ?

I applied the same changes to RC1 - prom.c than was in the trunk. As I mentioned a couple of nights ago, I could get RC1 working, but not the trunk. I just recorded this as an observation and pushed on. At the time I had compared the changes between RC1 and the trunk and they were identical.

Last night I applied the USB patches as pointed out by wzab. After I did this, my kernel would no longer boot with the same behavior than before - it hangs immediately after Starting program at 0x80001000. I removed all the USB modules, but could not successfully get the kernel to load again.

I then decided to push that build aside and grab a fresh RC1 and start again. I applied the CFE/prom.c patch as before but this time it wouldn't work either.  Following some of Mr S Brown's work, I commented out what you had done Jim, and it still wouldn't work. S Brown had also commented out setup_early_printk(); in /arch/mips/kernel/setup.c so I tried this and bingo - it worked.

However when I applied the USB patches, I broke it again

So I have come to the conclusion the CFE detection is still flaky at best and I need to learn to walk before I can run. I'm going to concentrate on this area first and see if I can get a robust solution.

Hi, MrBroadcom.

You are tracking down the issue we also met.
http://forum.openwrt.org/viewtopic.php?pid=76848#p76848

Anything in advance?

regards,
zukky

HI every best man -_- can you give me you are success booting rom for me -_- I'm trying to do wiht this machine at all  -_-