Modify

Opened 9 years ago

Closed 7 years ago

#3177 closed defect (fixed)

No 128MB RAM support for brcm (brcm47xx)

Reported by: anonymous Owned by: hauke
Priority: normal Milestone:
Component: kernel Version:
Keywords: Ram Upgrade wl500gp 128MB Cc:

Description

I upgraded my Asus Wl-500gp to 128MB Ram.
With Oleg's firmware it starts without a problem.

CFE_Output_Oleg_128MB:

CFE version 1.0.37 for BCM947XX (32bit,SP,LE)                                             
Build Date: ¥| 10¤ë 12 22:21:19 CST 2006 (root@localhost.localdomain)                                                                     
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.                                                       

Initializing Arena                  
Initializing Devices.                     
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.7.0                                                              
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P)                                                  
CPU type 0x29006: 264MHz                        
Total memory: 134217728 KBytes                              

Total memory used by CFE:  0x80800000 - 0x8089AF40 (634688)                                                           
Initialized Data:          0x808313D0 - 0x80833790 (9152)                                                         
BSS Area:                  0x80833790 - 0x80834F40 (6064)                                                         
Local Heap:                0x80834F40 - 0x80898F40 (409600)                                                           
Stack Area:                0x80898F40 - 0x8089AF40 (8192)                                                         
Text (code) segment:       0x80800000 - 0x808313D0 (201680)                                                           
Boot area (physical):      0x0089B000 - 0x008DB000                                                  
Relocation Factor:         I:00000000 - D:00000000                                                  

Device eth0:  hwaddr 00-1B-FC-57-AB-6E, ipaddr 192.168.178.1, mask 255.255.255.0                                                                                

        gateway not set, nameserver not set                                           
Null Rescue Flag.                 
Loader:raw Filesys:raw Dev:flash0.o                                 
Loading: .. 3560 bytes read                           
Entry at 0x80001000                   
Closing network.                
Starting program at 0x80001000                              
cpu probe         
prom init         
cpu report          
CPU revision is: 00029006                         
Primary instruction cache 16kb, linesize 16 bytes (2 ways)                                                          
Primary data cache 16kb, linesize 16 bytes (2 ways)                                                   
Linux version 2.4.20 (root@omnibook) (gcc version 3.2.3 with Broadcom modificati                                                                                
ons) #75 Fri Apr 6 00:12:23 MSD 2007                                    
Setting the PFC value as 0x15                             
Determined physical RAM map:                            
 memory: 08000000 @ 00000000 (usable)                                     
On node 0 totalpages: 32768                           
zone(0): 3276            
zone(1): 0 pages.                 
zone(2): 0 pages.                 
Kernel command line: root=/dev/mtdblock2 noinitrd init=/linuxrc console=ttyS0,11                                                                                
5200    
CPU: BCM4704 rev 9 at 264 MHz                             
Calibrating delay loop... 263.78 BogoMIPS                                         
Memory: 127292k/131072k available (1799k kernel code, 3780k reserved, 248k data,                                                                                
 68k init, 0k highmem)                      
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)                                                               
Inode cache hash table entries: 8192 (order: 4, 65536 bytes)                                                            
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)                                                            
Buffer-cache hash table entries: 8                                
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)                                                             
Checking for 'wait' instruction...  unavailable.                                                
POSIX conformance testing by UNIFIX                                   
PCI: Fixing up bus 0                    
PCI: Fixing up bridge                     
PCI: Fixing up bus 1                    
Linux NET4.0 for Linux 2.4                          
Based upon Swansea University Computer Society NET3.039                                                       
Initializing RT netlink socket                              
Starting kswapd               
Journalled Block Device driver loaded                                     
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)                                                             
devfs: boot_options: 0x1                        
NTFS driver v1.1.22 [Flags: R/O]                                
pty: 256 Unix98 ptys                   
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI en                                                                                
abled     
ttyS00 at 0xb8000300 (irq = 3) is a 16550A                                          
ttyS01 at 0xb8000400 (irq = 3) is a 16550A                                          
HDLC line discipline: version $Revision$, maxframe=4096                                                       
N_HDLC line discipline registered.                                  
loop: loaded (max 8 devices)                            
PPP generic driver version 2.4.2                                
PPP Deflate Compression module registered                                         
PPP BSD Compression module registered                                     
MPPE/MPPC encryption/compression module registered                                                  
 Amd/Fujitsu Extended Query Table v1.3 at 0x0040                                                
 Flash Id: Vendor: 0x0001 Device: 0x007e                                        
