On 11/21/2011 02:56 PM, Thomas Lang?s wrote:
> Hi!
>
> I'm trying to make our board use this driver instead of an old,
> proprietary bcm4329-driver, but I can't seem
> to find much detail on how to tell the driver where my chip is located
> (on what SDIO-bus). I suppose there
> is some specifics I need to include in my machine-file? Or is
> everything magic? Because, currently
> the platform crashes when enabling the driver. I suspect that this is
> because we boot from an uSD-card,
> and that the brcm80211 tries to access the same port for connecting to the chip.
>
The MMC core should be able to come up with the correct device. It
sounds strange that the driver would be activated for an SD card.
Could you provide some information on the board you are using. Type of
processor, kernel version, and anything else you can/want to share. In
/sys/bus/sdio/devices/ you may find the location of the bcm4329.
Gr. AvS
On 11/21/2011 01:34 PM, Thomas Lang?s wrote:
> On Mon, Nov 21, 2011 at 10:13 PM, Thomas Lang?s
> <[email protected]> wrote:
>> Hmm, doing that, and loading this as a module instead of compiling it into the
>> kernel seemed to work.
>>
>> Is there a reason for this not working when being compiled into the kernel? Is
>> it possible that I need to change the order of some of the units
>> being initialized
>> in my machine-description / init?\
Usually we compile it as module instead of built-in. But I just tried it
with built-in and it can intialize and scan. Some issue did happen
during joining an AP. So I would suggest use module for your
development for now.
>
> Ok, so I get the device listed as a wlan0-device, and I see the driver
> being able to communicate
> with the chip, sort of (it can read registers at least), but then I
> start seeing errors like this (from
> the previously attached log):
It's possible that the firmware carshed. Are you using the
firmware/nvram from Linux repository? You should use the nvram that fits
your platform.
Franky
On 11/21/2011 04:00 PM, Thomas Lang?s wrote:
> On Tue, Nov 22, 2011 at 12:56 AM, Franky Lin<[email protected]> wrote:
>> Yes please give it a try.
>
> Set it to 25MHz, still same problem.
I see. How about revert the change for enabling the debug message and
give it a go. Can the driver function normally? (load, scan, join AP and
ping).
>> About the functional combination of .36 kernel + proprietary driver, is it a
>> mainline kernel or an Android one?
>
> Android, yes.
You said the current kernel is from Samsung's tree, is it an Android one
as well?
Franky
On Mon, Nov 21, 2011 at 11:48 PM, Franky Lin <[email protected]> wrote:
> I think both firmware is fine. I was referring to the
> brcm/bcm4329-fullmac-4.txt It's a nvram file contains critical information
> used by firmware. And it's hardware dependent. We have submitted a patch to
> remove the one in Linux firmware repository to avoid confusion as it's for a
> Broadcom internal development board. It may not work with your set up. I
> think there should be a similar file comes with the proprietary driver
> package if you are using a module instead of a 4329 chip. Please use that
> one.
I did two tests one with only changing the nvram-file, and one with
changing both
the firmware and the nvram-file (this is the latest logfile you got). Both had
the same result.
> I don't have Exynos 4210 spec. But I guess for a such new chip the SDIO host
> should be able to run the bus at 50MHz. You could try to hack the MMC/SDIO
> host driver and reduce the max frequency to 25MHz or even further to 12MHz
> to see if any improvement.
Max clock is 63MHz, and the setting we have now works with 2.6.36 and the
proprietary driver (bcm4329).
Looking at the platform-code we have for 2.6.x, I see that we set
.cd_type = S3C_SDHCI_CD_GPIO,
Instead of
.cd_type = S3C_SDHCI_CD_INTERNAL,
I don't know if this matters (looking at the schematics, the clk-pin is the same
for mmc2 as it is for the gpio). Is this something related to the old
proprietary
driver?
Regards,
Thomas
On 11/21/2011 02:26 PM, Thomas Lang?s wrote:
> On Mon, Nov 21, 2011 at 10:58 PM, Franky Lin<[email protected]> wrote:
>> It's possible that the firmware carshed. Are you using the firmware/nvram
>> from Linux repository? You should use the nvram that fits your platform.
>
> I'm using the one from repository now, yes.
>
> Using the firmware I had from before, the only difference I see is the
> time of when
> the IRQ handler is called, but that is probably just randomness, I guess?
I think both firmware is fine. I was referring to the
brcm/bcm4329-fullmac-4.txt It's a nvram file contains critical
information used by firmware. And it's hardware dependent. We have
submitted a patch to remove the one in Linux firmware repository to
avoid confusion as it's for a Broadcom internal development board. It
may not work with your set up. I think there should be a similar file
comes with the proprietary driver package if you are using a module
instead of a 4329 chip. Please use that one.
>
> Attached is the log when modprobing with old firmware.
>
The issue you facing is more likely SDIO bus connection issue.
brcmf_sdioh_request_word: Failed to write word, Err: 0xffffffac
mmc1: Got data interrupt 0x00200000 even though no data operation was in
progress.
These may be both caused by data CRC error/time out.
I don't have Exynos 4210 spec. But I guess for a such new chip the SDIO
host should be able to run the bus at 50MHz. You could try to hack the
MMC/SDIO host driver and reduce the max frequency to 25MHz or even
further to 12MHz to see if any improvement.
Regards,
Franky
On Mon, Nov 21, 2011 at 7:30 PM, Franky Lin <[email protected]> wrote:
> Current MMC stack in Linux would not confuse a MMC/SD card and a SDIO
> device. Basically the intialization and command sets they used are
> different.
So the crash is unrelated, is what you're saying? I've attached the
log if that'll
give you some more clues.
> Just for curiosity, do you know the version of your proprietary driver? You
> should be able to find it in epivers.h.
#define EPI_VERSION_STR "4.218.248.18"
#define EPI_ROUTER_VERSION_STR "4.219.248.18"
> A crash log would be helpful to locate the issue.
Attached is a crash.log-file from the serial console.
Regards,
Thomas
On Mon, Nov 21, 2011 at 6:23 PM, Arend van Spriel <[email protected]> wrote:
> Could you provide some information on the board you are using. Type of
> processor, kernel version, and anything else you can/want to share. In
> /sys/bus/sdio/devices/ you may find the location of the bcm4329.
Kernel version: 3.2.0-rc1 (from linux-samsung tree)
Processor: Samsung Exynos 4210
* uSD-reader is on mmc 0
* bcm4329 is on mmc 2
Any more details you want to know, please feel free to ask.
Regards,
Thomas
On Tue, Nov 22, 2011 at 12:56 AM, Franky Lin <[email protected]> wrote:
> Yes please give it a try.
Set it to 25MHz, still same problem.
> About the functional combination of .36 kernel + proprietary driver, is it a
> mainline kernel or an Android one?
Android, yes.
Regards,
Thomas
Hello Thomas,
The max clock speed supported by 4329 is 50MHz.
-Howard
-----Original Message-----
From: Thomas Lang?s [mailto:[email protected]]
Sent: Monday, November 21, 2011 3:41 PM
To: Franky (Zhenhui) Lin
Cc: Arend Van Spriel; [email protected]; Howard Harte
Subject: Re: brcm80211 (with bcm4329-chip)
On Mon, Nov 21, 2011 at 11:48 PM, Franky Lin <[email protected]> wrote:
> I think both firmware is fine. I was referring to the
> brcm/bcm4329-fullmac-4.txt It's a nvram file contains critical information
> used by firmware. And it's hardware dependent. We have submitted a patch to
> remove the one in Linux firmware repository to avoid confusion as it's for a
> Broadcom internal development board. It may not work with your set up. I
> think there should be a similar file comes with the proprietary driver
> package if you are using a module instead of a 4329 chip. Please use that
> one.
I did two tests one with only changing the nvram-file, and one with
changing both
the firmware and the nvram-file (this is the latest logfile you got). Both had
the same result.
> I don't have Exynos 4210 spec. But I guess for a such new chip the SDIO host
> should be able to run the bus at 50MHz. You could try to hack the MMC/SDIO
> host driver and reduce the max frequency to 25MHz or even further to 12MHz
> to see if any improvement.
Max clock is 63MHz, and the setting we have now works with 2.6.36 and the
proprietary driver (bcm4329).
Looking at the platform-code we have for 2.6.x, I see that we set
.cd_type = S3C_SDHCI_CD_GPIO,
Instead of
.cd_type = S3C_SDHCI_CD_INTERNAL,
I don't know if this matters (looking at the schematics, the clk-pin is the same
for mmc2 as it is for the gpio). Is this something related to the old
proprietary
driver?
Regards,
Thomas
On 11/21/2011 10:45 AM, Thomas Lang?s wrote:
> On Mon, Nov 21, 2011 at 7:30 PM, Franky Lin<[email protected]> wrote:
>> Current MMC stack in Linux would not confuse a MMC/SD card and a SDIO
>> device. Basically the intialization and command sets they used are
>> different.
>
> So the crash is unrelated, is what you're saying? I've attached the
> log if that'll
> give you some more clues.
Yes, it should have nothing to do with the crash.
> Attached is a crash.log-file from the serial console.
>
> [ 5.390000] mmc1: Got data interrupt 0x00200000 even though no
data operation was in progress.
This is weird.
#define SDHCI_INT_ADMA_ERROR 0x02000000
Could you check why the the SDIO host controller is generating this kind
of interrupt?
Also, comment out the line "brcmf_msg_level = BRCMF_ERROR_VAL;" in
brcmf_c_init of dhd_common.c. Then insert fullmac module by
insmod brcmfmac.ko brcmf_msg_level=0x7. This will give you a more detail
log of brcmfmac. But I am suspecting even the first SDIO read command
failed.
Franky
On Mon, Nov 21, 2011 at 10:13 PM, Thomas Lang?s
<[email protected]> wrote:
> Hmm, doing that, and loading this as a module instead of compiling it into the
> kernel seemed to work.
>
> Is there a reason for this not working when being compiled into the kernel? Is
> it possible that I need to change the order of ?some of the units
> being initialized
> in my machine-description / init?
Ok, so I get the device listed as a wlan0-device, and I see the driver
being able to communicate
with the chip, sort of (it can read registers at least), but then I
start seeing errors like this (from
the previously attached log):
[ 463.030000] brcmf_sdioh_request_word: Failed to write word, Err: 0xffffffac
[ 463.030000] brcmf_sdcard_reg_write: error writing 0x00000000 to
addr 0x8058 size 4
[ 463.030000] brcmf_sdcard_reg_write: fun = 1, addr = 0x1800005c,
uint32data = 0x0
[ 463.030000] brcmf_sdioh_request_word: rw=1, func=1, addr=0x0805c, nbytes=4
[ 463.030000] brcmf_sdioh_request_word: Failed to write word, Err: 0xffffffac
[ 463.030000] brcmf_sdcard_reg_write: error writing 0x00000000 to
addr 0x805c size 4
[ 463.030000] brcmf_sdioh_request_byte: rw=1, func=0, addr=0x00002
[ 463.040000] brcmf_sdcard_cfg_write: fun = 0, addr = 0x2, u8data = 0x2
[ 463.040000] brcmf_sdioh_request_byte: rw=0, func=1, addr=0x00000
[ 463.040000] brcmf_sdcard_cfg_read: fun = 1, addr = 0x0, u8data = 0x29
[ 463.040000] brcmf_sdioh_request_byte: rw=1, func=1, addr=0x1000e
[ 463.040000] brcmf_sdcard_cfg_write: fun = 1, addr = 0x1000e, u8data = 0x0
[ 463.040000] brcmf_sdbrcm_sdiod_drive_strength_init: No SDIO Drive
strength init done for chip 4329 rev 3 pmurev 6
...
[ 463.040000] brcmf_sdcard_reg_write: fun = 1, addr = 0x18011000,
uint32data = 0x2
[ 463.040000] brcmf_sdioh_request_word: rw=1, func=1, addr=0x09000, nbytes=4
[ 463.040000] brcmf_sdioh_request_word: Failed to write word, Err: 0xffffffac
[ 463.040000] brcmf_sdcard_reg_write: error writing 0x00000002 to
addr 0x9000 size 4
[ 463.040000] brcmf_attach: Enter
...
[ 463.050000] brcmf_sdbrcm_probe: completed!!
...
[ 463.055000] brcmf_sdbrcm_isr: Enter
[ 463.055000] brcmf_sdbrcm_isr: bus is down. we have nothing to do
...
(and the list goes on)
Any pointers on what I should start looking for? :)
Regards,
Thomas
On Tue, Nov 22, 2011 at 1:13 AM, Franky Lin <[email protected]> wrote:
> On 11/21/2011 04:00 PM, Thomas Lang?s wrote:
>>
>> On Tue, Nov 22, 2011 at 12:56 AM, Franky Lin<[email protected]> ?wrote:
>> Set it to 25MHz, still same problem.
> I see. How about revert the change for enabling the debug message and give
> it a go. Can the driver function normally? (load, scan, join AP and ping).
It loads, but that's about it, it reports that the network is down.
>>> About the functional combination of .36 kernel + proprietary driver, is
>>> it a
>>> mainline kernel or an Android one?
>> Android, yes.
> You said the current kernel is from Samsung's tree, is it an Android one as
> well?
No, not Android but this one:
https://github.com/kgene/linux-samsung
Regards,
Thomas
On Mon, Nov 21, 2011 at 8:58 PM, Franky Lin <[email protected]> wrote:
>> [ ? ?5.390000] mmc1: Got data interrupt 0x00200000 even though no data
>> operation was in progress.
>
> This is weird.
> #define ?SDHCI_INT_ADMA_ERROR ? 0x02000000
> Could you check why the the SDIO host controller is generating this kind of
> interrupt?
>From the doc:
"This bit is set if the Host Controller detects errors during
ADMA based data transfer. The state of the ADMA at an
error occurrence is saved in the ADMA Error Status
Register, In addition, the Host Controller generates this
Interrupt if it detects invalid descriptor data (Valid=0) at
the ST_FDS state. ADMA Error State in the ADMA Error
Status indicates that an error occurs in ST_FDS state.
The Host Driver may find that Valid bit is not set at the
error descriptor."
> Also, comment out the line "brcmf_msg_level = BRCMF_ERROR_VAL;" in
> brcmf_c_init of dhd_common.c. Then insert fullmac module by
> insmod brcmfmac.ko brcmf_msg_level=0x7. This will give you a more detail log
> of brcmfmac. But I am suspecting even the first SDIO read command failed.
Hmm, doing that, and loading this as a module instead of compiling it into the
kernel seemed to work.
Is there a reason for this not working when being compiled into the kernel? Is
it possible that I need to change the order of some of the units
being initialized
in my machine-description / init?
I'm attaching the log from modprobe.
Regards,
Thomas
On 11/21/2011 03:50 PM, Thomas Lang?s wrote:
> On Tue, Nov 22, 2011 at 12:42 AM, Howard Harte<[email protected]> wrote:
>> Hello Thomas,
>>
>> The max clock speed supported by 4329 is 50MHz.
>
> According to the driver (mmc-driver, that is) it's running at 50MHz.
>
> I'll try to see if I can lower it to 25MHz, if you think that could
> solve any problems.
Yes please give it a try.
About the functional combination of .36 kernel + proprietary driver, is
it a mainline kernel or an Android one?
Thanks,
Franky
On Mon, Nov 21, 2011 at 10:58 PM, Franky Lin <[email protected]> wrote:
> It's possible that the firmware carshed. Are you using the firmware/nvram
> from Linux repository? You should use the nvram that fits your platform.
I'm using the one from repository now, yes.
Using the firmware I had from before, the only difference I see is the
time of when
the IRQ handler is called, but that is probably just randomness, I guess?
Attached is the log when modprobing with old firmware.
Regards,
Thomas
On Tue, Nov 22, 2011 at 12:42 AM, Howard Harte <[email protected]> wrote:
> Hello Thomas,
>
> The max clock speed supported by 4329 is 50MHz.
According to the driver (mmc-driver, that is) it's running at 50MHz.
I'll try to see if I can lower it to 25MHz, if you think that could
solve any problems.
Regards,
Thomas
On 11/21/2011 09:23 AM, Arend van Spriel wrote:
> On 11/21/2011 02:56 PM, Thomas Lang?s wrote:
>> Hi!
>>
>> I'm trying to make our board use this driver instead of an old,
>> proprietary bcm4329-driver, but I can't seem
>> to find much detail on how to tell the driver where my chip is located
>> (on what SDIO-bus). I suppose there
>> is some specifics I need to include in my machine-file? Or is
>> everything magic? Because, currently
>> the platform crashes when enabling the driver. I suspect that this is
>> because we boot from an uSD-card,
>> and that the brcm80211 tries to access the same port for connecting to the chip.
>>
>
> The MMC core should be able to come up with the correct device. It
> sounds strange that the driver would be activated for an SD card.
>
> Could you provide some information on the board you are using. Type of
> processor, kernel version, and anything else you can/want to share. In
> /sys/bus/sdio/devices/ you may find the location of the bcm4329.
Current MMC stack in Linux would not confuse a MMC/SD card and a SDIO
device. Basically the intialization and command sets they used are
different.
Just for curiosity, do you know the version of your proprietary driver?
You should be able to find it in epivers.h.
A crash log would be helpful to locate the issue.
Regards,
Franky