On Wed, Oct 10, 2012 at 10:55:44AM +0100, Dave Martin wrote:
> As a side comment, some things such as MAC addresses can be probed and
> set from userspace after kernel boot, assuming that you have a way
> to fetch the device description blob from userspace. If it's accessible
> via MTD I'm guessi
On Tue, Oct 09, 2012 at 12:25:14PM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 08, 2012 at 11:46:49AM +0100, Dave Martin wrote:
>
> > > Yes, but we still need rely on complex code like I2C/MTD to create a
> > > correct DTB, which again puts us back to patching the kernel for that
> > > functionali
On Tue, Oct 09, 2012 at 11:37:06AM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 08, 2012 at 11:24:13AM +0100, Dave Martin wrote:
>
> > Partly this came from some side speculation about whether we could do
> > things like privileged read-only permissions on newer CPUs, for preventing
> > unintended
On Mon, Oct 08, 2012 at 11:46:49AM +0100, Dave Martin wrote:
> > Yes, but we still need rely on complex code like I2C/MTD to create a
> > correct DTB, which again puts us back to patching the kernel for that
> > functionality.
>
> I'm still confused as to where this complexity is coming from.
>
On Mon, Oct 08, 2012 at 11:24:13AM +0100, Dave Martin wrote:
> Partly this came from some side speculation about whether we could do
> things like privileged read-only permissions on newer CPUs, for preventing
> unintended or undesired writes to the kernel's code or read-only data.
Some other arc
On Thu, Oct 04, 2012 at 11:59:07AM -0600, Jason Gunthorpe wrote:
> On Thu, Oct 04, 2012 at 12:36:37PM +0100, Dave Martin wrote:
>
> > OK, so it is supported, but not for ARM, yet. I'm not sure that
> > such a patch would be rejected, since building in a DTB is not
> > really that different from b
On Fri, Oct 05, 2012 at 09:45:00AM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 01, 2012 at 10:06:39AM -0600, Jason Gunthorpe wrote:
> > On Mon, Oct 01, 2012 at 04:39:53PM +0100, Dave Martin wrote:
> > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg
> > > > Align
>
On Mon, Oct 01, 2012 at 10:06:39AM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 01, 2012 at 04:39:53PM +0100, Dave Martin wrote:
> > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> > > LOAD 0x008000 0xc0008000 0x8000 0x372244 0x3a4310 RWE
> > > 0x8000
>
On Thu, Oct 04, 2012 at 12:36:37PM +0100, Dave Martin wrote:
> OK, so it is supported, but not for ARM, yet. I'm not sure that
> such a patch would be rejected, since building in a DTB is not
> really that different from building in a command-line.
Maybe I will be able to look at this in a few m
On Wed, Oct 03, 2012 at 12:44:38PM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 03, 2012 at 11:43:35AM +0100, Dave Martin wrote:
>
> > I'm not sure exactly what you mean by linking the DTB into vmlinux.
> > I don't think this is supported upstream, at least for ARM. It could
> > be done externally
On Wed, Oct 03, 2012 at 11:43:35AM +0100, Dave Martin wrote:
> I'm not sure exactly what you mean by linking the DTB into vmlinux.
> I don't think this is supported upstream, at least for ARM. It could
> be done externally by post-processing vmlinux to add extra sections
> and some boot shim code
[Nicolas, do you have a view on this thread with regard to XIP?]
Hi,
On Tue, Oct 02, 2012 at 11:47:59AM -0600, Jason Gunthorpe wrote:
> On Tue, Oct 02, 2012 at 11:23:46AM +0100, Dave Martin wrote:
>
> > > Well, no, it boots ELFs, so it can boot anything, with any memory
> > > layout. A 2nd stage
On Tue, Oct 02, 2012 at 11:23:46AM +0100, Dave Martin wrote:
> > Well, no, it boots ELFs, so it can boot anything, with any memory
> > layout. A 2nd stage loader would be required to boot standard kernels,
> > that loader would be an ELF with 1 section for the 2nd stage, 1
> > section for the zIma
On Mon, Oct 01, 2012 at 12:35:43PM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 01, 2012 at 06:56:47PM +0100, Dave Martin wrote:
>
> > > > If the kernel is intended to be loadable at a physical address which is
> > > > not statically known, no ELF loader that does not ignore the ELF
> > > > phdr
>
On Mon, Oct 01, 2012 at 06:56:47PM +0100, Dave Martin wrote:
> > > If the kernel is intended to be loadable at a physical address which is
> > > not statically known, no ELF loader that does not ignore the ELF
> > > phdr
> >
> > In this case you can't really use a standard ELF loader to load the
On Mon, Oct 01, 2012 at 10:06:39AM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 01, 2012 at 04:39:53PM +0100, Dave Martin wrote:
>
> > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> > > LOAD 0x008000 0xc0008000 0x8000 0x372244 0x3a4310 RWE
> > > 0x800
On Mon, Oct 01, 2012 at 04:39:53PM +0100, Dave Martin wrote:
> > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> > LOAD 0x008000 0xc0008000 0x8000 0x372244 0x3a4310 RWE 0x8000
>
> Not related directly to your patch, but I wonder why we don't we see
> se
On Sun, Sep 30, 2012 at 05:21:16PM -0600, Jason Gunthorpe wrote:
> The standard linux asm-generic/vmlinux.lds.h already supports this,
> and it seems other architectures do as well.
>
> The goal is to create an ELF file that has correct program headers. We
> want to see the VirtAddr be the runtime
The standard linux asm-generic/vmlinux.lds.h already supports this,
and it seems other architectures do as well.
The goal is to create an ELF file that has correct program headers. We
want to see the VirtAddr be the runtime address of the kernel with the
MMU turned on, and PhysAddr be the physical
19 matches
Mail list logo