number of CFI chips: 1                      
Flash device: 0x800000 at 0x1c000000                                    
Physically mapped flash: squashfs filesystem found at block 941                                                               
Creating 5 MTD partitions on "Physically mapped flash":                                                       
0x00000000-0x00040000 : "pmon"                              
0x00040000-0x007f0000 : "linux"                               
0x000eb714-0x007f0000 : "rootfs"                                
0x007f0000-0x00800000 : "nvram"                               
0x003e0000-0x007f0000 : "flashfs"                                 
sflash: found no supported devices                                  
NET4: Linux TCP/IP 1.0 for NET4.0                                 
IP Protocols: ICMP, UDP, TCP, IGMP                                  
IP: routing cache hash table of                               
TCP: Hash tables configured (established 8192 bind 16384)                                                         
Linux IP multicast router 0.06 plus PIM-SM                                          
ip_conntrack version 2.1 (1024 buckets, 8192 max) - 352 bytes per conntrack                                                                           
ip_conntrack_pptp version 1.9 loaded                                    
ip_nat_pptp version 1.5 loaded                              
ip_tables: (C) 2000-2002 Netfilter core team                                            
ipt_time loading                
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.                                                   
IPv6 v0.8 for NET4.0                    
IPv6 over IPv4 tunneling driver                               
NET4: Ethernet Bridge 008 for NET4.0                                    
802.1Q VLAN Support v1.7 Ben Greear <greearb@candelatech.com>                                                             
All bugs added by David S. Miller <davem@redhat.com>                                                    
FAT: bogus logical sector size 58624                                    
FAT: bogus logical sector size 58624                                    
NTFS: Unable to set blocksize 512.                                  
VFS: Mounted root (squashfs filesystem) readonly.                                                 
Mounted devfs on /dev                     
Freeing unused kernel memory: 68k freed                                       
Algorithmics/MIPS FPU Emulator v1.5                                   
eth0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.37.0                                                                
PCI: Enabling device 01:02.0 (0004 -> 0006)                                           
eth1: Broadcom BCM4318 802.11 Wireless Controller 3.90.38.0                                                           
vlan0: add 33:33:00:00:00:01 mcast addr                                     
vlan0: add 33:33:ff:57:ab:6e mcast address to master interface                                                              
vlan0: dev_set_promiscuity(master, 1)                                     
device eth0 entered promiscuous mode                                    
device vlan0 entered promiscuous mode                                     
device eth1 entered promiscuous mode                                    
br0: port 2(eth1) entering listening state                                          
br0: port 1(vlan0) entering listening state                                           
br0: port 2(eth1) entering learning state                                         
br0: port 1(vlan0) entering learning state                                          
br0: port 2(eth1) entering forwarding state                                           
br0: topology change detected, propagating                                          
br0: port 1(vlan0) entering forwarding state                                            
br0: topology change detected, propagating                                          
usb.c: registered new driver usbdevfs                                     
usb.c: registered new driver hub                                
usb-uhci.c: $Revision: 1.275 $ time 10:25:12 Jun 17 2006                                                        
usb-uhci.c: High bandwidth mode enabled                                       
PCI: Enabling device 01:03.0 (0000 -> 0001)                                           
ECHI PCI device 30381106 found.                               
UCHI reg 0x41 = 10                  
UCHI reg 0x41 changed to = 0                            
usb-uhci.c: USB UHCI at I/O 0x100, IRQ 2                                        
usb-uhci.c: Detected 2 ports                            
usb.c: new USB bus registered, assigned bus number 1                                                    
hub.c: USB hub found                    
hub.c: 2 ports detected                       
PCI: Enabling device 01:03.1 (0000 -> 0001)                                           
ECHI PCI device 30381106 found.                               
UCHI reg 0x41 = 10                  
UCHI reg 0x41 changed to = 0                            
usb-uhci.c: USB UHCI at I/O 0x120, IRQ 2                                        
usb-uhci.c: Detected 2 ports                            
usb.c: new USB bus registered, assigned bus number 2                                                    
hub.c: USB hub found                    
hub.c: 2 ports detected                       
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver                                                                 
PCI: Enabling device 01:03.2 (0000 -> 0002)                                           
ehci_hcd 01:03.2: PCI device 1106:3104                                      
ehci_hcd 01:03.2: irq 2, pci mem c00b0000                                         
usb.c: new USB bus registered, assig                                  
ECHI PCI device 31041106 found.                               
ECHI reg 0x49 = 80010f20                        
ECHI reg 0x49 changed to = 80010f00                                   
ECHI reg 0x4b = 80010f09                        
ECHI reg 0x4b changed to = 80010f29                                   
PCI: 01:03.2 PCI cache line size set incorrectly (0 bytes) by BIOS/FW, correctin                                                                                
g to 32       
ehci_hcd 01:03.2: USB 2.0 enabled, EHCI 1.00, driver 2003-Dec-29/2.4                                                                    
hub.c: USB hub found                    
hub.c: 4 ports detected                       
usb.c: registered new driver usblp                                  
printer.c: v0.13: USB Printer Device Class driver                                                 
usb.c: registered new driver audio                                  
audio.c: v1.0.0:USB Audio Class driver                                      
Linux video capture interface: v1.00                                    
SCSI subsystem driver Revision: 1.00                                    
Initializing USB Mass Storage driver...                                       
usb.c: registered new driver usb-storage                                        
USB Mass Storage support registered.
vlan1: Setting MAC address to  00 1b fc 57 ab 6e.
VLAN (vlan1):  Underlying device (eth0) has same MAC, not checking promiscious m
ode.
vlan1: add 33:33:00:00:00:01 mcast address to master interface
vlan1: add 33:33:ff:57:ab:6e mcast address to master interface
vlan1: Invalid argument
PCI devices found:
    Class 0501: PCI device 14e4:0800 (rev 9).
    Class 0200: PCI device 14e4:4713 (rev 9).
    Class 0200: PCI device 14e4:4713 (rev 9).
    Class 0c03: PCI device 14e4:4715 (rev 9).
    Class 0604: PCI device 14e4:0804 (rev 9).
    Class 0b30: PCI device 14e4:0816 (rev 9).
    Class 0703: PCI device 14e4:4712 (rev 9).
    Class 1000: PCI device 14e4:4718 (rev 9).
    Class 0500: PCI device 14e4:080f (rev 9).
    Class 0600: PCI device 14e4:4704 (rev 9).
    Class 0280: PCI device 14e4:4318 (rev 2).
    Class 0c03: PCI device 1106:3038 (rev 98).
    Class 0c03: PCI device 1106:3038 (rev 98).
    Class 0c03: PCI device 1106:3104 (rev 101).
