On 2/21/2019 10:27 AM, Rafał Miłecki wrote:
On Thu, 21 Feb 2019 at 09:59, Arend Van Spriel
<arend.vanspriel@xxxxxxxxxxxx> wrote:
On 2/21/2019 9:01 AM, Rafał Miłecki wrote:
On Wed, 20 Feb 2019 at 11:31, Rafał Miłecki <zajec5@xxxxxxxxx> wrote:
From: Rafał Miłecki <rafal@xxxxxxxxxx>
While experimenting with firmware loading I ended up in a state of
firmware reporting shared RAM address 0x04000001. It was causing:
[ 94.448015] Unable to handle kernel paging request at virtual address cd680001
due to reading out of the mapped memory.
This patch adds some basic validation to avoid kernel crashes due to the
unexpected firmware behavior.
For a reference for the further hackers. That has been caused by a
BCMA_CORE_SYS_MEM core on my BCM4366/4 not being up.
Thanks, Rafał
Does that happen all the time or in some specific scenario. Anyway, it
seems like we need to add a check in brcmf_chip_sysmem_ramsize() and
bringup the core if needed. Although, I am curious in what the state the
other cores are at that time. Might need a chip-wide reset.
It happens after brcmf_pcie_reset_device() which is probably a 100%
expected case ;)
Did not check what that function exactly does, but could be expected.
Normally brcmfmac does not call brcmf_pcie_reset_device() between
brcmf_chip_sysmem_ramsize() and the brcmf_pcie_download_fw_nvram() so
it was only my hacking that caused that issue for me.
Ah. Can only wish you happy hacking then ;-)
Gr. AvS
