On Thu, 23 May 2019, Atish Patra wrote:
> I have sent out a v3 incorporating most of your suggestions. If ARM
> maintainers agree, we can move both the headers to a common place.
>
> Just FYI: Marek also suggested to add unified support Image.gz for both U-Boot
> & RISC-V in U-Boot. I am working
On 5/16/19 9:20 AM, Paul Walmsley wrote:
+ ARM64 maintainers, Tom, Marek
Hi Atish,
On Mon, 13 May 2019, Atish Patra wrote:
On 5/13/19 5:40 PM, Paul Walmsley wrote:
On Mon, 13 May 2019, Atish Patra wrote:
On 5/13/19 5:09 PM, Paul Walmsley wrote:
What are the semantics of those reserved fie
On 5/17/19 10:39 AM, Paul Walmsley wrote:
On Wed, 1 May 2019, Atish Patra wrote:
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot flows.
Add a PE/COFF compliant image header that boot loaders can parse and
dire
On Wed, 1 May 2019, Atish Patra wrote:
> Currently, last stage boot loaders such as U-Boot can accept only
> uImage which is an unnecessary additional step in automating boot flows.
>
> Add a PE/COFF compliant image header that boot loaders can parse and
> directly load kernel flat Image. The e
+ ARM64 maintainers, Tom, Marek
Hi Atish,
On Mon, 13 May 2019, Atish Patra wrote:
> On 5/13/19 5:40 PM, Paul Walmsley wrote:
> > On Mon, 13 May 2019, Atish Patra wrote:
> > > On 5/13/19 5:09 PM, Paul Walmsley wrote:
> > >
> > > > What are the semantics of those reserved fields?
> > >
> > > +st
On 5/13/19 5:40 PM, Paul Walmsley wrote:
On Mon, 13 May 2019, Atish Patra wrote:
On 5/13/19 5:09 PM, Paul Walmsley wrote:
What are the semantics of those reserved fields?
+struct riscv_image_header {
+ u32 code0;
+ u32 code1;
+ u64 text_offset;
+ u64 image_size;
+
On Mon, 13 May 2019, Atish Patra wrote:
> On 5/13/19 5:09 PM, Paul Walmsley wrote:
>
> > What are the semantics of those reserved fields?
>
> +struct riscv_image_header {
> + u32 code0;
> + u32 code1;
> + u64 text_offset;
> + u64 image_size;
> + u64 res1;
> + u64 res2;
>
On 5/13/19 5:09 PM, Paul Walmsley wrote:
On Mon, 13 May 2019, Atish Patra wrote:
On 5/13/19 3:31 PM, Paul Walmsley wrote:
On Wed, 1 May 2019, Atish Patra wrote:
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot
On Mon, 13 May 2019, Atish Patra wrote:
> On 5/13/19 3:31 PM, Paul Walmsley wrote:
> > On Wed, 1 May 2019, Atish Patra wrote:
> >
> > > Currently, last stage boot loaders such as U-Boot can accept only
> > > uImage which is an unnecessary additional step in automating boot flows.
> > >
> > > Add
On 5/13/19 3:31 PM, Paul Walmsley wrote:
On Wed, 1 May 2019, Atish Patra wrote:
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot flows.
Add a PE/COFF compliant image header that boot loaders can parse and
direct
On Wed, 1 May 2019, Atish Patra wrote:
> Currently, last stage boot loaders such as U-Boot can accept only
> uImage which is an unnecessary additional step in automating boot flows.
>
> Add a PE/COFF compliant image header that boot loaders can parse and
> directly load kernel flat Image. The exi
On Wed, May 01, 2019 at 12:56:07PM -0700, Atish Patra wrote:
> Currently, last stage boot loaders such as U-Boot can accept only
> uImage which is an unnecessary additional step in automating boot flows.
>
> Add a PE/COFF compliant image header that boot loaders can parse and
> directly load kern
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot flows.
Add a PE/COFF compliant image header that boot loaders can parse and
directly load kernel flat Image. The existing booting methods will continue
to work as it
13 matches
Mail list logo