echo for PaN ::: &&&PaN

With X-WRT the router doesn't start.

CFE_Output_X-Wrt_128MB:

CFE version 1.0.37 for BCM947XX (32bit,SP,LE)                               
init started:
Build Date: ¥| 10¤ë 12 22:21:19 CST 2006 (root@localhost.localdomain)                                                               
BusyB
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.                                                       

et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.7.0
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P)
CPU type 0x29006: 264MHz
Total memory: 134217728 KBytes

Total memory used by CFE:  0x80800000 - 0x8089AF40 (634688)
Initialized Data:          0x808313D0 - 0x80833790 (9152)
BSS Area:                  0x80833790 - 0x80834F40 (6064)
Local Heap:                0x80834F40 - 0x80898F40 (409600)
Stack Area:                0x80898F40 - 0x8089AF40 (8192)
Text (code) segment:       0x80800000 - 0x808313D0 (201680)
Boot area (physical):      0x0089B000 - 0x008DB000
Relocation Factor:         I:00000000 - D:00000000

Device eth0:  hwaddr 00-1B-FC-57-AB-6E, ipaddr 192.168.178.1, mask 255.255.255.0

        gateway not set, nameserver not set
Null Rescue Flag.
Loader:raw Filesys:raw Dev:flash0.os File: Options:(null)
Loading: .. 3704 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000

With 32MB Ram X-Wrt is working great. Maybe the error only occurs with morem than 128MB Ram.

Here you can find a fix of a modified detection routine:
http://oleg.wl500g.info/wl500gp/kernel-mvista-mem.patch

Until now this fix is not included in 2.4 and 2.6 kernel targets for brcm (brcm47xx).

Here you can find the thread to this task:
http://forum.x-wrt.org/index.php/topic,657.0.html

Attachments (4)

detect-128mb-ram.diff (3.7 KB) - added by anonymous 9 years ago.
mem.patch (836 bytes) - added by hauke 8 years ago.
170-128MB_ram_bugfix.patch (232 bytes) - added by hauke 7 years ago.
change prefetch range
170-128MB_ram_bugfix.2.patch (1.4 KB) - added by hauke 7 years ago.

Download all attachments as: .zip

Change History (31)

Changed 9 years ago by anonymous

comment:1 Changed 9 years ago by anonymous

Patch don't work anymore you have to modify file ".../trunk/build_dir/linux-brcm47xx/linux-2.6.25.10/arch/mips/bcm47xx/prom.c" instead

Changed 8 years ago by hauke

comment:2 follow-ups: Changed 8 years ago by hauke

  • Owner changed from developers to hauke

Please try the attached patch. It is out of a new version of Broadcoms GPL code. If the mem.patch solves the problem with kernel 2.4 I will also make a patch for kernel 2.6 and integrate it into trunk, so please test this one.

comment:3 in reply to: ↑ 2 Changed 8 years ago by vargalex@…

Replying to hauke:

Please try the attached patch. It is out of a new version of Broadcoms GPL code. If the mem.patch solves the problem with kernel 2.4 I will also make a patch for kernel 2.6 and integrate it into trunk, so please test this one.

