[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <734600434d7d4cce871353b33ef22a6f@realtek.com>
Date: Wed, 20 Nov 2019 09:20:13 +0000
From: James Tai <james.tai@...ltek.com>
To: Andreas Färber <afaerber@...e.de>
CC: "linux-realtek-soc@...ts.infradead.org"
<linux-realtek-soc@...ts.infradead.org>,
Mark Rutland <mark.rutland@....com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 5/7] ARM: dts: rtd1195: Introduce r-bus
Hi Andreas,
> Please see [1] - I had already updated the second reservation to start at
> 0xa800 and extended it to 0x100000 before your response here.
Thank you.
> The previous "bootcode" size of 0xc000 can be found here:
> https://github.com/BPI-SINOVOIP/BPI-M4-bsp/blob/master/linux-rtk/arch/arm
> /mach-rtd119x/include/mach/memory.h
> https://github.com/BPI-SINOVOIP/BPI-M4-bsp/blob/master/linux-rtk/arch/arm
> /boot/dts/realtek/rtd119x/rtd-119x-horseradish.dts
>
> As you can see the 0xc000 and 0xf4000 were hardcoded and did not depend on
> SYS_BOOTCODE_MEMSIZE...
> For later SoCs I saw some FIXME(?) comment that area up to 0x100000 was
> reserved due to some Jira ticket and should get fixed? Any insights on what is
> in that memory range causing problems?
>
The problem is solved. (memory overwrite by FW)
Regards,
James
Powered by blists - more mailing lists