"Summary: [...] if you want to have your board supported then spend some time on mainlining your changes/drivers. And then come to us."
Full article: http://marcin.juszkiewicz.com.pl/2015/11/10/fedora-23-and-unsupported-armaar...
On 10 November 2015 at 23:51, Kevin Hilman khilman@kernel.org wrote:
"Summary: [...] if you want to have your board supported then spend some time on mainlining your changes/drivers. And then come to us."
Full article: http://marcin.juszkiewicz.com.pl/2015/11/10/fedora-23-and-unsupported-armaar...
It says: Then we have bootloaders. Hikey can be flashed with UEFI but (according to bootloader install documentation) you need to keep partitions in some magic way. Where is “there has to be one ef00 type partition formatted with FAT” as it is with other UEFI powered machines? Dragonboard 410c uses fastboot ;(
But it's incorrect on HiKey.
Command (m for help): p
Disk /dev/mmcblk0: 7.3 GiB, 7818182656 bytes, 15269888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 2CB85345-6A91-4043-8203-723F0D28FBE8
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
The script of generating partition table is in below.
linux) dd if=/dev/zero of=${TEMP_FILE} bs=${SECTOR_SIZE} count=${SECTOR_NUMBER} sgdisk -U 2CB85345-6A91-4043-8203-723F0D28FBE8 -v ${TEMP_FILE} #[1: vrl: 1M-2M] sgdisk -n 1:0:+1M -t 1:0700 -u 1:496847AB-56A1-4CD5-A1AD-47F4ACF055C9 -c 1:"vrl" ${TEMP_FILE} #[2: vrl_backup: 2M-3M] sgdisk -n 2:0:+1M -t 2:0700 -u 2:61A36FC1-8EFB-4899-84D8-B61642EFA723 -c 2:"vrl_backup" ${TEMP_FILE} #[3: mcuimage: 3M-4M] sgdisk -n 3:0:+1M -t 3:0700 -u 3:65007411-962D-4781-9B2C-51DD7DF22CC3 -c 3:"mcuimage" ${TEMP_FILE} #[4: fastboot: 4M-12M] sgdisk -n 4:0:+8M -t 4:EF02 -u 4:496847AB-56A1-4CD5-A1AD-47F4ACF055C9 -c 4:"fastboot" ${TEMP_FILE} #[5: nvme: 12M-14M] sgdisk -n 5:0:+2M -t 5:0700 -u 5:00354BCD-BBCB-4CB3-B5AE-CDEFCB5DAC43 -c 5:"nvme" ${TEMP_FILE} #[6: boot: 14M-78M] sgdisk -n 6:0:+64M -t 6:EF00 -u 6:5C0F213C-17E1-4149-88C8-8B50FB4EC70E -c 6:"boot" ${TEMP_FILE} #[7: reserved: 78M-334M] sgdisk -n 7:0:+256M -t 7:0700 -u 7:BED8EBDC-298E-4A7A-B1F1-2500D98453B7 -c 7:"reserved" ${TEMP_FILE} #[8: cache: 334M-590M] sgdisk -n 8:0:+256M -t 8:8301 -u 8:A092C620-D178-4CA7-B540-C4E26BD6D2E2 -c 8:"cache" ${TEMP_FILE} #[9: system: 590M-End] sgdisk -n -E -t 9:0700 -u 9:FC56E345-2E8E-49AE-B2F8-5B9D263FE377 -c 9:"system" ${TEMP_FILE} ;;
Regards Haojian
On 11 November 2015 at 04:32, Haojian Zhuang haojian.zhuang@linaro.org wrote:
On 10 November 2015 at 23:51, Kevin Hilman khilman@kernel.org wrote:
"Summary: [...] if you want to have your board supported then spend some time on mainlining your changes/drivers. And then come to us."
Full article: http://marcin.juszkiewicz.com.pl/2015/11/10/fedora-23-and-unsupported-armaar...
It says: Then we have bootloaders. Hikey can be flashed with UEFI but (according to bootloader install documentation) you need to keep partitions in some magic way. Where is “there has to be one ef00 type partition formatted with FAT” as it is with other UEFI powered machines? Dragonboard 410c uses fastboot ;(
But it's incorrect on HiKey.
Command (m for help): p
Disk /dev/mmcblk0: 7.3 GiB, 7818182656 bytes, 15269888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 2CB85345-6A91-4043-8203-723F0D28FBE8
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
The script of generating partition table is in below.
linux) dd if=/dev/zero of=${TEMP_FILE} bs=${SECTOR_SIZE} count=${SECTOR_NUMBER} sgdisk -U 2CB85345-6A91-4043-8203-723F0D28FBE8 -v ${TEMP_FILE} #[1: vrl: 1M-2M] sgdisk -n 1:0:+1M -t 1:0700 -u 1:496847AB-56A1-4CD5-A1AD-47F4ACF055C9 -c 1:"vrl" ${TEMP_FILE} #[2: vrl_backup: 2M-3M] sgdisk -n 2:0:+1M -t 2:0700 -u 2:61A36FC1-8EFB-4899-84D8-B61642EFA723 -c 2:"vrl_backup" ${TEMP_FILE} #[3: mcuimage: 3M-4M] sgdisk -n 3:0:+1M -t 3:0700 -u 3:65007411-962D-4781-9B2C-51DD7DF22CC3 -c 3:"mcuimage" ${TEMP_FILE} #[4: fastboot: 4M-12M] sgdisk -n 4:0:+8M -t 4:EF02 -u 4:496847AB-56A1-4CD5-A1AD-47F4ACF055C9 -c 4:"fastboot" ${TEMP_FILE} #[5: nvme: 12M-14M] sgdisk -n 5:0:+2M -t 5:0700 -u 5:00354BCD-BBCB-4CB3-B5AE-CDEFCB5DAC43 -c 5:"nvme" ${TEMP_FILE} #[6: boot: 14M-78M] sgdisk -n 6:0:+64M -t 6:EF00 -u 6:5C0F213C-17E1-4149-88C8-8B50FB4EC70E -c 6:"boot" ${TEMP_FILE} #[7: reserved: 78M-334M] sgdisk -n 7:0:+256M -t 7:0700 -u 7:BED8EBDC-298E-4A7A-B1F1-2500D98453B7 -c 7:"reserved" ${TEMP_FILE} #[8: cache: 334M-590M] sgdisk -n 8:0:+256M -t 8:8301 -u 8:A092C620-D178-4CA7-B540-C4E26BD6D2E2 -c 8:"cache" ${TEMP_FILE} #[9: system: 590M-End] sgdisk -n -E -t 9:0700 -u 9:FC56E345-2E8E-49AE-B2F8-5B9D263FE377 -c 9:"system" ${TEMP_FILE} ;;
Regards Haojian _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On 11 November 2015 at 14:35, Koen Kooi koen.kooi@linaro.org wrote:
On 11 November 2015 at 04:32, Haojian Zhuang haojian.zhuang@linaro.org wrote:
On 10 November 2015 at 23:51, Kevin Hilman khilman@kernel.org wrote:
"Summary: [...] if you want to have your board supported then spend some time on mainlining your changes/drivers. And then come to us."
Full article: http://marcin.juszkiewicz.com.pl/2015/11/10/fedora-23-and-unsupported-armaar...
It says: Then we have bootloaders. Hikey can be flashed with UEFI but (according to bootloader install documentation) you need to keep partitions in some magic way. Where is “there has to be one ef00 type partition formatted with FAT” as it is with other UEFI powered machines? Dragonboard 410c uses fastboot ;(
But it's incorrect on HiKey.
Command (m for help): p
Disk /dev/mmcblk0: 7.3 GiB, 7818182656 bytes, 15269888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 2CB85345-6A91-4043-8203-723F0D28FBE8
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Other partitions are useless to debian build. If there's an accurate requirement on partition table, we could make a new partition table for debian build. But we don't have this requirement up to now.
On 10 November 2015 at 17:51, Kevin Hilman khilman@kernel.org wrote:
"Summary: [...] if you want to have your board supported then spend some time on mainlining your changes/drivers. And then come to us."
Full article: http://marcin.juszkiewicz.com.pl/2015/11/10/fedora-23-and-unsupported-armaar...
I'll reword as: if you want to have your board officially supported by RedHat (or put your favorite distro here), the requirement is to have your board supported mainline, because it's their policy.
AFAICT, nothing prevent to have a community effort and build a Fedora Remix (or CentOS [1]). You can switch the kernel, when/if mainline will be on par, feature wise.
[1] http://blog.chris.tylers.info/index.php?/archives/280-Running-LEAP-Portable-...
On 11/11/15 06:35, Koen Kooi wrote:
On 11 November 2015 at 04:32, Haojian Zhuang haojian.zhuang@linaro.org wrote:
On 10 November 2015 at 23:51, Kevin Hilman khilman@kernel.org wrote:
"Summary: [...] if you want to have your board supported then spend some time on mainlining your changes/drivers. And then come to us."
Full article: http://marcin.juszkiewicz.com.pl/2015/11/10/fedora-23-and-unsupported-armaar...
It says: Then we have bootloaders. Hikey can be flashed with UEFI but (according to bootloader install documentation) you need to keep partitions in some magic way. Where is “there has to be one ef00 type partition formatted with FAT” as it is with other UEFI powered machines? Dragonboard 410c uses fastboot ;(
But it's incorrect on HiKey.
Command (m for help): p
Disk /dev/mmcblk0: 7.3 GiB, 7818182656 bytes, 15269888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 2CB85345-6A91-4043-8203-723F0D28FBE8
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Isn't that a consequence of loading UEFI itself from the same media (eMMC) that UEFI loads the OS?
I think we might always need at least one partition configured to "protect" the firmware; we need to be able to direct an off-the-shelf (i.e. does not have any special knowledge about hikey) OS installer not to mess with it.
What is the best way to mark such a partition to encourage installers to do that by default?
Daniel.
On Wed, Nov 11, 2015 at 01:50:15PM +0000, Daniel Thompson wrote:
On 11/11/15 06:35, Koen Kooi wrote:
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Isn't that a consequence of loading UEFI itself from the same media (eMMC) that UEFI loads the OS?
I think we might always need at least one partition configured to "protect" the firmware; we need to be able to direct an off-the-shelf (i.e. does not have any special knowledge about hikey) OS installer not to mess with it.
What is the best way to mark such a partition to encourage installers to do that by default?
Most installers won't touch anything they don't recognise, but it could be clearer here. Just using "Microsoft basic data" as a partition type doesn't tell anybody anything useful here. From reading https://en.wikipedia.org/wiki/GUID_Partition_Table, I'd suggest maybe using Reserved (8DA63339-0007-60C0-C436-083AC8230908) or (maybe better) picking/registering a different partition type altogether.
Cheers,
On Wed, Nov 11, 2015 at 4:43 AM, Haojian Zhuang haojian.zhuang@linaro.org wrote:
On 11 November 2015 at 14:35, Koen Kooi koen.kooi@linaro.org wrote:
On 11 November 2015 at 04:32, Haojian Zhuang haojian.zhuang@linaro.org wrote:
On 10 November 2015 at 23:51, Kevin Hilman khilman@kernel.org wrote:
"Summary: [...] if you want to have your board supported then spend some time on mainlining your changes/drivers. And then come to us."
Full article: http://marcin.juszkiewicz.com.pl/2015/11/10/fedora-23-and-unsupported-armaar...
It says: Then we have bootloaders. Hikey can be flashed with UEFI but (according to bootloader install documentation) you need to keep partitions in some magic way. Where is “there has to be one ef00 type partition formatted with FAT” as it is with other UEFI powered machines? Dragonboard 410c uses fastboot ;(
But it's incorrect on HiKey.
Command (m for help): p
Disk /dev/mmcblk0: 7.3 GiB, 7818182656 bytes, 15269888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 2CB85345-6A91-4043-8203-723F0D28FBE8
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Other partitions are useless to debian build. If there's an accurate requirement on partition table, we could make a new partition table for debian build. But we don't have this requirement up to now.
One of the things people asked for the reference software is to push it to have a more common partition table and booting logic, so it can be closer to what you would expect on a traditional desktop.
So we should try to experiment with this over the next few weeks for sure.
Thanks,
On Wed, Nov 11, 2015 at 12:39 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Wed, Nov 11, 2015 at 01:50:15PM +0000, Daniel Thompson wrote:
On 11/11/15 06:35, Koen Kooi wrote:
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Isn't that a consequence of loading UEFI itself from the same media (eMMC) that UEFI loads the OS?
I think we might always need at least one partition configured to "protect" the firmware; we need to be able to direct an off-the-shelf (i.e. does not have any special knowledge about hikey) OS installer not to mess with it.
What is the best way to mark such a partition to encourage installers to do that by default?
Most installers won't touch anything they don't recognise, but it could be clearer here. Just using "Microsoft basic data" as a partition type doesn't tell anybody anything useful here. From reading https://en.wikipedia.org/wiki/GUID_Partition_Table, I'd suggest maybe using Reserved (8DA63339-0007-60C0-C436-083AC8230908) or (maybe better) picking/registering a different partition type altogether.
That should indeed work better for eMMC. Other option we should have is having the firmware as part of the eMMC and the OS installed at the SDcard (and then the partition table/logic would be generic enough).
In the end we need to support both, since people might want to also install distros on a usb disk (specially with USB 3.0), which would be similar to the sdcard logic.
Cheers,
Agreed - lets make this as generic as possible (subject to hardware support);
Goal for Reference Platform
We should define and follow standards where we need to - for example common partition tables …. Boot from eMMC Boot from SD Boot from USB Stick Boot from network (GRUB 2) using on board ethernet or USB ethernet dongle
All from an open source bootloader with ATF, OPTEE, UEFI, ACPI/DT, Fastboot support etc.
George
On Nov 11, 2015, at 10:07 AM, Ricardo Salveti ricardo.salveti@linaro.org wrote:
On Wed, Nov 11, 2015 at 12:39 PM, Steve McIntyre <steve.mcintyre@linaro.org mailto:steve.mcintyre@linaro.org> wrote:
On Wed, Nov 11, 2015 at 01:50:15PM +0000, Daniel Thompson wrote:
On 11/11/15 06:35, Koen Kooi wrote:
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Isn't that a consequence of loading UEFI itself from the same media (eMMC) that UEFI loads the OS?
I think we might always need at least one partition configured to "protect" the firmware; we need to be able to direct an off-the-shelf (i.e. does not have any special knowledge about hikey) OS installer not to mess with it.
What is the best way to mark such a partition to encourage installers to do that by default?
Most installers won't touch anything they don't recognise, but it could be clearer here. Just using "Microsoft basic data" as a partition type doesn't tell anybody anything useful here. From reading https://en.wikipedia.org/wiki/GUID_Partition_Table, I'd suggest maybe using Reserved (8DA63339-0007-60C0-C436-083AC8230908) or (maybe better) picking/registering a different partition type altogether.
That should indeed work better for eMMC. Other option we should have is having the firmware as part of the eMMC and the OS installed at the SDcard (and then the partition table/logic would be generic enough).
In the end we need to support both, since people might want to also install distros on a usb disk (specially with USB 3.0), which would be similar to the sdcard logic.
Cheers,
Ricardo Salveti _______________________________________________ Dev mailing list Dev@lists.96boards.org mailto:Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev https://lists.96boards.org/mailman/listinfo/dev
+++ Fathi Boudra [2015-11-11 09:24 +0200]:
I'll reword as: if you want to have your board officially supported by RedHat (or put your favorite distro here), the requirement is to have your board supported mainline, because it's their policy.
Indeed. Debian has exactly the same policy, because anything else is unmaintainable.
Wookey
hi，
This will support Ubuntu, debian and fedora and so on for HiKey board in next v2.1 release. you can wait this release and pay attention to this website: http://open-estuary.com/. :)
Thank you Xinwei
On 2015/11/11 23:19, George Grey wrote:
Agreed - lets make this as generic as possible (subject to hardware support);
Goal for Reference Platform
We should define and follow standards where we need to - for example common partition tables …. Boot from eMMC Boot from SD Boot from USB Stick Boot from network (GRUB 2) using on board ethernet or USB ethernet dongle
All from an open source bootloader with ATF, OPTEE, UEFI, ACPI/DT, Fastboot support etc.
George
On Nov 11, 2015, at 10:07 AM, Ricardo Salveti <ricardo.salveti@linaro.org mailto:ricardo.salveti@linaro.org> wrote:
On Wed, Nov 11, 2015 at 12:39 PM, Steve McIntyre <steve.mcintyre@linaro.org mailto:steve.mcintyre@linaro.org> wrote:
On Wed, Nov 11, 2015 at 01:50:15PM +0000, Daniel Thompson wrote:
On 11/11/15 06:35, Koen Kooi wrote:
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Isn't that a consequence of loading UEFI itself from the same media (eMMC) that UEFI loads the OS?
I think we might always need at least one partition configured to "protect" the firmware; we need to be able to direct an off-the-shelf (i.e. does not have any special knowledge about hikey) OS installer not to mess with it.
What is the best way to mark such a partition to encourage installers to do that by default?
Most installers won't touch anything they don't recognise, but it could be clearer here. Just using "Microsoft basic data" as a partition type doesn't tell anybody anything useful here. From reading https://en.wikipedia.org/wiki/GUID_Partition_Table, I'd suggest maybe using Reserved (8DA63339-0007-60C0-C436-083AC8230908) or (maybe better) picking/registering a different partition type altogether.
That should indeed work better for eMMC. Other option we should have is having the firmware as part of the eMMC and the OS installed at the SDcard (and then the partition table/logic would be generic enough).
In the end we need to support both, since people might want to also install distros on a usb disk (specially with USB 3.0), which would be similar to the sdcard logic.
Cheers,
Ricardo Salveti _______________________________________________ Dev mailing list Dev@lists.96boards.org mailto:Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Wed, Nov 11, 2015 at 2:39 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Wed, Nov 11, 2015 at 01:50:15PM +0000, Daniel Thompson wrote:
On 11/11/15 06:35, Koen Kooi wrote:
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Isn't that a consequence of loading UEFI itself from the same media (eMMC) that UEFI loads the OS?
I think we might always need at least one partition configured to "protect" the firmware; we need to be able to direct an off-the-shelf (i.e. does not have any special knowledge about hikey) OS installer not to mess with it.
What is the best way to mark such a partition to encourage installers to do that by default?
Most installers won't touch anything they don't recognise, but it could be clearer here. Just using "Microsoft basic data" as a partition type doesn't tell anybody anything useful here. From reading https://en.wikipedia.org/wiki/GUID_Partition_Table, I'd suggest maybe using Reserved (8DA63339-0007-60C0-C436-083AC8230908) or (maybe better) picking/registering a different partition type altogether.
Reserved would be fine I think. The partition attribute flags may be the right place to mark partitions as required-do-not-touch. Bit 0 means system partition (do not touch or move). Bit 1 means EFI should ignore the contents and not attempt to read. Setting those two flags may be sufficient to keep those partitions around. But I digress from the main point...
Doing full system images like were doing now is fine to get people up and running, but it doesn't help distros. When the MMC is shared between firmware and the OS, we need to take a two stage approach to OS support: 1) Prepare the platform (just enough partitioning to hold the firmware images) 2) OS/Distro installer (OS does it's own thing for installation, including creating/moving the ESP if need be)
The first stage is firmly our responsibility or the board vendor's. It should leave the MMC partitioned, but no OS partitions exist yet. The ESP may exist, but if it does then it should be empty (or alternately, the firmware is okay with it being empty).
Second stage is the distro installer. It should be able to do all the normal activities that an installer does with one restriction: It must not delete the reserved partitions. If it does, or if the user does manually, then the user has to go back to stage 1.
Boards should ship with stage 1 already installed, ready for an OS installer. Installing the OS (or netbooting for that matter) shouldn't require redoing stage 1.
Stage 2 could be a netboot installer, a netboot image, or boot from SD card. End users can also go do their own thing (install firmware images to SD card), but that isn't something we expect distros to support. Users doing that are on their own.
The Debian system images we currently produce are /kind of/ like stage 2, but we're very naive about it by flashing raw filesystem images to disk. Fine for proving things out, but it isn't where we want to be.
Steve, does that sound like a supportable approach for Debian?
g.
On Thu, Nov 12, 2015 at 01:45:15PM +0000, Grant Likely wrote:
On Wed, Nov 11, 2015 at 2:39 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Wed, Nov 11, 2015 at 01:50:15PM +0000, Daniel Thompson wrote:
On 11/11/15 06:35, Koen Kooi wrote:
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Isn't that a consequence of loading UEFI itself from the same media (eMMC) that UEFI loads the OS?
I think we might always need at least one partition configured to "protect" the firmware; we need to be able to direct an off-the-shelf (i.e. does not have any special knowledge about hikey) OS installer not to mess with it.
What is the best way to mark such a partition to encourage installers to do that by default?
Most installers won't touch anything they don't recognise, but it could be clearer here. Just using "Microsoft basic data" as a partition type doesn't tell anybody anything useful here. From reading https://en.wikipedia.org/wiki/GUID_Partition_Table, I'd suggest maybe using Reserved (8DA63339-0007-60C0-C436-083AC8230908) or (maybe better) picking/registering a different partition type altogether.
Reserved would be fine I think. The partition attribute flags may be the right place to mark partitions as required-do-not-touch. Bit 0 means system partition (do not touch or move). Bit 1 means EFI should ignore the contents and not attempt to read. Setting those two flags may be sufficient to keep those partitions around. But I digress from the main point...
ACK, those bits would make sens.
Doing full system images like were doing now is fine to get people up and running, but it doesn't help distros. When the MMC is shared between firmware and the OS, we need to take a two stage approach to OS support:
- Prepare the platform (just enough partitioning to hold the firmware images)
- OS/Distro installer (OS does it's own thing for installation,
including creating/moving the ESP if need be)
The first stage is firmly our responsibility or the board vendor's. It should leave the MMC partitioned, but no OS partitions exist yet. The ESP may exist, but if it does then it should be empty (or alternately, the firmware is okay with it being empty).
Yup.
Second stage is the distro installer. It should be able to do all the normal activities that an installer does with one restriction: It must not delete the reserved partitions. If it does, or if the user does manually, then the user has to go back to stage 1.
Boards should ship with stage 1 already installed, ready for an OS installer. Installing the OS (or netbooting for that matter) shouldn't require redoing stage 1.
Stage 2 could be a netboot installer, a netboot image, or boot from SD card. End users can also go do their own thing (install firmware images to SD card), but that isn't something we expect distros to support. Users doing that are on their own.
The Debian system images we currently produce are /kind of/ like stage 2, but we're very naive about it by flashing raw filesystem images to disk. Fine for proving things out, but it isn't where we want to be.
Steve, does that sound like a supportable approach for Debian?
Absolutely. It's the kind of setup that debian-installer will be expecting. It should present a reasonable end-user experience if exposed to them directly, and *should* also work sensibly if somebody is pre-seeding an installation for a lights-out setup.
Cheers,
On Thu, Nov 12, 2015 at 2:52 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Thu, Nov 12, 2015 at 01:45:15PM +0000, Grant Likely wrote:
On Wed, Nov 11, 2015 at 2:39 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Wed, Nov 11, 2015 at 01:50:15PM +0000, Daniel Thompson wrote:
On 11/11/15 06:35, Koen Kooi wrote:
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Isn't that a consequence of loading UEFI itself from the same media (eMMC) that UEFI loads the OS?
I think we might always need at least one partition configured to "protect" the firmware; we need to be able to direct an off-the-shelf (i.e. does not have any special knowledge about hikey) OS installer not to mess with it.
What is the best way to mark such a partition to encourage installers to do that by default?
Most installers won't touch anything they don't recognise, but it could be clearer here. Just using "Microsoft basic data" as a partition type doesn't tell anybody anything useful here. From reading https://en.wikipedia.org/wiki/GUID_Partition_Table, I'd suggest maybe using Reserved (8DA63339-0007-60C0-C436-083AC8230908) or (maybe better) picking/registering a different partition type altogether.
Reserved would be fine I think. The partition attribute flags may be the right place to mark partitions as required-do-not-touch. Bit 0 means system partition (do not touch or move). Bit 1 means EFI should ignore the contents and not attempt to read. Setting those two flags may be sufficient to keep those partitions around. But I digress from the main point...
ACK, those bits would make sens.
Doing full system images like were doing now is fine to get people up and running, but it doesn't help distros. When the MMC is shared between firmware and the OS, we need to take a two stage approach to OS support:
- Prepare the platform (just enough partitioning to hold the firmware images)
- OS/Distro installer (OS does it's own thing for installation,
including creating/moving the ESP if need be)
The first stage is firmly our responsibility or the board vendor's. It should leave the MMC partitioned, but no OS partitions exist yet. The ESP may exist, but if it does then it should be empty (or alternately, the firmware is okay with it being empty).
Yup.
Second stage is the distro installer. It should be able to do all the normal activities that an installer does with one restriction: It must not delete the reserved partitions. If it does, or if the user does manually, then the user has to go back to stage 1.
Boards should ship with stage 1 already installed, ready for an OS installer. Installing the OS (or netbooting for that matter) shouldn't require redoing stage 1.
Stage 2 could be a netboot installer, a netboot image, or boot from SD card. End users can also go do their own thing (install firmware images to SD card), but that isn't something we expect distros to support. Users doing that are on their own.
The Debian system images we currently produce are /kind of/ like stage 2, but we're very naive about it by flashing raw filesystem images to disk. Fine for proving things out, but it isn't where we want to be.
Steve, does that sound like a supportable approach for Debian?
Absolutely. It's the kind of setup that debian-installer will be expecting. It should present a reasonable end-user experience if exposed to them directly, and *should* also work sensibly if somebody is pre-seeding an installation for a lights-out setup.
Right. Lets do this then. Ricardo, how do we get there? There UEFI upstreaming work is really important to pick up bugfixes and features from mainline. So is the kernel mainlining work so that distros can pick up board support. We need to have some focus on grub_install to make sure it works correctly on HiKey's UEFI. It would be really good to get the Dragonboard 410c UEFI port working for us, but I don't know if the source code for that has been released.
g.
Right. Lets do this then. Ricardo, how do we get there? There UEFI upstreaming work is really important to pick up bugfixes and features from mainline. So is the kernel mainlining work so that distros can pick up board support. We need to have some focus on grub_install to make sure it works correctly on HiKey's UEFI. It would be really good to get the Dragonboard 410c UEFI port working for us, but I don't know if the source code for that has been released.
What is the status of (HiKey) UEFI support for various boot devices? The last version I tested supported eMMC only, with SD and netboot "in the works" by various reports. We need UEFI support for at least two different boot devices to enable the use of an installer (i.e., run installer from SD then boot installed system from eMMC, or run installer from network then boot installed system from SD/eMMC). (People have been "running from SD" since the beginning, but the kernel-on-eMMC/userland-on-SD approach doesn't count for installer support).
-Chris
On Thu, Nov 12, 2015 at 4:04 PM, Chris Tyler chris.tyler@senecacollege.ca wrote:
Right. Lets do this then. Ricardo, how do we get there? There UEFI upstreaming work is really important to pick up bugfixes and features from mainline. So is the kernel mainlining work so that distros can pick up board support. We need to have some focus on grub_install to make sure it works correctly on HiKey's UEFI. It would be really good to get the Dragonboard 410c UEFI port working for us, but I don't know if the source code for that has been released.
What is the status of (HiKey) UEFI support for various boot devices? The last version I tested supported eMMC only, with SD and netboot "in the works" by various reports. We need UEFI support for at least two different boot devices to enable the use of an installer (i.e., run installer from SD then boot installed system from eMMC, or run installer from network then boot installed system from SD/eMMC). (People have been "running from SD" since the beginning, but the kernel-on-eMMC/userland-on-SD approach doesn't count for installer support).
Agreed. I've not tried playing with any of the other boot scenarios. We /should/ have everything we need to install Grub on the ESP, but get the config file, kernel, initrd and dtb from a Linux partition.
g.
On Thu, Nov 12, 2015 at 1:36 PM, Grant Likely grant.likely@linaro.org wrote:
On Thu, Nov 12, 2015 at 2:52 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Thu, Nov 12, 2015 at 01:45:15PM +0000, Grant Likely wrote:
On Wed, Nov 11, 2015 at 2:39 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Wed, Nov 11, 2015 at 01:50:15PM +0000, Daniel Thompson wrote:
On 11/11/15 06:35, Koen Kooi wrote:
>Device Start End Sectors Size Type >/dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data >/dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data >/dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data >/dev/mmcblk0p4 8192 24575 16384 8M BIOS boot >/dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data >/dev/mmcblk0p6 28672 159743 131072 64M EFI System >/dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data >/dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved >/dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Isn't that a consequence of loading UEFI itself from the same media (eMMC) that UEFI loads the OS?
I think we might always need at least one partition configured to "protect" the firmware; we need to be able to direct an off-the-shelf (i.e. does not have any special knowledge about hikey) OS installer not to mess with it.
What is the best way to mark such a partition to encourage installers to do that by default?
Most installers won't touch anything they don't recognise, but it could be clearer here. Just using "Microsoft basic data" as a partition type doesn't tell anybody anything useful here. From reading https://en.wikipedia.org/wiki/GUID_Partition_Table, I'd suggest maybe using Reserved (8DA63339-0007-60C0-C436-083AC8230908) or (maybe better) picking/registering a different partition type altogether.
Reserved would be fine I think. The partition attribute flags may be the right place to mark partitions as required-do-not-touch. Bit 0 means system partition (do not touch or move). Bit 1 means EFI should ignore the contents and not attempt to read. Setting those two flags may be sufficient to keep those partitions around. But I digress from the main point...
ACK, those bits would make sens.
Doing full system images like were doing now is fine to get people up and running, but it doesn't help distros. When the MMC is shared between firmware and the OS, we need to take a two stage approach to OS support:
- Prepare the platform (just enough partitioning to hold the firmware images)
- OS/Distro installer (OS does it's own thing for installation,
including creating/moving the ESP if need be)
The first stage is firmly our responsibility or the board vendor's. It should leave the MMC partitioned, but no OS partitions exist yet. The ESP may exist, but if it does then it should be empty (or alternately, the firmware is okay with it being empty).
Yup.
Second stage is the distro installer. It should be able to do all the normal activities that an installer does with one restriction: It must not delete the reserved partitions. If it does, or if the user does manually, then the user has to go back to stage 1.
Boards should ship with stage 1 already installed, ready for an OS installer. Installing the OS (or netbooting for that matter) shouldn't require redoing stage 1.
Stage 2 could be a netboot installer, a netboot image, or boot from SD card. End users can also go do their own thing (install firmware images to SD card), but that isn't something we expect distros to support. Users doing that are on their own.
The Debian system images we currently produce are /kind of/ like stage 2, but we're very naive about it by flashing raw filesystem images to disk. Fine for proving things out, but it isn't where we want to be.
Steve, does that sound like a supportable approach for Debian?
Absolutely. It's the kind of setup that debian-installer will be expecting. It should present a reasonable end-user experience if exposed to them directly, and *should* also work sensibly if somebody is pre-seeding an installation for a lights-out setup.
Right. Lets do this then. Ricardo, how do we get there? There UEFI upstreaming work is really important to pick up bugfixes and features from mainline. So is the kernel mainlining work so that distros can pick up board support. We need to have some focus on grub_install to make sure it works correctly on HiKey's UEFI.
Yes, that's is part of the goals we have for reference software. For the initial build, my main focus was getting the build in place, and change the bootloader logic to at least load grub2, kernel, initrd and dtb from the root file system (the member builds we have are shipping everything as part of the boot partition).
While we have UEFI support for HiKey, we're still sorting out the upstreaming plan, but that should be in place quite soon. The goal is indeed for it to be generic enough for any distro to be able to install without changes to the installer.
It would be really good to get the Dragonboard 410c UEFI port working for us, but I don't know if the source code for that has been released.
That might be a bit more tricky, since we don't have any source code for it. The only other work we know is the initial u-boot support for it, but still not replacing the little-kernel (the first stage bootloader is still proprietary).
Cheers,
On Thu, Nov 12, 2015 at 2:04 PM, Chris Tyler chris.tyler@senecacollege.ca wrote:
Right. Lets do this then. Ricardo, how do we get there? There UEFI upstreaming work is really important to pick up bugfixes and features from mainline. So is the kernel mainlining work so that distros can pick up board support. We need to have some focus on grub_install to make sure it works correctly on HiKey's UEFI. It would be really good to get the Dragonboard 410c UEFI port working for us, but I don't know if the source code for that has been released.
What is the status of (HiKey) UEFI support for various boot devices? The last version I tested supported eMMC only, with SD and netboot "in the works" by various reports. We need UEFI support for at least two different boot devices to enable the use of an installer (i.e., run installer from SD then boot installed system from eMMC, or run installer from network then boot installed system from SD/eMMC). (People have been "running from SD" since the beginning, but the kernel-on-eMMC/userland-on-SD approach doesn't count for installer support).
Booting from the SD card is already working (not yet following the generic location/files though), now for USB/netboot I know that it is planned, but not sure if supported at all at this point (since it needs to support the usb controller first).
Cheers,
On Thu, Nov 12, 2015 at 7:45 AM, Grant Likely grant.likely@linaro.org wrote:
On Wed, Nov 11, 2015 at 2:39 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Wed, Nov 11, 2015 at 01:50:15PM +0000, Daniel Thompson wrote:
On 11/11/15 06:35, Koen Kooi wrote:
Device Start End Sectors Size Type /dev/mmcblk0p1 2048 4095 2048 1M Microsoft basic data /dev/mmcblk0p2 4096 6143 2048 1M Microsoft basic data /dev/mmcblk0p3 6144 8191 2048 1M Microsoft basic data /dev/mmcblk0p4 8192 24575 16384 8M BIOS boot /dev/mmcblk0p5 24576 28671 4096 2M Microsoft basic data /dev/mmcblk0p6 28672 159743 131072 64M EFI System /dev/mmcblk0p7 159744 684031 524288 256M Microsoft basic data /dev/mmcblk0p8 684032 1208319 524288 256M Linux reserved /dev/mmcblk0p9 1208320 7471070 6262751 3G Microsoft basic data
So you proved Marcins point: instead of ESP + rootfs like you'd expect hikey has vrl, vrl_backup, mcuimage and more partitions. Having the script below doesn't make it less 'magic'.
Isn't that a consequence of loading UEFI itself from the same media (eMMC) that UEFI loads the OS?
I think we might always need at least one partition configured to "protect" the firmware; we need to be able to direct an off-the-shelf (i.e. does not have any special knowledge about hikey) OS installer not to mess with it.
What is the best way to mark such a partition to encourage installers to do that by default?
Most installers won't touch anything they don't recognise, but it could be clearer here. Just using "Microsoft basic data" as a partition type doesn't tell anybody anything useful here. From reading https://en.wikipedia.org/wiki/GUID_Partition_Table, I'd suggest maybe using Reserved (8DA63339-0007-60C0-C436-083AC8230908) or (maybe better) picking/registering a different partition type altogether.
Reserved would be fine I think. The partition attribute flags may be the right place to mark partitions as required-do-not-touch. Bit 0 means system partition (do not touch or move). Bit 1 means EFI should ignore the contents and not attempt to read. Setting those two flags may be sufficient to keep those partitions around. But I digress from the main point...
Doing full system images like were doing now is fine to get people up and running, but it doesn't help distros. When the MMC is shared between firmware and the OS, we need to take a two stage approach to OS support:
- Prepare the platform (just enough partitioning to hold the firmware images)
- OS/Distro installer (OS does it's own thing for installation,
including creating/moving the ESP if need be)
The first stage is firmly our responsibility or the board vendor's. It should leave the MMC partitioned, but no OS partitions exist yet. The ESP may exist, but if it does then it should be empty (or alternately, the firmware is okay with it being empty).
Second stage is the distro installer. It should be able to do all the normal activities that an installer does with one restriction: It must not delete the reserved partitions. If it does, or if the user does manually, then the user has to go back to stage 1.
Boards should ship with stage 1 already installed, ready for an OS installer. Installing the OS (or netbooting for that matter) shouldn't require redoing stage 1.
I personally would like to see the pain of stage 1 related tasks reduced. Yes, solving OS install problems serves a lot of users, but there are a fair number of people that have to deal with components prior to OS boot and everything before that point is different. Some things we may not be able to fix, but I'm sure there are things we can. We've generally just left it to Builds&Baselines team to work around all these differences. We need to stop doing that and standardize things across platforms where we can.
For example, I need to fix the partition table or revert it back to "stage 1". How do I do that in a way that is common across boards? There's varying requirements of what platforms need for partitions or reserved areas, but that is all just data. There is no good reason for the procedure to be different. In good ole non-standard u-boot that can be a "gpt write ${partitions}" command with $partitions coming from environment or "fastboot oem format". For UEFI?
Another example, how do I update UEFI/u-boot without rebuilding ATF. In general, I'd like to be able to replace only the component I care about while retaining the rest of the released images. We should be looking at how to reduce the number of steps and making sure the steps are the same across boards.
Rob
On 12 November 2015 at 21:57, Ricardo Salveti ricardo.salveti@linaro.org wrote:
On Thu, Nov 12, 2015 at 2:04 PM, Chris Tyler chris.tyler@senecacollege.ca wrote:
Right. Lets do this then. Ricardo, how do we get there? There UEFI upstreaming work is really important to pick up bugfixes and features from mainline. So is the kernel mainlining work so that distros can pick up board support. We need to have some focus on grub_install to make sure it works correctly on HiKey's UEFI. It would be really good to get the Dragonboard 410c UEFI port working for us, but I don't know if the source code for that has been released.
What is the status of (HiKey) UEFI support for various boot devices? The last version I tested supported eMMC only, with SD and netboot "in the works" by various reports. We need UEFI support for at least two different boot devices to enable the use of an installer (i.e., run installer from SD then boot installed system from eMMC, or run installer from network then boot installed system from SD/eMMC). (People have been "running from SD" since the beginning, but the kernel-on-eMMC/userland-on-SD approach doesn't count for installer support).
Booting from the SD card is already working (not yet following the generic location/files though), now for USB/netboot I know that it is planned, but not sure if supported at all at this point (since it needs to support the usb controller first).
We have an initial implementation but we're still debugging it since we observe crashes.
-
Chris Tyler -
Daniel Thompson -
Fathi Boudra -
George Grey -
Grant Likely -
Haojian Zhuang -
Kevin Hilman -
Koen Kooi -
Ricardo Salveti -
Rob Herring -
Steve McIntyre -
Wookey -
Xinwei Kong