Hi!

mem.patch works, but the router boots only first time. Than run script /etc/init.d/nvram, what sets sdram_init to 0x0009 (boardtype 0x042f). Than next boot fails. Help only Pin9 trick. I have changed the /etc/init.d/nvram, I set the sdram_init to 0x0011. Than is all OK.

comment:4 in reply to: ↑ 2 Changed 8 years ago by anonymous

Replying to hauke:

Please try the attached patch. It is out of a new version of Broadcoms GPL code. If the mem.patch solves the problem with kernel 2.4 I will also make a patch for kernel 2.6 and integrate it into trunk, so please test this one.

That's great.I need a patch for kernel 2.6. Can you supply? I will try it on my belkin 8230-4 with 128m mem.

comment:5 follow-up: Changed 8 years ago by hauke

The patch is applied in r18413

The problem reported by vargalex@… is in package/nvram/files/nvram.init It has some problems with this special board type.

Please report if broadcom devices now work with 128MB ram.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 8 years ago by anonymous

Replying to hauke:

The patch is applied in r18413

The problem reported by vargalex@… is in package/nvram/files/nvram.init It has some problems with this special board type.

Please report if broadcom devices now work with 128MB ram.

Hi!

I have latest patch not tested, but in mem.patch (what works) apply a change in target/linux/brcm-2.4/files/arch/mips/bcm947xx/prom.c
from
for (mem = (1 << 20); mem < (128 << 20); mem += (1 << 20)) {
to
for (mem = (1 << 20); mem < (128 << 20); mem <<= 1) {

Is this change not necessary? This change was in mem.patch!

comment:7 in reply to: ↑ 6 ; follow-ups: Changed 8 years ago by hauke

Replying to anonymous:

Replying to hauke:
Hi!

I have latest patch not tested, but in mem.patch (what works) apply a change in target/linux/brcm-2.4/files/arch/mips/bcm947xx/prom.c
from
{{for (mem = (1 << 20); mem < (128 << 20); mem += (1 << 20)) {}}
to
{{for (mem = (1 << 20); mem < (128 << 20); mem <<= 1) {}}

Is this change not necessary? This change was in mem.patch!

This was also copied out of the broadcom's sources, but is not necessary.

With "mem += (1 << 20)" it tries to get the size of the ram in 1MB steps. With "mem <<= 1" it steps from 1MB to 2MB to 4MB to 8MB ...

comment:8 in reply to: ↑ 7 ; follow-up: Changed 8 years ago by vargalex@…

Replying to hauke:

Replying to anonymous:

Replying to hauke:
Hi!

I have latest patch not tested, but in mem.patch (what works) apply a change in target/linux/brcm-2.4/files/arch/mips/bcm947xx/prom.c
from
{{for (mem = (1 << 20); mem < (128 << 20); mem += (1 << 20)) {}}
to
{{for (mem = (1 << 20); mem < (128 << 20); mem <<= 1) {}}

Is this change not necessary? This change was in mem.patch!

This was also copied out of the broadcom's sources, but is not necessary.

With "mem += (1 << 20)" it tries to get the size of the ram in 1MB steps. With "mem <<= 1" it steps from 1MB to 2MB to 4MB to 8MB ...

Hi!

Thanks for your reply! I will test this patch. Sorry, but I forgot to fill the e-mail field, so I was the 'Anonymous' too. :-)
If I well understand it, than this patch is applied for 2.6 too. Am I right? So, when I build a firmware from 2.6 trunk, should then work.

Thanks!

comment:9 in reply to: ↑ 8 ; follow-ups: Changed 8 years ago by hauke

Replying to vargalex@…:

Hi!

Thanks for your reply! I will test this patch. Sorry, but I forgot to fill the e-mail field, so I was the 'Anonymous' too. :-)
If I well understand it, than this patch is applied for 2.6 too. Am I right? So, when I build a firmware from 2.6 trunk, should then work.

Thanks!

Yes the problem should also be fixed for kernel 2.6. I have not tested it because I do not have a device with so much memory in it. The problem in /etc/init.d/nvram still exists and I do not understand why variable is changed in it.

Hauke

comment:10 in reply to: ↑ 9 Changed 8 years ago by vargalex@…

Replying to hauke:

Replying to vargalex@…:

Hi!

Thanks for your reply! I will test this patch. Sorry, but I forgot to fill the e-mail field, so I was the 'Anonymous' too. :-)
If I well understand it, than this patch is applied for 2.6 too. Am I right? So, when I build a firmware from 2.6 trunk, should then work.

Thanks!

Yes the problem should also be fixed for kernel 2.6. I have not tested it because I do not have a device with so much memory in it. The problem in /etc/init.d/nvram still exists and I do not understand why variable is changed in it.

Hauke

Hi!

I will test it, and give you a report from this. I think the reason is why /etc/init.d/nvram changed the sdram_init the next: when you on Asus WL-500gP upload a clear_nvram.trx, or make a Pin9-trick, than sdram_init value is 0x000b. That is for one memory chip (16 bit). With /etc/init.d/nvram change the value to 0x0009. Than the next boot is OK, you have 32MB RAM (32 bit, 2 memory chips). (That meant, that the user must no manual change this value.) But this is wrong for routers what modded to 128MB. I have changed the /etc/init.d/nvram:
"1071") #0x042f

sdinit = $(nvram get sdram_init)
if [ $sdinit = '0x000b' ]
then

nvram_set sdram_init "$(printf 0x%04x $(( $(/usr/sbin/nvram get sdram_init) | 0x0009 )))"
[ "$COMMIT" = 1 ] && {

nvram_set sdram_ncdl 0x0

}

fi

So, with this change, we change the sdram_init value, when the value is 0x000b. (Also modded router owners change the value manually.)

comment:11 in reply to: ↑ 9 Changed 8 years ago by vargalex@…

Replying to hauke:

Yes the problem should also be fixed for kernel 2.6. I have not tested it because I do not have a device with so much memory in it. The problem in /etc/init.d/nvram still exists and I do not understand why variable is changed in it.

Hauke

Hi!

I have tested the 2.6 trunk. Not OK.
But. I have found a problem: after build we have a build_dir. In build_dir is two prom.v file for bcm47xx:

  1. build_dir/linux-brcm47xx/linux-2.6.30.9/arch/mips/bcm47xx/prom.c

That is OK, that is patched.

  1. build_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1/linux-2.6.30.9/arch/mips/bcm47xx/prom.c

That is not OK, than is the unpatched file
I don't know, what is for firmware, but when I manual change the second file (build_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1/linux-2.6.30.9/arch/mips/bcm47xx/prom.c), and than make a second build, then all is OK.

comment:12 in reply to: ↑ 7 ; follow-up: Changed 7 years ago by b.sander

Replying to hauke:

Is this change not necessary? This change was in mem.patch!

This was also copied out of the broadcom's sources, but is not necessary.

With "mem += (1 << 20)" it tries to get the size of the ram in 1MB steps. With "mem <<= 1" it steps from 1MB to 2MB to 4MB to 8MB ...


This is essential for the detection, because this prevents a overrun and as a result a bus error stops execution. The patch to leave out the last page is rather suspicious - this should depend on Pagesize settings.

Without the full patch applied this won't run any kernel on devices with 128mb.

Thanks,
b.sander

comment:13 in reply to: ↑ 12 ; follow-up: Changed 7 years ago by hauke

Replying to b.sander:

This is essential for the detection, because this prevents a overrun and as a result a bus error stops execution.

Why should this prevent an overrun? The change is done in the incrementation step in the for loop, the test step is untouched.

The patch to leave out the last page is rather suspicious - this should depend on Pagesize settings.

Yes you are right this should use PAGE_SIZE. But the brcm47xx platform does not use any other Pageszie then 4K

Without the full patch applied this won't run any kernel on devices with 128mb.

As I understood vargalex the patch worked for him. b.sander have you tested it yourself?

vargalex: Is trunk without any modifications except the one preventing the nvram change working for you?

Could someone please test if trunk works on a device with 128MB ram without patch 170-128MB_ram_bugfix.patch or with the attached patch instead of 170-128MB_ram_bugfix.patch.

Please delete build_dir/linux-brcm47xx/ after changing something at the patches applied to the kernel and before building a new image.

Changed 7 years ago by hauke

change prefetch range

comment:14 in reply to: ↑ 13 ; follow-up: Changed 7 years ago by b.sander

Replying to hauke:

Replying to b.sander:

This is essential for the detection, because this prevents a overrun and as a result a bus error stops execution.

Why should this prevent an overrun? The change is done in the incrementation step in the for loop, the test step is untouched.

Loading: 0x80001000/6939948 0x8069f52c/136020 Entry at 0x80005250
Closing network.
et0: link down
Starting program at 0x80005250
**Exception 32: EPC=8028B4F4, Cause=00008018, VAddr=00000000
                RA=8028B4C4, PRID=00029007

        0  ($00) = 00000000     AT ($01) = 10000000
        v0 ($02) = 8FB10064     v1 ($03) = 8808B488
        a0 ($04) = 00100000     a1 ($05) = 07E00000
        a2 ($06) = 27BDFFE8     a3 ($07) = 08000000
        t0 ($08) = 00004000     t1 ($09) = 00000000
        t2 ($10) = 00000001     t3 ($11) = FFFFFFFF
        t4 ($12) = 00000000     t5 ($13) = 00000000
        t6 ($14) = 00000000     t7 ($15) = 00000000
        s0 ($16) = 806B0000     s1 ($17) = 80277F08
        s2 ($18) = FFFD96F0     s3 ($19) = 81FD6710
        s4 ($20) = 81BB45B0     s5 ($21) = 81FB6220
        s6 ($22) = 81FCE640     s7 ($23) = 81BB7CF8
        t8 ($24) = FFFFFFC8     t9 ($25) = E23B65E0
        k0 ($26) = 0000000A     k1 ($27) = FFFFFFFF
        gp ($28) = 80276000     sp ($29) = 80277E98
        fp ($30) = FFFF7E4C     ra ($31) = 8028B4C4

The codeblock for this is on:

8028b488 <prom_init>:
...
8028b4f0:	3c070800 	lui	a3,0x800
8028b4f4:	8c620000 	lw	v0,0(v1)
8028b4f8:	10460005 	beq	v0,a2,8028b510 <prom_init+0x88>
8028b4fc:	00641821 	addu	v1,v1,a0
8028b500:	00a42821 	addu	a1,a1,a0
8028b504:	14a7fffb 	bne	a1,a3,8028b4f4 <prom_init+0x6c>
8028b508:	00000000 	nop

looking at $v1 the address is above the 128mb = 0x8808B488 and that's why this probing:

	for (mem = (1 << 20); mem < (128 << 20); mem += (1 << 20)) {
		if (*(unsigned long *)((unsigned long)(prom_init) + mem) ==
		    *(unsigned long *)(prom_init))
			break;
	}

rises an exception and this:

	for (mem = (1 << 20); mem < (128 << 20); mem <<= 1)

will not!

Loading: 0x80001000/6939948 0x8069f52c/136020 Entry at 0x80005250
Closing network.
et0: link down
Starting program at 0x80005250
Linux version 2.6.32.9 (jax@jd) (gcc version 4.3.3 (GCC) ) #3 Sun Feb 28 16:57:15 CET 2010
CPU revision is: 00029007 (Broadcom BCM3302)
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x05, vendor 0x4243)
ssb: Core 1 found: Fast Ethernet (cc 0x806, rev 0x06, vendor 0x4243)
ssb: Core 2 found: IPSEC (cc 0x80B, rev 0x01, vendor 0x4243)
ssb: Core 3 found: USB 1.1 Hostdev (cc 0x808, rev 0x02, vendor 0x4243)
ssb: Core 4 found: PCI (cc 0x804, rev 0x08, vendor 0x4243)
ssb: Core 5 found: MIPS 3302 (cc 0x816, rev 0x01, vendor 0x4243)
ssb: Core 6 found: MEMC SDRAM (cc 0x80F, rev 0x00, vendor 0x4243)
ssb: Initializing MIPS core...
ssb: set_irq: core 0x0806, irq 4 => 4
ssb: set_irq: core 0x080b, irq 5 => 2
ssb: set_irq: core 0x0804, irq 2 => 5
ssb: after irq reconfiguration
ssb: core 0x0800, irq : 2(S)  3* 4  5  6  D  I 
ssb: core 0x0806, irq : 2(S)  3  4* 5  6  D  I 
ssb: core 0x080b, irq : 2(S)* 3  4  5  6  D  I 
ssb: core 0x0808, irq : 2(S)  3  4  5  6* D  I 
ssb: core 0x0804, irq : 2(S)  3  4  5* 6  D  I 
ssb: core 0x0816, irq : 2(S)* 3  4  5  6  D  I 
ssb: core 0x080f, irq : 2(S)  3  4  5  6  D  I*
early_nvram_init: WGT634U NVRAM found.
ssb: Sonics Silicon Backplane found at address 0x18000000
Swapping serial ports!
Serial init done.
Determined physical RAM map:
 memory: 07fff000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
  Normal   0x00000000 -> 0x00007fff
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00007fff
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32511
Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Primary instruction cache 8kB, 2-way, VIPT, linesize 16 bytes.
Primary data cache 4kB, 2-way, VIPT, no aliases, linesize 16 bytes
Memory: 122836k/131068k available (2238k kernel code, 8044k reserved, 350k data, 4188k init, 0k highmem)
Hierarchical RCU implementation.


The patch to leave out the last page is rather suspicious - this should depend on Pagesize settings.

Yes you are right this should use PAGE_SIZE. But the brcm47xx platform does not use any other Pageszie then 4K


Only for sanity ;-) Tested on
WGT634U 128 mb sdram and
WL-500gp v1 128 mb ddr ram.

