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.google.com/u/0/+MarcinJuszkiewicz/posts/J79qhndV6FY
All started when I got Pine64 board (based on Allwinner A64 SoC) and had
same issue as on several boards in past - boot loader written in some
random place on SD card.
Days where people used Texas Instruments SoC chips were great - in-cpu
boot loader knew how to read MBR partition table and was able to load
1st stage boot loader (called MLO) from it as long it was FAT filesystem.
GPU used by Raspberry/Pi is able to read MBR, finds 1st partition and
reads firmware files from there as long it is FAT.
Chromebooks have some SPI flash to keep boot loaders and use GPT
partitioning to find where from load kernel (or another boot loader).
And then we have all those boards where vendors decided that SPI flash
for boot loader is too expensive so it will be read from SD card
instead. From any random place of course...
Then we have distributions. And instead of generating bunch of images
per board they want to make one clean image which will be able to handle
as much as possible.
If there are UEFI machines on a list of supported ones then GPT
partitioning will be used, boot loader will be stored in "EFI system
area" and it boots. This is how AArch64 SBSA/SBBR machines work.
But there are also all those U-Boot (or fastboot/redboot/whateverboot)
ones. They are usually handled by taking image from previous stage and
adding boot loader(s) by separate script. And this is where "fun" starts...
GPT takes first 17KB of storage media as it allow to store information
about 128 partitions. Sure, no one is using so many on such devices but
still space is reserved.
But most of chips expects boot loader(s) to be stored:
- right after MBR
- from 1KB
- from 8KB
- any other random place
So scripts start to be sets of magic written to handle all those SoCs...
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 specification totally ignored that fact while it could
be a way of showing how to make popular board. Instead it became
yet-another-board-to-laugh (EE spec did not improve much).
Is there a way to get it improved? At least for new designs?
+1
On 5 May 2016 at 20:08, Bill Gatliff <bgat(a)billgatliff.com> wrote:
>
>
> On Thu, May 5, 2016 at 11:50 AM Martin Stadtler <
> martin.stadtler(a)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 and those that are positioned for production/enterprise.
>>
>
> One way to draw the line is whether the board is delivered to be used
> as-is, vs. with the expectation of further development activities that will
> change the work product that shipped with the board.
>
> In the first case, all you care is that it works when it leaves the dock.
> In the latter case, you care more that it can't be easily broken later.
>
> That's a pretty big difference in my experience.
>
> b.g.
> --
>
> Bill Gatliff
> Embedded Linux training and consulting
> bgat(a)billgatliff.com
> (309) 453-3421
>
--
Martin Stadtler
Director, Enterprise Group
Linaro Ltd
mobile: +44.7492180779
IRC: martinst@#linaro on irc.freenode.ne <http://irc.freenode.net/>t
Hello,
Summary: Your SSH username on https://android-review.linaro.org will
now match Linaro username (first.last) after the next login. You local
repository clones need to be updated for new username.
Detailed description:
https://android-review.linaro.org was the first Gerrit server in
Linaro, when there were no central LDAP user database yet. As a result,
there were free-form SSH usernames used, instead of the later standard
first.last as used on all the other Gerrit servers. This inconsistency
was a subject of background concern for Systems team, but of course not
something having enough priority to "fix". However, Gerrit 2.12.2
upgrade started tonight uncovered following issue: Gerrit tries to
synchronize its SSH username setting with LDAP, and fails, as Gerrits
own rules disallow changing of username. The symptom of this is error
"Authentication temporary unavailable" when a user with "old" SSH
username tries to login via browser.
While this can be classified as a Gerrit bug (and previous versions
were smart enough), we'll unlikely find any timely solution to keep
things as they are. So, it makes sense to take a chance of cleaning up
username and making this server follow standard username conventions.
Consequently:
1. All usernames which don't match "first.last" pattern are reset.
2. If you are affected, you won't be able to perform SSH operations
(like git clone/push) until you login via web interface.
3. On the next login via web interface, it will be set to LDAP's
"first.last" value.
4. You will need to update remotes of your existing git clones to new
username (or alternatively, re-clone).
5. If you already use "first.last" SSH username, you're unaffected.
The list of users affected is given below. While it seems long,
majority of enrties there are for people no longer at Linaro, or
for community accounts (which didn't work since we switched to LDAP
anyway). If you need further assistance, please open a ticket at
https://servicedesk.linaro.org/servicedesk/customer/portal/4 .
Thanks,
Paul
username:Ng
username:pfefferz
username:asac
username:james_w
username:fgiff
username:jserv
username:mabac
username:deeptik
username:cyang
username:mpoirier
username:ndec
username:mwaddel
username:mansson
username:Sachin
username:vishalbhoj
username:suapapa
username:fabo
username:pabhishek
username:cnxsoft
username:amitdanielk
username:patrikryd
username:sangwook
username:ericm
username:pundiramit
username:glandium
username:eazyigz
username:tixy
username:danilo
username:john
username:nytowl
username:tony_tu
username:Sangwook
username:StefanEkenberg
username:uichi
username:plars
username:zyga
username:ruppi
username:ebenpor
username:jhkim
username:Annamalai
username:markoncomputer
username:Claude
username:tianhongwang
username:rchand00
username:omarrmz
username:aviksil
username:nvl1109
username:a0132810
username:pelya
username:krtaylor
username:developer4563
username:yusufbu
username:dzinman
username:arussello
username:mdupuy
username:williamcharles
username:aorth
username:lanaczko
username:rmcc
username:kcrudup
username:kelvin
username:angelsl
username:unixmanlinuxboy
username:Quiter
username:sourxsunny
username:pbeeler
username:anmar
username:wucongdonglai
username:bambi
username:rperier
username:sgt
username:roalex
username:vishveshwarbhat
username:therbom
username:rajagopalvenkat
username:winner00
username:ramesh
username:abelloni
username:sparksco
username:fahadkdi
username:ryanharkin
username:axelfagerstedt
username:nocoast
username:milo
username:fcarpenter
username:hongbozhang
username:fahadk
username:pelya2
username:janjic
username:dpervushin
username:qoowater
username:cerial
username:tinojantony
username:stephaneeee
username:kishoreboddu
username:nuclearmistake
username:SanjasdfsafsffaySinghsdfasfRawat
username:donvigo
username:tinojgit
username:afarah
username:mechmetal
username:akbennett
username:c
username:sikuner
username:wasungkim
username:stevanr
username:deqiang
username:anilkumar
username:willnewton
username:codeart
username:lrabiet
username:Bintian
username:bintian
username:vishalbhoj2
username:tusharbehera
username:jbergsag
username:tgall
username:amitkhare
username:neo
username:paramanands
username:sumit
username:danielt
username:help
username:XavierHsu
username:Serban
username:Z
username:koenkooi
(127 rows)
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
One of the goals of RPB is to follow that our changes go back
upstream. For the next RPB release, a more polished report is planned.
But to get things started, here's a sample - and to use as baseline to
compare progress for the 16.06 release. The list of packages is
collected from db410/alip image with distrodelta script[1]. This lists
the packages that do not become from Debian (Jessie release) or Debian
backports:
New packages not in Debian:
96boards-artwork: 0.6-0linaro1
96boards-tools: 0.5
optee-client: 1.0.1+git5+g89f25ce-1.linarojessie.1
glshim: 0.41+git20150911.42a7739-0.linarojessie.1
linaro-artwork: 0.6-0linaro1
linaro-default-settings: 0.3-0linaro1
linaro-overlay: 1112.8
wcnss-config: 1.8
Changed packages:
alsa-lib: 1.0.28-1+linaro1.linarojessie.1
* add UCM config file for HDMI and HiFi on DB410c
* add UCM config file for HDMI on IFC6410
chromium-browser: 47.0.2526.16-1.6.linarojessie.1
* seccomp and namespace fixes
* patches to compile on arm64/armhf
firmware-nonfree: 20160110-1.linarojessie.1
* ti-connectivity (updates for HiKey):
- Include wl18xx-fw-4 firmware
- Add TIInit_11.8.32.bts for bluetooth support
isc-dhcp: 4.3.3-8~linaro1
* Reverting requirement for debhelper >= 9.20151220
* Upload to make it work with latest systemd:
- https://bugs.96boards.org/show_bug.cgi?id=271
linux: 4.4.0.linaro.104-1.linarojessie.1
* See kernel changes report (TBD)
No-changes Backports:
apparmor: 2.10-2.linarojessie.1
binutils: 2.25.90.20160101-1.linarojessie.1
gdb: 7.10-1.linarojessie.1
gyp: 0.1+20150913git1f374df9-1.linarojessie.1
java-common: 2:1.8-53.linarojessie.1
nodejs: 4.2.2~dfsg-1.1.linarojessie.1
openssl: 1.0.2d-1.linarojessie.1
systemd: 228-2.4.linarojessie.3
sysvinit: 2.88dsf-59.2.linarojessie.1
util-linux: 2.27.1-1.linarojessie.1
x265: 1.7-4~bpo8+1.linarojessie.1
xorg: 1:7.7+11.linarojessie.1
xorg-server: 2:1.17.3-2.linarojessie.2
xserver-xorg-video-fbdev: 1:0.4.4-1.linarojessie.1
xserver-xorg-video-freedreno: 1.4.0-1.linarojessie.1
[1] https://github.com/suihkulokki/distrodelta with command
distrodelta -o Debian 'Debian Backports'