Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1521742 > unrolled thread
| Started by | Michal Simek <monstr@monstr.eu> |
|---|---|
| First post | 2016-11-14 16:20 +0100 |
| Last post | 2016-11-14 16:20 +0100 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] ARM: zynq: Reserve correct amount of non-DMA RAM Michal Simek <monstr@monstr.eu> - 2016-11-14 16:20 +0100
| From | Michal Simek <monstr@monstr.eu> |
|---|---|
| Date | 2016-11-14 16:20 +0100 |
| Subject | Re: [PATCH] ARM: zynq: Reserve correct amount of non-DMA RAM |
| Message-ID | <sDrd7-eg-7@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
On 10.11.2016 10:57, Nathan Rossi wrote:
> On 10 November 2016 at 19:33, Nathan Rossi <nathan@nathanrossi.com> wrote:
>> On 10 November 2016 at 18:41, Michal Simek <monstr@monstr.eu> wrote:
>>> + Nathan
>>>
>>> 2016-10-31 17:26 GMT+01:00 Kyle Roeschley <kyle.roeschley@ni.com>:
>>>>
>>>> On Zynq, we haven't been reserving the correct amount of DMA-incapable
>>>> RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
>>>> the first 512k). In older kernels, this was masked by the
>>>> memblock_reserve call in arm_memblock_init(). Now, reserve the correct
>>>> amount excplicitly rather than relying on swapper_pg_dir, which is an
>>>> address and not a size anyway.
>>>>
>>>> Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the
>>>> kernel")
>>>>
>>>> Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
>>
>> Tested-by: Nathan Rossi <nathan@nathanrossi.com>
>>
>> For reference this causes problems with DEBUG_RODATA (which changed to
>
> Sorry typo -> s/causes/caused/, as in "... this [incorrect reserving
> of the lower 512K] caused ...".
>
> Regards,
> Nathan
>
>> default yes for CPU_V7 in v4.6) due to padding memory between
>> .head.text and .text, allowing memory below 0x80000 to be available
>> for allocation as non-reserved memory.
Applied to zynq/soc
https://github.com/Xilinx/linux-xlnx/commits/zynq/soc
Thanks,
Michal
Back to top | Article view | linux.kernel
csiph-web