Could someone please test if trunk works on a device with 128MB ram without patch 170-128MB_ram_bugfix.patch or with the attached patch instead of 170-128MB_ram_bugfix.patch.

Please delete build_dir/linux-brcm47xx/ after changing something at the patches applied to the kernel and before building a new image.

Please look at Ticket #6765 for an updated patch!

Thanks,
b.sander

comment:15 in reply to: ↑ 14 ; follow-up: Changed 7 years ago by hauke

Thank you b.sander for your relay good debugging. Hopefully now I got what happened here and why. As I do not know of any device with an amount of ram other then 2n your patch should be safe.

It looks like the brcm47xx uses 128MB for addressing the ram and maps the physical ram more times into this space. With a size of 128MB ran this detection function does not work any more and we assume 128MB ram.

In the working case for vargalex the function prom_init could have been placed in the first 1MB of ram and then it worked, if it was placed somewhere else it did not work.

The attached patch contains a little bit more documentation and some other stuff from braodcom driver. Please try it if it works.

Changed 7 years ago by hauke

comment:16 Changed 7 years ago by vargalex@…

Hi!

By me (WL-500gP 128MB RAM) was the patch good, but my fried have a WL-500gP with 128MB RAM too, but the patch don't work for he's router. The good solution was:

for (mem = (1 << 20); mem < (128 << 20); mem <<= 1) {

vargalex

comment:17 in reply to: ↑ 15 Changed 7 years ago by b.sander

Replying to hauke:

Thank you b.sander for your relay good debugging. Hopefully now I got what happened here and why. As I do not know of any device with an amount of ram other then 2n your patch should be safe.

It looks like the brcm47xx uses 128MB for addressing the ram and maps the physical ram more times into this space. With a size of 128MB ran this detection function does not work any more and we assume 128MB ram.

Right[[BR]]

In the working case for vargalex the function prom_init could have been placed in the first 1MB of ram and then it worked, if it was placed somewhere else it did not work.

The attached patch contains a little bit more documentation and some other stuff from braodcom driver. Please try it if it works.

Works for me!

Loading: 0x80001000/6938664 
0x8069f028/137304 Entry at 0x80005250
Closing network.
et0: link down
Starting program at 0x80005250

Linux version 2.6.32.9 (jax@jd) (gcc version 4.3.3 (GCC) ) #2 Mon Mar 1 09:00:03 CET 2010
CPU revision is: 00029007 (Broadcom BCM3302)
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x05, vendor 0x4243)
ssb: Core 1 found: Fast Ethernet (cc 0x806, rev 0x06, vendor 0x4243)
ssb: Core 2 found: IPSEC (cc 0x80B, rev 0x01, vendor 0x4243)
ssb: Core 3 found: USB 1.1 Hostdev (cc 0x808, rev 0x02, vendor 0x4243)
ssb: Core 4 found: PCI (cc 0x804, rev 0x08, vendor 0x4243)
ssb: Core 5 found: MIPS 3302 (cc 0x816, rev 0x01, vendor 0x4243)
ssb: Core 6 found: MEMC SDRAM (cc 0x80F, rev 0x00, vendor 0x4243)
ssb: Initializing MIPS core...
ssb: set_irq: core 0x0806, irq 4 => 4
ssb: set_irq: core 0x080b, irq 5 => 2
ssb: set_irq: core 0x0804, irq 2 => 5
ssb: after irq reconfiguration
ssb: core 0x0800, irq : 2(S)  3* 4  5  6  D  I 
ssb: core 0x0806, irq : 2(S)  3  4* 5  6  D  I 
ssb: core 0x080b, irq : 2(S)* 3  4  5  6  D  I 
ssb: core 0x0808, irq : 2(S)  3  4  5  6* D  I 
ssb: core 0x0804, irq : 2(S)  3  4  5* 6  D  I 
ssb: core 0x0816, irq : 2(S)* 3  4  5  6  D  I 
ssb: core 0x080f, irq : 2(S)  3  4  5  6  D  I*
early_nvram_init: WGT634U NVRAM found.
ssb: Sonics Silicon Backplane found at address 0x18000000
Swapping serial ports!
Serial init done.
Determined physical RAM map:
 memory: 08000000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
  Normal   0x00000000 -> 0x00008000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00008000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Primary instruction cache 8kB, 2-way, VIPT, linesize 16 bytes.
