On 2016/7/21 16:10, Dave Young wrote:
> On 07/19/16 at 09:07pm, Eric W. Biederman wrote:
>> zhongjiang writes:
>>
>>> From: zhong jiang
>>>
>>> I hit the following question when run trinity in my system. The
>>> kernel is 3.4 version. but the mainline have same question to be
>>> solved. The root
From: zhong jiang
I hit the following question when run trinity in my system. The
kernel is 3.4 version. but the mainline have same question to be
solved. The root cause is the segment size is too large, it can
expand the most of the area or the whole memory, therefore, it
may waste an amount of
From: zhong jiang
I hit the following question when run trinity in my system. The
kernel is 3.4 version. but the mainline have same question to be
solved. The root cause is the segment size is too large, it can
expand the most of the area or the whole memory, therefore, it
may waste an amount of
On Fri, Jul 22, 2016 at 09:38:42AM +0530, Pratyush Anand wrote:
> On 21/07/2016:02:49:36 PM, Geoff Levand wrote:
> > On Thu, 2016-07-21 at 11:50 +0100, Robin Murphy wrote:
> > > The Exynos UART (drivers/tty/serial/samsung.c) is one which comes to
> > > mind as definitely existing, and on arm64 syst
On 21/07/2016:02:49:36 PM, Geoff Levand wrote:
> On Thu, 2016-07-21 at 11:50 +0100, Robin Murphy wrote:
> > The Exynos UART (drivers/tty/serial/samsung.c) is one which comes to
> > mind as definitely existing, and on arm64 systems to boot. The TX
> > register is at offset 0x20 there.
>
> Here's wh
Thiago Jung Bauermann writes:
> Am Freitag, 15 Juli 2016, 18:03:35 schrieb Thiago Jung Bauermann:
>> Am Freitag, 15 Juli 2016, 22:26:09 schrieb Arnd Bergmann:
>> > However, the powerpc specific RTAS runtime services provide a similar
>> > interface to the UEFI runtime support and allow to call in
Hi Thiago,
> So even if not ideal, the solution above is desirable for powerpc. We would
> like to preserve the ability of allowing userspace to pass parameters to the
> OS via the DTB, even if secure boot is enabled.
>
> I would like to turn the above into a proposal:
>
> Extend the syscall a
Am Freitag, 15 Juli 2016, 18:03:35 schrieb Thiago Jung Bauermann:
> Am Freitag, 15 Juli 2016, 22:26:09 schrieb Arnd Bergmann:
> > However, the powerpc specific RTAS runtime services provide a similar
> > interface to the UEFI runtime support and allow to call into
> > binary code from the kernel, w
On Thu, 2016-07-21 at 11:50 +0100, Robin Murphy wrote:
> The Exynos UART (drivers/tty/serial/samsung.c) is one which comes to
> mind as definitely existing, and on arm64 systems to boot. The TX
> register is at offset 0x20 there.
Here's what I came up with.
+ struct data {const char *name;
On 07/21/2016 12:33 PM, Maxim Uvarov wrote:
2016-07-21 18:19 GMT+03:00 Daniel Walker :
There appears to be no code which checks what is or is not System ram,
there is nothing that checks the device tree to see what is IO memory, and
nothing reads /proc/iomem .. So AFAIK nothing cares if it's I
2016-07-21 18:19 GMT+03:00 Daniel Walker :
>
> There appears to be no code which checks what is or is not System ram,
> there is nothing that checks the device tree to see what is IO memory, and
> nothing reads /proc/iomem .. So AFAIK nothing cares if it's IO memory, or
> system ram, and there's n
There appears to be no code which checks what is or is not System ram,
there is nothing that checks the device tree to see what is IO memory,
and nothing reads /proc/iomem .. So AFAIK nothing cares if it's IO
memory, or system ram, and there's no method to config things to skip
any memory in
On 21/07/16 11:31, Mark Rutland wrote:
[...]
+
+> > > > if (*p == 0)
+> > > > > > return 0;
+
+> > > > errno = 0;
+
+> > > > v = strtoull(p, NULL, 0);
+
+> > > > if (errno)
+> > > > > > return 0;
+
>>
On Wed, Jul 20, 2016 at 12:19:21PM -0700, Geoff Levand wrote:
> > > +static uint64_t read_sink(const char *command_line)
> > > +{
> > > +> > > > uint64_t v;
> > > +> > > > const char *p;
> > > +
> > > +> > > > if (arm64_opts.port)
> > > +> > > > > > return arm64_opts.port;
>
On Wed, Jul 20, 2016 at 11:41:35AM +, David Laight wrote:
> From: Dave Young
> > I do not think it is worth to add another syscall for extra fds.
> > We have open(2) as an example for different numbers of arguments
> > already.
>
> Probably works 'by luck' and no one has actually thought about
On 07/19/16 at 09:07pm, Eric W. Biederman wrote:
> zhongjiang writes:
>
> > From: zhong jiang
> >
> > I hit the following question when run trinity in my system. The
> > kernel is 3.4 version. but the mainline have same question to be
> > solved. The root cause is the segment size is too large,
Second kernel should already know that it's not system ram of the
first kernel and in that case makedumpfile will not dump that memory.
Simple way is to pass additional kernel argument to kexec is when you
load the kernel. If it works than you can think how it's better to
pass this parameter. Vari
* Russell King - ARM Linux [160707 03:25]:
> On Wed, Jun 15, 2016 at 11:42:28PM +0100, Russell King - ARM Linux wrote:
> > The boot environment must be setup such that there is room for the
> > uncompressed image (aligned currently to 256 bytes) followed by the
> > size of the compressed image, wi
18 matches
Mail list logo
