On 05/04/2018 06:20 PM, William Mills wrote:
[explicitly cc'ing boot-arch to see if this solves the TI auth problems]
On 05/04/2018 11:45 AM, Alexander Graf wrote:
On 05/04/2018 04:56 PM, Grant Likely wrote:
On 04/05/2018 15:46, Grant Likely wrote:
On 03/05/2018 09:43, Daniel Thompson wrote:
On Wed, May 02, 2018 at 06:09:15PM -0400, Tom Rini wrote:
On Wed, May 02, 2018 at 10:48:11PM +0100, Grant Likely wrote:
On 02/05/2018 22:24, Tom Rini wrote:
On Wed, May 02, 2018 at 08:40:42PM +0100, Daniel Thompson wrote:
In terms of the restrictions that come from EBBR mandating GPT:
Can we step back, why is EBBR mandating GPT?
I think EBBR should recommend GPT, but allow MBR if the SoC boot
masked
rom conflicts with GPT.
In the early days of GPT there was also a hybrid GPT+MBR scheme that
could list the boot partition in the MBR, but still have a full
GPT. It
isn't pretty, but there is precidence.
How about recommends GPT but allows MBR, no qualifiers. As you note
there's a lot of ways to fiddle around and make it work, probably, on
all of the existing SoCs that do magic offsets. But it's a lot easier
to just allow MBR (what the SoCs were designed to have to live
with) and
guide line that in this case nothing before the first 2MiB be used by
the OS. With a few more spec words around all of that so it's nice
and
formal :)
I'm OK to allow MBR.
I'd be inclined to require that protective partitions be used to defend
the first 2MB though. They are more flexible and are a useful hint to
anyone trying to manually partition.
In a different mail Tom wrote:
And I agree with the high level idea of needing to do something to
protect systems with a magic in-use spot.
There are a couple of extra details.
1. We can't allocate a GUID to discourage an automatic partitioner
from harming a protected partition. We only have the 8-bit
partition type.
Some potential candidates could be 0xA2 (which Altera appear use
for a similar purpose), 0xE7 (wikipedia does not report existing
uses) or 0xF0 (PA-RISC Linux boot loader).
2. Boot ROMs that have built-in support for FAT could be hard coded to
require a specific partition type. >
I think we don't need to worry about #2 to much: systems with built-in
MBR/FAT parsing can use hybrid MBR/GPT to communicate to distros
which partitions are protected because (presumably) they allow
flexibility in placing the first sector of the FAT partition.
Can we start a list of SoCs that have special requirements on the
boot eMMC/SD/USB? It would be useful to see the cross-section of
requirements.
I've created a wiki page to start capturing data. From their we can
decide what scenarios the spec needs to cover.
https://github.com/glikely/ebbr-for-discussion/wiki/Boot-Media-Behaviour
One more thought, are there many new SoCs still using hard coded
offsets instead of an MBR or GPT? It may be that there aren't enough
left for us to care about for EBBR level 0. In which case EBBR Level 0
should support both MBR and GPT (non-hybrid), and then narrow to GPT
only in a future revision.
I don't think we'll be able to move away from MBR anytime soon. For a
quick glimpse on what SoCs need to have blobs installed where, take a
look at our image creation script:
https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM:Live/JeOS/uboot-image-install.in?expand=1
There you can see that we force to MBR (for various reasons) on:
* RPi (reads MBR)
* i.MX 5x/6 (SPL at sector 2)
* Exynos 4/5 (SPL is in sector 1, not sure about newer ones)
* AM905 (SPL in sector 1)
* Kirkwood (SPL in sector 1)
* Zynq(MP) (convenient to store boot.bin on FAT partition in MBR)
I think we should simply dictate that EBBR compliant OSs do not start
any partitions before a sane boundary (1MB? 2MB?). IIRC most
partitioning tools these days won't start partitions before 1MB anyway,
so if we declare 1MB a safe bound we essentially have no work to do.
I did skim (not study) the script. Looks like a good resource of
current board info. I see you are using raw mode for many boards.
Yes, we usually prefer raw mode over anything else, as it's then more
consistent across the different platforms. Special "firmware partitions"
just become maintenance headaches because then suddenly our partitioner
needs adoption and awareness.
I am missing something. If there is only MBR and no GPT then there is
no GUID type for EFI Partition. So how does the firmware find the "EFI
Partition" and the default /efi/boot/boot*.efi file? Does it just use
the partition with boot flag?
There is a special partition ID for the ESP (0xEF), but U-Boot currently
just searches on every partition that's marked bootable.
Alex
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
