linux-kernel - RE: [PATCH 2/2] MIPS: DTS: img: add device tree for Marduk board

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 Oct 2016 08:49:34 +0000
From:   James Hartley <James.Hartley@...tec.com>
To:     Rahul Bedarkar <Rahul.Bedarkar@...tec.com>,
        Rob Herring <robh@...nel.org>
CC:     Ralf Baechle <ralf@...ux-mips.org>,
        Mark Rutland <mark.rutland@....com>,
        "linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] MIPS: DTS: img: add device tree for Marduk board

Hi Rahul,

> -----Original Message-----
> From: Rahul Bedarkar
> Sent: 13 October 2016 08:02
> To: Rob Herring
> Cc: Ralf Baechle; Mark Rutland; James Hartley; linux-mips@...ux-mips.org;
> devicetree@...r.kernel.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH 2/2] MIPS: DTS: img: add device tree for Marduk board
> 
> Hi,
> 
> On Monday 10 October 2016 07:51 PM, Rob Herring wrote:
> >> +
> >> +	memory {
> >
> > Is 0 the actual base, or that gets filled in by bootloader? If the
> > formet, add unit address.
> >
> 
> Bootloader (uboot) can override or fixup memory node. But with version of
> bootloader I tested with, base address is hardcoded to 0 and only size may
> get changed. But since booloader can override or fixup memory node, I
> assume we don't add unit address in this case.
> 
> >> +		device_type = "memory";
> >> +		reg =  <0x00000000 0x08000000>;
> 
> I now realized that size is incorrectly specified in memory node. It should be
> 256MB and not 128MB. I will fix this in v2.

This is board dependent, and since you have already explained that the boot loader is expected to configure this, I would recommend leaving it at 128MB (which I believe is the size of the smallest DDR part in use on existing boards). This would mean that if for some reason the boot loader did not adjust the settings, it would still boot on all currently known boards.

James.

> 
> Thanks,
> Rahul