Primary data cache 4kB, 2-way, VIPT, no aliases, linesize 16 bytes
Memory: 122864k/131072k available (2238k kernel code, 8044k reserved, 350k data, 4188k init, 0k highmem)
Hierarchical RCU implementation.
[...]
BusyBox v1.15.3 (2010-02-27 22:46:13 UTC) built-in shell (ash)
Enter 'help' for a li
st of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 KAMIKAZE (bleeding edge, r19885) ------------------
  * 10 oz Vodka       Shake well with ice and strain
  * 10 oz Triple sec  mixture into 10 shot glasses.
  * 10 oz lime juice  Salute!
 ---------------------------------------------------
root@OpenWrt:/#

comment:18 Changed 7 years ago by thepeople

  • Status changed from new to assigned

comment:19 follow-up: Changed 7 years ago by hauke

Please try recent trunk.
r20072 contains probably a fix for this problem.
Please report any success or failure.

comment:20 in reply to: ↑ 19 ; follow-ups: Changed 7 years ago by b.sander

Replying to hauke:

Please try recent trunk.
r20072 contains probably a fix for this problem.
Please report any success or failure.

I did not test the trunk, but please take a look at http://oleg.wl500g.info/sdram.html. Why you wanna probe the memory in 1 mbyte steps, there is no setup for mixed size ram chips for this memory controller? The Broadcom code probes only available configuration windows. So if there is no window at 64 mbyte - then there is the maximum of 128 mbyte installed.

