On 27 Mar 2013 01:31, Graeme Russ graeme.r...@gmail.com wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 06:09 PM, Graeme Russ wrote:
I've had a quick glance at the U-Boot source and I think the newer
'FIT' image may be a better
On 27 Mar 2013 03:24, Jon jdisn...@gmail.com wrote:
I feel we gain the greatness of unified kernel but we make separate
images that handle the u-boot quirks. We push down the stack so to speak.
The only diff of each image being load addr's.
The exynos5 kernel requires FIT images, so an extra
On 27 Mar 2013 03:38, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 26 Mar 2013, Brendan Conoboy wrote:
We could create a number of uboot headers. Then after loading the
default
uImage, load a separate uboot header overwriting the first 64 bytes of
RAM.
Please don't engage in those
On 27 Mar 2013 05:12, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 08:38 PM, Nicolas Pitre wrote:
If uImage is a problem, just don't use it, period. Problem solved. All
the targets supported by the unified kernel are recent enough to have
bootz support in their U-Boot source.
On Wed, 27 Mar 2013, Graeme Russ wrote:
Hi Nicolas
On Wed, Mar 27, 2013 at 2:29 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Wed, 27 Mar 2013, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 06:09 PM, Graeme
On Tue, 26 Mar 2013, Brendan Conoboy wrote:
On 03/26/2013 08:38 PM, Nicolas Pitre wrote:
If uImage is a problem, just don't use it, period. Problem solved. All
the targets supported by the unified kernel are recent enough to have
bootz support in their U-Boot source. Please use that.
Hi Nico, Graeme,
On 03/27/2013 11:01 AM, Nicolas Pitre wrote:
On Wed, 27 Mar 2013, Graeme Russ wrote:
Using FIT you should be able to bundle a unified uImage, initramfs and
FDT. You can then edit the FDT within U-Boot for device specific
parameters (like load address).
IMHO this is the
On Wed, 27 Mar 2013, Peter Robinson wrote:
On 27 Mar 2013 03:24, Jon jdisn...@gmail.com wrote:
The problem statement is different u-boot are different, and we cannot
have unified images.
Yes we can, we just need a tool to adjust the uboot bit like Han's tool for
the A1x devices. Its less
On Wed, 27 Mar 2013, Jon Masters wrote:
Prior to Brendan sending that mail last night, we had an internal RH
meeting wherein this topic came up (and precipitated the email). I
explained already in that and will repeat here that the ARM kernel is
already relocatable. It has only two major
On Wed, Mar 27, 2013 at 3:15 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Wed, 27 Mar 2013, Peter Robinson wrote:
On 27 Mar 2013 03:24, Jon jdisn...@gmail.com wrote:
The problem statement is different u-boot are different, and we cannot
have unified images.
Yes we can, we just need a tool
On 03/27/2013 11:26 AM, Nicolas Pitre wrote:
On Wed, 27 Mar 2013, Jon Masters wrote:
Prior to Brendan sending that mail last night, we had an internal RH
meeting wherein this topic came up (and precipitated the email). I
explained already in that and will repeat here that the ARM kernel is
On Wed, 27 Mar 2013, Peter Robinson wrote:
On Wed, Mar 27, 2013 at 3:15 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Wed, 27 Mar 2013, Peter Robinson wrote:
On 27 Mar 2013 03:24, Jon jdisn...@gmail.com wrote:
The problem statement is different u-boot are different, and we cannot
have
On Wed, 27 Mar 2013, Jon Masters wrote:
On 03/27/2013 11:26 AM, Nicolas Pitre wrote:
On Wed, 27 Mar 2013, Jon Masters wrote:
Prior to Brendan sending that mail last night, we had an internal RH
meeting wherein this topic came up (and precipitated the email). I
explained already in
Through Fedora 18 GA we've had a one-to-one mapping between the SoC and
the kernel rpm. Likewise, we produced a different filesystem image for
each SoC (EG, a highbank image, a panda image, a trimslice image, etc).
Since then the unified kernel in 3.7 and beyond has introduced the
ability to
Hi Brendan,
I may be way of the mark with my suggestions as I am not that familiar
with ARM, but here goes:
On Wed, Mar 27, 2013 at 10:39 AM, Brendan Conoboy b...@redhat.com wrote:
The trouble is, there is no unified $ubootAddress available. The pandaboard
uses 0x80008000, highbank and tegra
On 03/26/2013 04:49 PM, Graeme Russ wrote:
4. Relocatable kernel (like x86)
If I understand correctly it already is relocatable. This is simply the
address that uboot is instructed to load the kernel into memory at.
5. Have U-Boot process uImage to adjust for load location (U-Boot
already
Hi Brendan,
On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 04:49 PM, Graeme Russ wrote:
4. Relocatable kernel (like x86)
If I understand correctly it already is relocatable. This is simply the
address that uboot is instructed to load the kernel into
On 03/26/2013 05:04 PM, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 04:49 PM, Graeme Russ wrote:
4. Relocatable kernel (like x86)
If I understand correctly it already is relocatable. This is simply the
address that
Hi Brendan,
On Wed, Mar 27, 2013 at 11:20 AM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 05:04 PM, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 04:49 PM, Graeme Russ wrote:
4. Relocatable kernel (like
On 03/26/2013 05:26 PM, Graeme Russ wrote:
I just realised I got this a bit wrong - mkimage make a U-Boot image
with a header which contains the kernel load address. Not sure what
mkimage does to the Linux kernel binary itself
The kernel binary is left intact. Only a 64 byte header is
Hi Brendan,
On Wed, Mar 27, 2013 at 11:34 AM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 05:26 PM, Graeme Russ wrote:
I just realised I got this a bit wrong - mkimage make a U-Boot image
with a header which contains the kernel load address. Not sure what
mkimage does to the Linux
I feel we gain the greatness of unified kernel but we make separate images
that handle the u-boot quirks. We push down the stack so to speak. The only
diff of each image being load addr's.
The exynos5 kernel requires FIT images, so an extra dimension of
complexity. Well, at least for chromebook.
On Wed, 27 Mar 2013, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 06:09 PM, Graeme Russ wrote:
I've had a quick glance at the U-Boot source and I think the newer
'FIT' image may be a better path to follow. In
On Tue, 26 Mar 2013, Brendan Conoboy wrote:
We could create a number of uboot headers. Then after loading the default
uImage, load a separate uboot header overwriting the first 64 bytes of RAM.
Please don't engage in those senseless games just to work around a
stupid restriction of the
On Wed, 27 Mar 2013, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 11:20 AM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 05:04 PM, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 04:49 PM,
Hi Nicolas
On Wed, Mar 27, 2013 at 2:29 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Wed, 27 Mar 2013, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy b...@redhat.com wrote:
On 03/26/2013 06:09 PM, Graeme Russ wrote:
I've had a quick glance at the
On 03/26/2013 08:38 PM, Nicolas Pitre wrote:
If uImage is a problem, just don't use it, period. Problem solved. All
the targets supported by the unified kernel are recent enough to have
bootz support in their U-Boot source. Please use that.
Is bootz supported everywhere we need? I was under
27 matches
Mail list logo
