[opensuse-arm] RaspberryPi:upstream update -- partitioning
Hi Alex and Marcus, Last night I tested the new JeOS-raspberrypi image that had finally been built. https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryP... (note: not the old ...:RaspberryPi/JeOS-raspberrypi) It did not boot - screen stayed dark, no green LED activity. It uses GPT, so I tried converting to MBR (with gdisk) - no change. I further changed the MBR partition type of the first of the three partitions from EFI to FAT16 - starts booting U-Boot, yay! The bad news is, I don't see how I could tweak either of these in the Kiwi config. :/ It seems that the new partition layout is triggered by firmware="vboot". Does that mean changes need to be done in Kiwi code? Booting with the manually changed partitions didn't get beyond "Starting kernel ..." due to fdt not loaded. That part is hopefully fixed with tonight's JeOS changes - new image can't be built due to unresolved sysconfig-network at the moment. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 15.01.2014 20:57, schrieb Andreas Färber:
new image can't be built due to unresolved sysconfig-network at the moment.
Actually all JeOS images no longer build - apparently sysconfig-network has been dropped in favour of wicked-service: https://build.opensuse.org/request/show/213496 I'll piece together an SR. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 15.01.2014 20:57, schrieb Andreas Färber:
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryP... (note: not the old ...:RaspberryPi/JeOS-raspberrypi)
It did not boot - screen stayed dark, no green LED activity.
It uses GPT, so I tried converting to MBR (with gdisk) - no change.
Same when changing the GPT partition type from EFI to simple data (?) like the other partitions. On inspiration from Alex, I tried a hybrid MBR (gdisk h command), using 06 as MBR type for the EFI partition, but same result.
I further changed the MBR partition type of the first of the three partitions from EFI to FAT16 - starts booting U-Boot, yay!
The bad news is, I don't see how I could tweak either of these in the Kiwi config. :/ It seems that the new partition layout is triggered by firmware="vboot". Does that mean changes need to be done in Kiwi code?
Apparently so. But searching the kiwi sources on GitHub for "vboot" or "gpt" didn't exactly result in handy hits to tweak... :(
Booting with the manually changed partitions didn't get beyond "Starting kernel ..." due to fdt not loaded. That part is hopefully fixed with tonight's JeOS changes - new image can't be built due to unresolved sysconfig-network at the moment.
sysconfig-network has been replaced with wicked-service, restoring image builds. With manual partition and boot.scr tweaks, for the first time with kernel-default I got output on HDMI, but boot got stuck with KIWI not finding the boot partition - probably caused by the MBR conversion. Update: Right now, image build is broken again, sorry: https://build.opensuse.org/request/show/214066 Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
I further changed the MBR partition type of the first of the three partitions from EFI to FAT16 - starts booting U-Boot, yay!
Could you send the layout of the resulting ptable which you were able to boot the device with ? parted device unit s print it would help me to do the right fixes in kiwi
The bad news is, I don't see how I could tweak either of these in the Kiwi config. :/ It seems that the new partition layout is triggered by firmware="vboot". Does that mean changes need to be done in Kiwi code?
yes. I talked to Alex about this disk layout and I think it's the best we can do. You are right the vboot firmware caused this layout and it is used for the Chromebook in the first place. For this device we needed a real GPT. With raspberry the layout is also a good idea but we have to use a sync_mbr ptable type. My plan is to configure this with: firmware="vboot" loader="berryboot" - should create a sync_mbr ptable type - should create three partitions 1. a fat16 containing u-boot.bin plus config.txt plus cmdline.txt plus all the raspberry required firmware stuff. as kernel in config.txt we use u-boot.bin which loads boot.scr from the second partition 2. ext2 boot partition, with boot.scr kernel and initrd 3. root partition The kiwi script hooks as we use for setting up the different loaders for the arm boards can be used to change all that. The common parts which are clear should be done by kiwi though Thanks Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 16.01.2014 um 09:11 schrieb Marcus Schäfer <ms@suse.de>:
Hi,
I further changed the MBR partition type of the first of the three partitions from EFI to FAT16 - starts booting U-Boot, yay!
Could you send the layout of the resulting ptable which you were able to boot the device with ?
parted device unit s print
it would help me to do the right fixes in kiwi
The bad news is, I don't see how I could tweak either of these in the Kiwi config. :/ It seems that the new partition layout is triggered by firmware="vboot". Does that mean changes need to be done in Kiwi code?
yes. I talked to Alex about this disk layout and I think it's the best we can do. You are right the vboot firmware caused this layout and it is used for the Chromebook in the first place. For this device we needed a real GPT. With raspberry the layout is also a good idea but we have to use a sync_mbr ptable type. My plan is to configure this with:
firmware="vboot" loader="berryboot"
Shouldn't loader be u-boot? After all, we need to run the normal uboot setup scripts, no?
- should create a sync_mbr ptable type - should create three partitions
1. a fat16 containing u-boot.bin plus config.txt plus cmdline.txt plus all the raspberry required firmware stuff. as kernel in config.txt we use u-boot.bin which loads boot.scr from the second partition
2. ext2 boot partition, with boot.scr kernel and initrd
3. root partition
The kiwi script hooks as we use for setting up the different loaders for the arm boards can be used to change all that. The common parts which are clear should be done by kiwi though
Exactly, we should leave the current uboot script magic alive, but just change the gpt to be either an mbr or a synced gpt :). For partition types we should be able to fix things up in the scripts like we do for the chromebook. Alex
Thanks
Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de -------------------------------------------------------
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
firmware="vboot" loader="berryboot"
Shouldn't loader be u-boot? After all, we need to run the normal uboot setup scripts, no?
yes but it's kind of both isn't it ? there is this berryboot "thing" reading config.txt and running a kernel which in our case is the real bootloader u-boot. Somehow I have to create the configs so that uboot is called. The loader="berryboot" information would be the trigger to do that. berryboot is also the name I found when looking up the boot capabilities of the raspberry devices. Thus I found the name ok because it's about loading raspberry... somehow :-) The scripts as part of the descriptions in the buildservice will most probably only fiddle around with the contents of the boot.scr as we do it for all boards. I think the setup so that u-boot is called is pretty generic and can be done by kiwi so you don't need to care for this in any script
Exactly, we should leave the current uboot script magic alive, but just change the gpt to be either an mbr or a synced gpt :). For partition types we should be able to fix things up in the scripts like we do for the chromebook.
yep it will be that way and in order to not break e.g the chromebook description I'd like to distinguish it by the loader setup Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 16.01.2014, at 12:56, Marcus Schäfer <ms@suse.de> wrote:
Hi,
firmware="vboot" loader="berryboot"
Shouldn't loader be u-boot? After all, we need to run the normal uboot setup scripts, no?
yes but it's kind of both isn't it ? there is this berryboot "thing" reading config.txt and running a kernel which in our case is the real bootloader u-boot. Somehow I have to create the configs so that
To me the "berryboot" part is the same level as MLO or SPL on other platforms. It's just some random binary blob required to actually get into u-boot. There's no need to have kiwi involved.
uboot is called. The loader="berryboot" information would be the trigger to do that. berryboot is also the name I found when looking up the boot capabilities of the raspberry devices. Thus I found the name ok because it's about loading raspberry... somehow :-)
The scripts as part of the descriptions in the buildservice will most probably only fiddle around with the contents of the boot.scr as we do it for all boards.
I think the setup so that u-boot is called is pretty generic and can be done by kiwi so you don't need to care for this in any script
Exactly, we should leave the current uboot script magic alive, but just change the gpt to be either an mbr or a synced gpt :). For partition types we should be able to fix things up in the scripts like we do for the chromebook.
yep it will be that way and in order to not break e.g the chromebook description I'd like to distinguish it by the loader setup
I think it'd make sense to test whether the chromebook would be happy with a sync'ed MBR. Then we wouldn't bloat the number of combinations too heavily. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
To me the "berryboot" part is the same level as MLO or SPL on other platforms. It's just some random binary blob required to actually get into u-boot. There's no need to have kiwi involved.
is ok for me too, just thought if you wouldn't have to care for it it would make the image description generator's live a bit easier basically if you set firmware="vboot" loader="uboot" you get what you want except for the ptable layout
I think it'd make sense to test whether the chromebook would be happy with a sync'ed MBR. Then we wouldn't bloat the number of combinations too heavily.
right that would be great Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 16.01.2014, at 15:35, Marcus Schäfer <ms@suse.de> wrote:
Hi,
To me the "berryboot" part is the same level as MLO or SPL on other platforms. It's just some random binary blob required to actually get into u-boot. There's no need to have kiwi involved.
is ok for me too, just thought if you wouldn't have to care for it it would make the image description generator's live a bit easier basically if you set
firmware="vboot" loader="uboot"
you get what you want except for the ptable layout
It's the opposite - the less clever kiwi is the easier we can fix and change things in the uboot setup scripts :). One-offs really belong there.
I think it'd make sense to test whether the chromebook would be happy with a sync'ed MBR. Then we wouldn't bloat the number of combinations too heavily.
right that would be great
Unfortunately the Chromebook build is completely broken right now though, so it's hard to verify :). How about we just change it to always-synced and worst case fix it up to unsynced in the u-boot script? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
It's the opposite - the less clever kiwi is the easier we can fix and change things in the uboot setup scripts :). One-offs really belong there.
:-) kiwi is not clever, but I got what you've said
right that would be great
Unfortunately the Chromebook build is completely broken right now though, so it's hard to verify :). How about we just change it to always-synced and worst case fix it up to unsynced in the u-boot script?
fine with me I think I'm going to work on this next week, have to fix the efi problems with the HP machines first Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Guys, JeOS builds in QEMU are completely broken ATM: https://build.opensuse.org/package/live_build_log/devel:ARM:Factory:Contrib:... The unsupported ioctl 0x1269 appears to be BLKPG, so I implemented it to the best of my understanding in Virtualization qemu. But it seems, the build is still using some 1.5.92 version rather than my shiny 1.7.0! I tracked down that :Factory:ARM's qemu-linux-user-arm is packaging whatever QEMU the build host happens to have installed for some reason. But there is no dependency on QEMU so that it doesn't get updated. I therefore pieced together a trivial qemu-linux-user-arm package with my new binaries and overlaid that: https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryP... However, the package did not get published yet, which I guess - since kiwi uses zypper to download packages - is the reason the build still fails... "Build jobs have been processed, new repository is not yet created" although the repository on the download server does exist and contains kernel binaries. Same problem as with 13.1 updates? Other than that, I have a local experimental KIWI patch adding the bootargs quotes and changing the partition type that I would've liked to test. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
JeOS builds in QEMU are completely broken ATM:
yes unfortunately qemu builds on x86_64 also worked only for a short time for me. It was the reason why I started to build on real arm hardware whenever possible. But with current Factory::ARM this did not work either because for some reason the required dbus package could not be found Retrieving: dbus-1-1.7.10-1.1.armv6hl.rpm ...............................[error] File './suse/armv6hl/dbus-1-1.7.10-1.1.armv6hl.rpm' not found on medium 'http://download.opensuse.org/ports/armv6hl/factory/repo/oss' Thus I also can't build at the moment
Other than that, I have a local experimental KIWI patch adding the bootargs quotes and changing the partition type that I would've liked to test.
if you like I can give it a try too ? ...if I can overcome the build problem above Thanks Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 18.01.2014 14:38, schrieb Marcus Schäfer:
Other than that, I have a local experimental KIWI patch adding the bootargs quotes and changing the partition type that I would've liked to test.
if you like I can give it a try too ?
My local patch is two-fold: diff --git a/modules/KIWIBoot.pm b/modules/KIWIBoot.pm index 254efc4..05ba95a 100644 --- a/modules/KIWIBoot.pm +++ b/modules/KIWIBoot.pm @@ -5211,9 +5211,9 @@ sub setupBootLoaderConfiguration { $kiwi -> failed (); return; } elsif (($topic=~ /^KIWI USB/)||($imgtype=~ /vmx|oem|split/)) { - print $FD "setenv bootargs $cmdline \${append}\n"; + print $FD "setenv bootargs '$cmdline \${append}'\n"; } else { - print $FD "setenv bootargs $cmdline \${append}\n" + print $FD "setenv bootargs '$cmdline \${append}'\n" } $FD -> close(); $kiwi -> done(); This is placing quotes around the bootargs value - to make this a proper patch you would need to escape any quotes within $cmdline, which I was unsure how to do in Perl. ;) @@ -6049,10 +6049,11 @@ sub getGeometry { return; } if (($firmware eq "efi") || - ($firmware eq "uefi") || - ($firmware eq "vboot") - ) { + ($firmware eq "uefi")) { $label = 'gpt'; + } elsif ($firmware eq "vboot") { +# $label = 'gpt_sync_mbr'; + $label = 'msdos'; } $status = KIWIQX::qxx ("$parted_exec -s $disk mklabel $label 2>&1"); $result = $? >> 8; As suggested by you, this is code to try either gpt_sync_mbr or msdos partitioning. The ioctl issue applied to all of uefi, gpt_sync_mbr and msdos though. If needed, I believe $loader would be there to be checked, too. Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, JFI
My local patch is two-fold:
Thanks, I incorporated the label part and added some other patches in order to build the layout we would like to achieve. Without further postprocessing I can now build a raspberry image of the following layout: Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 2048s 67591s 65544s primary fat16 boot, lba, type=0c 2 69632s 479239s 409608s primary ext3 type=83 3 483328s 1699839s 1216512s primary ext4 type=83 Partition 1 =================> * raspberry firmware files * config.txt kernel=u-boot.bin * uboot loader Partition 2 =================> * dtb/... * boot/kernel_and_initrd * boot.scr ==> loaded by uboot * vboot/... ==> mountpoint for accessing Part1 data Partition 3 =================> * root filesystem I will continue to actually boot that thing, which is imho the most important part :-) The commit for the changes done so far is in the kiwi master git. for reference: 587226cc if I get it to boot there are two further things we should fix: 1. correct cmdline quoting, as Andreas already pointed out 2. change name of loader attribute value 'berryboot' because it's misleading Thanks Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 18.01.2014 06:57, schrieb Andreas Färber:
Guys,
JeOS builds in QEMU are completely broken ATM:
https://build.opensuse.org/package/live_build_log/devel:ARM:Factory:Contrib:...
The unsupported ioctl 0x1269 appears to be BLKPG, so I implemented it to the best of my understanding in Virtualization qemu. But it seems, the build is still using some 1.5.92 version rather than my shiny 1.7.0!
I tracked down that :Factory:ARM's qemu-linux-user-arm is packaging whatever QEMU the build host happens to have installed for some reason. But there is no dependency on QEMU so that it doesn't get updated. I therefore pieced together a trivial qemu-linux-user-arm package with my new binaries and overlaid that:
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryP...
However, the package did not get published yet, which I guess - since kiwi uses zypper to download packages - is the reason the build still fails... "Build jobs have been processed, new repository is not yet created" although the repository on the download server does exist and contains kernel binaries.
Same problem as with 13.1 updates?
Quick update: My first building qemu-linux-user-arm package -5.1 got published after a few hours(!), by now -6.1 is published, too. So no, 13.1 updates is still not publishing, it only took reeeally long. The output changed now from "Unsupported syscall: cmd=0x1269 (0)" to "Invalid type 0x9", which I did not find in linux-user. It occurs equally often, so something with my implementation may be wrong. Alex? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 18.01.2014 um 18:08 schrieb Andreas Färber <afaerber@suse.de>:
Am 18.01.2014 06:57, schrieb Andreas Färber:
Guys,
JeOS builds in QEMU are completely broken ATM:
https://build.opensuse.org/package/live_build_log/devel:ARM:Factory:Contrib:...
The unsupported ioctl 0x1269 appears to be BLKPG, so I implemented it to the best of my understanding in Virtualization qemu. But it seems, the build is still using some 1.5.92 version rather than my shiny 1.7.0!
I tracked down that :Factory:ARM's qemu-linux-user-arm is packaging whatever QEMU the build host happens to have installed for some reason. But there is no dependency on QEMU so that it doesn't get updated. I therefore pieced together a trivial qemu-linux-user-arm package with my new binaries and overlaid that:
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryP...
However, the package did not get published yet, which I guess - since kiwi uses zypper to download packages - is the reason the build still fails... "Build jobs have been processed, new repository is not yet created" although the repository on the download server does exist and contains kernel binaries.
Same problem as with 13.1 updates?
Quick update: My first building qemu-linux-user-arm package -5.1 got published after a few hours(!), by now -6.1 is published, too. So no, 13.1 updates is still not publishing, it only took reeeally long.
The output changed now from "Unsupported syscall: cmd=0x1269 (0)" to "Invalid type 0x9", which I did not find in linux-user. It occurs equally often, so something with my implementation may be wrong. Alex?
Yeah, maybe the guest is printing it. Try to write a small test program for your ioctl emulation - or try QEMU_STRACE=1 first to be sure it's really that one. Alex
Andreas
-- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 16.01.2014 13:06, schrieb Alexander Graf:
On 16.01.2014, at 12:56, Marcus Schäfer <ms@suse.de> wrote:
firmware="vboot" loader="berryboot"
Shouldn't loader be u-boot? After all, we need to run the normal uboot setup scripts, no?
yes but it's kind of both isn't it ? there is this berryboot "thing" reading config.txt and running a kernel which in our case is the real bootloader u-boot. Somehow I have to create the configs so that
To me the "berryboot" part is the same level as MLO or SPL on other platforms. It's just some random binary blob required to actually get into u-boot. There's no need to have kiwi involved.
uboot is called. The loader="berryboot" information would be the trigger to do that. berryboot is also the name I found when looking up the boot capabilities of the raspberry devices. Thus I found the name ok because it's about loading raspberry... somehow :-)
The scripts as part of the descriptions in the buildservice will most probably only fiddle around with the contents of the boot.scr as we do it for all boards.
I think the setup so that u-boot is called is pretty generic and can be done by kiwi so you don't need to care for this in any script
Exactly, we should leave the current uboot script magic alive, but just change the gpt to be either an mbr or a synced gpt :). For partition types we should be able to fix things up in the scripts like we do for the chromebook.
yep it will be that way and in order to not break e.g the chromebook description I'd like to distinguish it by the loader setup
I think it'd make sense to test whether the chromebook would be happy with a sync'ed MBR. Then we wouldn't bloat the number of combinations too heavily.
According to http://archlinuxarm.org/platforms/armv7/samsung/odroid-xu the ODROID-XU also needs some special partitioning scheme. I haven't tried Linux yet, but my Android SD card looks like this: Device Boot Start End Blocks Id System /dev/sdb1 6982800 15377339 4197270 c W95 FAT32 (LBA) /dev/sdb2 136620 2246639 1055010 83 Linux /dev/sdb3 2246640 6451499 2102430 83 Linux /dev/sdb4 6451500 6982799 265650 83 Linux Note: no FAT partition, "free space" before block 136620 (70 MB) If you have ideas how to investigate this magic free space, do let me know. Anyway, just pointing out that the RPi may be special wrt its config.txt etc. but more than just the two boards may want a three-partition layout, with all sorts of variations. I'll try to test a sync'ed GPT tonight. But I also noticed that the Raspberry Pi bootloader files (bootcode.bin, *.elf) end up on both partitions when they would only be necessary on the FAT partition. Is that fixable in our JeOS scripts? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Am 16.01.2014 12:56, schrieb Marcus Schäfer:
firmware="vboot" loader="berryboot"
Shouldn't loader be u-boot? After all, we need to run the normal uboot setup scripts, no?
yes but it's kind of both isn't it ? there is this berryboot "thing" reading config.txt and running a kernel which in our case is the real bootloader u-boot. Somehow I have to create the configs so that uboot is called. The loader="berryboot" information would be the trigger to do that. berryboot is also the name I found when looking up the boot capabilities of the raspberry devices. Thus I found the name ok because it's about loading raspberry... somehow :-)
As I pointed out before, BerryBoot seems to be something different: http://www.berryterminal.com/doku.php/berryboot So that name feels confusing. If we need some special enum value, let's rather call it raspberrypi or so. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
As I pointed out before, BerryBoot seems to be something different: http://www.berryterminal.com/doku.php/berryboot
funny :)
So that name feels confusing. If we need some special enum value, let's rather call it raspberrypi or so.
agreed Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 16.01.2014 09:11, schrieb Marcus Schäfer:
I further changed the MBR partition type of the first of the three partitions from EFI to FAT16 - starts booting U-Boot, yay!
Could you send the layout of the resulting ptable which you were able to boot the device with ?
parted device unit s print
it would help me to do the right fixes in kiwi
Here's a booting config as result of gdisk /dev/sdb with r g w y followed by changing the partition type to 06 in gnome-disks: # parted /dev/sdb unit s print Model: Generic- Multi-Card (scsi) Disk /dev/sdb: 31116288s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 2048s 67591s 65544s primary fat16 type=06 2 69632s 479239s 409608s primary ext3 type=07 3 483328s 2080640s 1597313s primary ext4 type=07 Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (3)
-
Alexander Graf -
Andreas Färber -
Marcus Schäfer