Regards

comment:21 in reply to: ↑ 20 ; follow-up: Changed 7 years ago by anonymous

I've tested r20144 on two of my wl500gpv1, both with 128m mod. they booted properly with sdram_init=0x0009. Then I set sdram_init=0x0011, they still went up. But unfortunately, they both booted failed at the next boot. I had to apply the pin9 trick to force them enter tftp mode. Wish this information can help you

Best Regards

Replying to b.sander:

Replying to hauke:

Please try recent trunk.
r20072 contains probably a fix for this problem.
Please report any success or failure.

I did not test the trunk, but please take a look at http://oleg.wl500g.info/sdram.html. Why you wanna probe the memory in 1 mbyte steps, there is no setup for mixed size ram chips for this memory controller? The Broadcom code probes only available configuration windows. So if there is no window at 64 mbyte - then there is the maximum of 128 mbyte installed.

Regards

comment:22 in reply to: ↑ 21 ; follow-up: Changed 7 years ago by frosch6669

Hello,
did you modify the configurationfile for nvram values, i read somewhere that there ist a script running at boot setting some nvram variables, maybe it is setting some wrong values?!
Regards

Replying to anonymous:

I've tested r20144 on two of my wl500gpv1, both with 128m mod. they booted properly with sdram_init=0x0009. Then I set sdram_init=0x0011, they still went up. But unfortunately, they both booted failed at the next boot. I had to apply the pin9 trick to force them enter tftp mode. Wish this information can help you

