loader: fetch all potential boot partitions for device

This also keeps the functionality of hrev53848, which simplifies the
list of disks searched for bootable partitions; however, it maintains
the previous behaviour of platform_get_boot_partitions that continues
to iterate over a list of possible boot partitions, which should
allow finding a bootable BFS partition better in more circumstances.

Particularly, there are numerous reports of the UEFI loader entering
the boot menu despite it finding a bootable partition, which this
should address.

EFI's device_contains_partition is also structured such that it
compares the disk GPT table of the partition the loader is
querying of the EFI disk's GPT table, in the case that there are
multiple disks, as the most reliable method of comparison, with
a generic fallback for non-GPT disks, which will be less reliable.

This reverts commit 0d932a49ada8af6314cd3f20c3f597143f1f555d.

Change-Id: I5fac8608035d56b8bb4dc6c3d495ec6db42fa9b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4149
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>

Revert "loader: fetch all potential boot partitions for boot device."

This reverts commit e888217124fa9fb214ffa790e6a66dca3917f25e.

Change-Id: I06be82ac863f615796d9edc86f5ef903b8123a9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2231
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

boot loader: Wire up net_stack_cleanup()

Add a platform cleanup hook before starting the kernel. The openfirmware
and PXE loaders clean up their network stack there, while the other
loaders currently do nothing.

This closes ticket #6166

Change-Id: I34765892dfd9b2310c6af97c9ff7d414afae49e5
Reviewed-on: https://review.haiku-os.org/c/50
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

loader: fetch all potential boot partitions for boot device.

This allows the loader to skip BFS partitions that don't contain
a bootable system. Useful when you have a BFS data partition that
comes before the system partition when iterated over.

Currently, only the UEFI loader actually returns more than one
possible partition.

Don't store a KMessage in kernel_args for the boot volume, only the buffer address/size.

Pointers in kernel_args are going to be changed to unconditionally use 64-bit
storage (to make kernel_args compatible with both the x86 and x86_64 kernels).
KMessage stores a pointer to its buffer, however since KMessage is used
outside of the boot code it is undesirable to change it to use 64-bit storage
for the pointer as it may add additional overhead on 32-bit builds. Therefore,
only store the buffer address and size and then construct a KMessage from
those in the kernel.

Rework the ConsoleDevice to be a full featured window based console.
Only looses high intensity color from the plain console, but doesn't eat keystrokes, and a 2nd window opens for dprintf stuff.
Only Amiga makes it possible ;-)
http://revolf.free.fr/beos/shots/shot_haiku_loader_amiga_m68k_004.png


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39264 a95241bf-73f2-0310-859d-f6bbb57e9c96

Allocate the IOReq if not done yet at Open() time.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39256 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add a Clear() call to ExecDevice.
Seems there is a lowlevel.library which might be easier to use for keyboard, add some defs for it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39113 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add an ExecDevice class to handle devices using Exec's IORequest calls. Subclass it as KeyboardDevice to use keyboard.device.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39108 a95241bf-73f2-0310-859d-f6bbb57e9c96

s/amicalls/rom_calls/


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38944 a95241bf-73f2-0310-859d-f6bbb57e9c96

Stub out some more of the platform code.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38921 a95241bf-73f2-0310-859d-f6bbb57e9c96

Don't store a KMessage in kernel_args for the boot volume, only the buffer address/size.

Pointers in kernel_args are going to be changed to unconditionally use 64-bit
storage (to make kernel_args compatible with both the x86 and x86_64 kernels).
KMessage stores a pointer to its buffer, however since KMessage is used
outside of the boot code it is undesirable to change it to use 64-bit storage
for the pointer as it may add additional overhead on 32-bit builds. Therefore,
only store the buffer address and size and then construct a KMessage from
those in the kernel.

Rework the ConsoleDevice to be a full featured window based console.
Only looses high intensity color from the plain console, but doesn't eat keystrokes, and a 2nd window opens for dprintf stuff.
Only Amiga makes it possible ;-)
http://revolf.free.fr/beos/shots/shot_haiku_loader_amiga_m68k_004.png


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39264 a95241bf-73f2-0310-859d-f6bbb57e9c96

Allocate the IOReq if not done yet at Open() time.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39256 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add a Clear() call to ExecDevice.
Seems there is a lowlevel.library which might be easier to use for keyboard, add some defs for it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39113 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add an ExecDevice class to handle devices using Exec's IORequest calls. Subclass it as KeyboardDevice to use keyboard.device.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39108 a95241bf-73f2-0310-859d-f6bbb57e9c96

s/amicalls/rom_calls/


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38944 a95241bf-73f2-0310-859d-f6bbb57e9c96

Stub out some more of the platform code.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38921 a95241bf-73f2-0310-859d-f6bbb57e9c96