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
> some
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 it is about boot loaders and Lin
On 05/05/2016 12:05 PM, Bill Gatliff wrote:
On Thu, May 5, 2016 at 11:50 AM Martin Stadtler
mailto:martin.stadt...@linaro.org>> 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 p
+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 better term)
>> boards
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,
> again
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 store boot loader(s)
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 unpacked my board and
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 partitioning tools don
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 renderin
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 store boot loader(s)
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...
>
> Even 96boards CE specificat
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 from most of SoC vendor
> compa
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 guidelin
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 from most of SoC vendor
> compa
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. https://plus.googl
Changes in cpufreq_06.sh to calculate summatory and
average of frequency measurements.
Signed-off-by: Saul Romero
---
cpufreq/cpufreq_06.sh | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/cpufreq/cpufreq_06.sh b/cpufreq/cpufreq_06.sh
index b323dc8..a25bbd
Changes in cpufreq_06.sh to calculate summatory and
average of frequency measurements.
Signed-off-by: Saul Romero
---
cpufreq/cpufreq_06.sh | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/cpufreq/cpufreq_06.sh b/cpufreq/cpufreq_06.sh
index b323dc8..a25bbd
19 matches
Mail list logo