comment:23 in reply to: ↑ 22 Changed 7 years ago by yellowbug

Hi, thank you for your informing. after changing "sdram_init=0x0009" to "sdram_init=0x0011" in /etc/init.d/nvram, everything is ok now. Great job!

Replying to frosch6669:

Hello,
did you modify the configurationfile for nvram values, i read somewhere that there ist a script running at boot setting some nvram variables, maybe it is setting some wrong values?!
Regards

comment:24 Changed 7 years ago by anonymous

I have an ASUS WL-500W that I have applied the 128MB RAM mod to. I use bcrm 2.4 image and suffer the hang at boot time when I set sdram_init=0x0011 and sdram_config=0x0062. I get control back by loading in Olegs firmware and setting sdram variables back to the standard (sdram_init=0x000b and sdram_config=0x0032. However following the info above when I set sdram_init=0x0009 and sdram_config=0x0062, it does boot and it reports 64MB of memory available. Not ideal but at least it is more.
Fraser

comment:25 Changed 7 years ago by vargalex@…

Hi!

I think, the 2.4 image is still wrong patched (but by me was ok). Try the 2.6.

comment:26 in reply to: ↑ 20 Changed 7 years ago by b.sander

Replying to hauke:

Index: package/nvram/files/nvram.init
===================================================================
--- package/nvram/files/nvram.init	(Revision 20744)
+++ package/nvram/files/nvram.init	(Arbeitskopie)
@@ -52,7 +52,13 @@
 			}
 		;;
 		"1071") #0x042f
-			nvram_set sdram_init "$(printf 0x%04x $(( $(/usr/sbin/nvram get sdram_init) | 0x0009 )))"
+			# why mess with sdram_init at all? do sanity check first! max 0x0011 = 128mb
+			SDRAM_INIT=$(printf %d $(/usr/sbin/nvram get sdram_init))
+			[ "$SDRAM_INIT" -lt "9" -o "$SDRAM_INIT" -gt "17" ] && {
+				# set this to default: 0x09 only if value is invaild
+				echo "sdram_init is invaild: $(printf 0x%04x $SDRAM_INIT), force to default!"
+				$(/usr/sbin/nvram_set sdram_init "0x0009")
+			}
 			[ "$COMMIT" = 1 ] && {
 				nvram_set sdram_ncdl 0x0
 			}


Regards

comment:27 Changed 7 years ago by hauke

  • Resolution set to fixed
  • Status changed from assigned to closed

Thank you b.sander for the patch.

It was added in r21497

If there are still problems please reopen the ticket.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.