Opened 9 years ago

Closed 5 years ago

#4083 closed defect (fixed)

incorrect clock rate on ASUS WL-520gU

Reported by: semenzato Owned by: hauke
Priority: normal Milestone:
Component: packages Version:
Keywords: Cc:


This code in linux-

/* 5354 chip uses a non programmable PLL of frequency 240MHz */
if (sb_chip(sbh) == BCM5354_CHIP_ID) {

rate = 240000000;
goto out;


is incorrect for the ASUS WL-520gU router. The correct frequency for this model is 200MHz.

The symptom is that system time runs at 83.33% of normal---too slow to be fixed by ntpclient or adjtimex.

Attachments (0)

Change History (13)

comment:1 follow-up: Changed 9 years ago by florian

Do not you also have issues with the flash chip ?

comment:2 Changed 9 years ago by redhawk

The CFE.BIN file clearly states that this is operation at 240MHz.

Mine looses about 12-13 minutes per hour. (about 12 seconds per minute)


comment:3 Changed 9 years ago by cmshk

After set rate = 240000000; slow clock issue fixed, but when writing to jffs2, you get :

Warning: DQ5 raised while program operation was in progress, however operation completed OK

I believe there are some more timing data needed to be patched. Developers please give some hints.

comment:4 Changed 9 years ago by cmshk

Sorry, please correct my typo, should be "After set rate = 200000000;"

comment:5 Changed 9 years ago by florian

  • Owner changed from developers to florian
  • Status changed from new to assigned

comment:6 Changed 9 years ago by edo <edo.rus@…>

same with 2.6 kernel (brcm47xx target), see /ticket/5135.html for details

comment:7 Changed 9 years ago by jchau@…

Same problem here. Using OpenWRT 8.09.1 (openwrt-brcm-2.4-squashfs.trx). None of the NTP programs (ntpd, ntpclient) are able to correct the time. And if I set the time with the date command, I can notice too many seconds of drift (too slow) per minute.

comment:8 Changed 8 years ago by nagydani@…


comment:9 in reply to: ↑ 1 Changed 8 years ago by jchau@…

Replying to florian:

Do not you also have issues with the flash chip ?

I might also have problems with the flash chip: I encountered problems upgrading the firmware from Kamikaze 8.09.1 to 8.09.2. When using the LuCI web-interface to upgrade the firmware (also telling it to keep the configuration files), the process does not complete; however, this problem can also be completely unrelated to the flash chip. After the failed upgrade, the router enters its firmware recovery mode, where I am able to successfully use tftp to get the Kamikaze firmware onto the router. Other than this problem, I have not noticed any flash chip/flashing related problems on the WL520-gU.

I hope you'll excuse my ignorance, but how does this incorrect clock rate bug relate to issues with the flash chip? Is it that the wrong signal timing should prevent I/O with the flash chip? I'll try to reproduce & analyze my firmware upgrade problem if that will help fix this bug.

comment:10 Changed 7 years ago by anonymous

has this been fixed now?

comment:11 Changed 6 years ago by florian

  • Owner changed from florian to hauke
  • Status changed from accepted to assigned

comment:12 Changed 6 years ago by pawowgold

very good, it's very useful to me, thank you very much!

comment:13 Changed 5 years ago by hauke

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

This is fixed in r34325.

Add Comment

Modify Ticket

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

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

Note: See TracTickets for help on using tickets.