On 1/18/2018 12:47 PM, Vanessa Maegima wrote:
Hi Arend,
On Ter, 2018-01-16 at 21:21 +0100, Arend van Spriel wrote:
On 1/15/2018 9:08 PM, Fabio Estevam wrote:
Hi Arend,
On Tue, Dec 5, 2017 at 12:58 PM, Vanessa Maegima
<vanessa.maegima@xxxxxxx> wrote:
Hi Arend,
Sorry for this!
I updated the folder on https://emea01.safelinks.protection.outlo
ok.com/?url=https%3A%2F%2Fdrive.google.com%2Fdrive%2Ffolders%2F1f
osahjL&data=02%7C01%7Cvanessa.maegima%40nxp.com%7Cf07cd1a6ffb34c0
961f608d55d1eb901%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
6517308901643244&sdata=6JAqSN%2BVPJ%2FCF7cbnBjm8geMKWydWkG9JcUhGB
Pj644%3D&reserved=0
N1KI5NKS59_aPZdHLpENPFHtK
Thanks!
Any ideas, please?
Well, the dumps confirm a crash early in the firmware boot. However,
I
could not obtain more information from it. To capture the failure I
need
to rework some firmware functionality which is not trivial and I can
not
claim time for it right now.
Regards,
Arend
Thanks for all your investigation here!
I just want to report one more thing that I noticed from my tests.
I have tried to use an html file that I downloaded using wget as the
nvram file (https://github.com/OpenELEC/wlan-firmware/blob/master/firmw
are/brcm/nvram_ap6335.txt) and the wifi seems to work. I have not
noticed the wrong format file until testing it.
Interesting. In brcmfmac the file is parsed before sending it to the
firmware so I am wondering what is effectively send to the device.
Can you dump the nvram that is sent to the device. Just add hexdump call
of nvram in brcmf_fw_request_nvram_done() in firmware.c just before
fwctx->done() is called.
Regards,
Arend
