On Fri, May 06, 2016 at 02:03:42PM -0400, Jon Masters wrote:
> On 05/06/2016 01:10 PM, Mark Brown wrote:
> > On Fri, May 06, 2016 at 12:20:40PM -0400, Jon Masters wrote:
> > > But is it really worth trying after so long of the right thing not
> > > happening? If anyone really cared about making
On Fri, May 06, 2016 at 12:20:40PM -0400, Jon Masters wrote:
> But is it really worth trying after so long of the right thing not
> happening? If anyone really cared about making general purpose distros boot
> on embedded boards, efforts to compel standards would have happened years
> ago. To do
On Fri, May 6, 2016 at 12:15 PM, Alexander Graf wrote:
>
>
> On 06.05.16 13:03, Grant Likely wrote:
>> On Fri, May 6, 2016 at 2:10 AM, Tom Rini wrote:
>>> On Thu, May 05, 2016 at 10:21:25PM +0200, Alexander Graf wrote:
So what's the goal here? Are we
On 06.05.16 13:03, Grant Likely wrote:
> On Fri, May 6, 2016 at 2:10 AM, Tom Rini wrote:
>> On Thu, May 05, 2016 at 10:21:25PM +0200, Alexander Graf wrote:
>>> So what's the goal here? Are we trying to force GPT on systems whose
>>> vendors never intended them to run with
On Fri, May 6, 2016 at 2:10 AM, Tom Rini wrote:
> On Thu, May 05, 2016 at 10:21:25PM +0200, Alexander Graf wrote:
>> On 05.05.16 17:21, Grant Likely wrote:
>> > On Thu, May 5, 2016 at 12:45 PM, Marcin Juszkiewicz
>> > wrote:
>> >> Recently my
On Thu, May 05, 2016 at 12:44:57PM -0700, Brendan Conoboy wrote:
> All of the best practices people here are talking about appear to be geared
> toward a frictionless connection to the ARM Linux ecosystem. That's
> something many software focused Linaro participants care about, but is that
>
On 05.05.16 17:21, Grant Likely wrote:
> On Thu, May 5, 2016 at 12:45 PM, Marcin Juszkiewicz
> wrote:
>> Recently my angry post on Google+ [1] got so many comments that it was clear
>> that it would be better to move to some mailing list with discussion.
>>
>> As
On 05/05/2016 12:05 PM, Bill Gatliff wrote:
On Thu, May 5, 2016 at 11:50 AM Martin Stadtler
> wrote:
Specifically for the 96boards, the spec is a recommended view, but
its not meant to be constraining, however it does allow
+1
On 5 May 2016 at 20:08, Bill Gatliff wrote:
>
>
> On Thu, May 5, 2016 at 11:50 AM Martin Stadtler <
> martin.stadt...@linaro.org> wrote:
>
>> I would add, that you need to draw a line in the sand between the
>> 'consumer' (don't flame me, I am just struggling to find a
On Thu, May 05, 2016 at 07:47:41PM +0100, Martin Stadtler wrote:
> Specifically for the 96boards, the spec is a recommended view, but its not
> meant to be constraining, however it does allow one to then show a best
> practice, that others can adopt. That's where the RPB comes in to play,
>
I would add, that you need to draw a line in the sand between the
'consumer' (don't flame me, I am just struggling to find a better term)
boards and those that are positioned for production/enterprise. We can't
state that there is only one way that is the right way, that's not fair to
anyone, and
On Thu, May 5, 2016 at 9:29 PM, Mark Brown wrote:
> On Thu, May 05, 2016 at 09:01:05PM +0530, Amit Kucheria wrote:
>> On Thu, May 5, 2016 at 5:15 PM, Marcin Juszkiewicz
>
>> > Solution for existing SoCs is usually adding 1MB of SPI flash during design
>> > phase of device and
On Thu, May 05, 2016 at 06:03:40PM +0100, Grant Likely wrote:
> On Thu, May 5, 2016 at 5:53 PM, Mark Brown wrote:
> > I think there's one other slightly different angle on this which we
> > should address at the same time, creating fresh boot media for a device
> > ("I just
On Thu, May 5, 2016 at 5:53 PM, Mark Brown wrote:
> On Thu, May 05, 2016 at 04:21:59PM +0100, Grant Likely wrote:
>
>> I think we have everything we need to work around the location of the
>> FW boot image without breaking the UEFI spec. The biggest problem is
>> making sure
On Thu, May 05, 2016 at 04:21:59PM +0100, Grant Likely wrote:
> I think we have everything we need to work around the location of the
> FW boot image without breaking the UEFI spec. The biggest problem is
> making sure partitioning tools don't go stomping over required
> firmware data and
On Thu, May 5, 2016 at 4:59 PM, Mark Brown wrote:
> On Thu, May 05, 2016 at 09:01:05PM +0530, Amit Kucheria wrote:
>> On Thu, May 5, 2016 at 5:15 PM, Marcin Juszkiewicz
>
>> > Solution for existing SoCs is usually adding 1MB of SPI flash during design
>> > phase of device and
On Thu, May 05, 2016 at 09:01:05PM +0530, Amit Kucheria wrote:
> On Thu, May 5, 2016 at 5:15 PM, Marcin Juszkiewicz
> > Solution for existing SoCs is usually adding 1MB of SPI flash during design
> > phase of device and store boot loader(s) there. But it is so expensive
> > someone would say when
On Thu, May 5, 2016 at 5:15 PM, Marcin Juszkiewicz
wrote:
> Solution for existing SoCs is usually adding 1MB of SPI flash during design
> phase of device and store boot loader(s) there. But it is so expensive
> someone would say when it is in 10-30 cents range...
On Thu, May 5, 2016 at 12:45 PM, Marcin Juszkiewicz
wrote:
> Recently my angry post on Google+ [1] got so many comments that it was clear
> that it would be better to move to some mailing list with discussion.
>
> As it is about boot loaders and Linaro has engineers
W dniu 05.05.2016 o 15:26, Simon Glass pisze:
This has bugged me for a long time. I see that Rockchip stores its
boot information 64 blocks into the device, allowing room for the
GPT. This seems like the lowest common denominator for the case you
raise. Perhaps ARM could create a set of
Hi,
On 5 May 2016 at 05:45, Marcin Juszkiewicz
wrote:
>
> Recently my angry post on Google+ [1] got so many comments that it was clear
> that it would be better to move to some mailing list with discussion.
>
> As it is about boot loaders and Linaro has engineers
Recently my angry post on Google+ [1] got so many comments that it was
clear that it would be better to move to some mailing list with discussion.
As it is about boot loaders and Linaro has engineers from most of SoC
vendor companies I thought that this will be best one.
1.
22 matches
Mail list logo