[opensuse-arm] Raspberry Pi 3 AArch64 DTB
Hi, On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too. * dtb-rpi3-aarch64 : pre-compiled bcm2837-rpi-3-b.dtb (from where?) Current JeOS uses the pre-compiled DT. WiFi is not working on AArch64 version, and I am wondering if it could be caused by the DTB used. Alex, Andreas, any idea? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 10/13/2016 10:37 AM, Guillaume Gardet wrote:
Hi,
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
Yeah, that's Andreas' attempt to make a hacky interim solution cleaner.
* dtb-rpi3-aarch64 : pre-compiled bcm2837-rpi-3-b.dtb (from where?)
This is literally assembled by hand.
Current JeOS uses the pre-compiled DT.
WiFi is not working on AArch64 version, and I am wondering if it could be caused by the DTB used.
Probably, yes. IMHO we have 2 options: 1) Keep hacking on the contrib, try to make it work (pretty much a waste of time IMHO) 2) 4.8 has proper RPi3 support, just move all RPi3 enablement to Tumbleweed proper Would you have time to work on option 2? 4.8 is missing Wifi (which the 4.4 based kernel in contrib includes), but for "normal" things it should be fine. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 13/10/2016 à 11:07, Alexander Graf a écrit :
On 10/13/2016 10:37 AM, Guillaume Gardet wrote:
Hi,
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
Yeah, that's Andreas' attempt to make a hacky interim solution cleaner.
* dtb-rpi3-aarch64 : pre-compiled bcm2837-rpi-3-b.dtb (from where?)
This is literally assembled by hand.
Current JeOS uses the pre-compiled DT.
WiFi is not working on AArch64 version, and I am wondering if it could be caused by the DTB used.
Probably, yes. IMHO we have 2 options:
1) Keep hacking on the contrib, try to make it work (pretty much a waste of time IMHO) 2) 4.8 has proper RPi3 support, just move all RPi3 enablement to Tumbleweed proper
Would you have time to work on option 2? 4.8 is missing Wifi (which the 4.4 based kernel in contrib includes), but for "normal" things it should be fine.
I do not have much time for that, sorry. I think we should have a fully (downstream?) working image (32 or 64 bits) including HDMI, and WiFi (and maybe hardware video decoding?). Then, we might have a 2nd image which follow upstream and where we might have some things missing such as WiFi. If more versions are needed for testing/developing purpose, then we should use staging projects. This is how is handled Raspberry Pi 1. For RPi2, we have only a downstream image since JeOS-raspberrypi2 package is missing in Factory:ARM. I think we could add it. Dirk, could you do it, please? Once 4.8 will be in Factory, lets play with JeOS-raspberrypi3_aarch64 in Factory. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 10/13/2016 11:34 AM, Guillaume Gardet wrote:
Le 13/10/2016 à 11:07, Alexander Graf a écrit :
On 10/13/2016 10:37 AM, Guillaume Gardet wrote:
Hi,
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
Yeah, that's Andreas' attempt to make a hacky interim solution cleaner.
* dtb-rpi3-aarch64 : pre-compiled bcm2837-rpi-3-b.dtb (from where?)
This is literally assembled by hand.
Current JeOS uses the pre-compiled DT.
WiFi is not working on AArch64 version, and I am wondering if it could be caused by the DTB used.
Probably, yes. IMHO we have 2 options:
1) Keep hacking on the contrib, try to make it work (pretty much a waste of time IMHO) 2) 4.8 has proper RPi3 support, just move all RPi3 enablement to Tumbleweed proper
Would you have time to work on option 2? 4.8 is missing Wifi (which the 4.4 based kernel in contrib includes), but for "normal" things it should be fine.
I do not have much time for that, sorry.
I think we should have a fully (downstream?) working image (32 or 64 bits) including HDMI, and WiFi (and maybe hardware video decoding?).
Hardware video decoding is currently limited to the 32-bit downstream rpi foundation kernel. An image with that one in place already exists here: https://en.opensuse.org/HCL:Raspberry_Pi3#Installing_the_32-bit_non-upstream... The devel:ARM:Factory:Contrib:RaspberryPi3 repo is for the 64bit variant which doesn't exist in raspberry foundation land.
Then, we might have a 2nd image which follow upstream and where we might have some things missing such as WiFi. If more versions are needed for testing/developing purpose, then we should use staging projects.
Yes, hence my suggestion to remove the RPi3 contrib and just move it all to Tumbleweed.
This is how is handled Raspberry Pi 1.
For RPi2, we have only a downstream image since JeOS-raspberrypi2 package is missing in Factory:ARM. I think we could add it. Dirk, could you do it, please?
For the RPi2 we're in the same situation: A downstream 32bit kernel with video decoding and an upstream 32bit kernel (that should work fine with the Tumbleweed kernel) that does not have video decoding capabilities.
Once 4.8 will be in Factory, lets play with JeOS-raspberrypi3_aarch64 in Factory.
Agreed. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 13/10/2016 à 11:40, Alexander Graf a écrit :
On 10/13/2016 11:34 AM, Guillaume Gardet wrote:
Le 13/10/2016 à 11:07, Alexander Graf a écrit :
On 10/13/2016 10:37 AM, Guillaume Gardet wrote:
Hi,
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
Yeah, that's Andreas' attempt to make a hacky interim solution cleaner.
* dtb-rpi3-aarch64 : pre-compiled bcm2837-rpi-3-b.dtb (from where?)
This is literally assembled by hand.
Current JeOS uses the pre-compiled DT.
WiFi is not working on AArch64 version, and I am wondering if it could be caused by the DTB used.
Probably, yes. IMHO we have 2 options:
1) Keep hacking on the contrib, try to make it work (pretty much a waste of time IMHO) 2) 4.8 has proper RPi3 support, just move all RPi3 enablement to Tumbleweed proper
Would you have time to work on option 2? 4.8 is missing Wifi (which the 4.4 based kernel in contrib includes), but for "normal" things it should be fine.
I do not have much time for that, sorry.
I think we should have a fully (downstream?) working image (32 or 64 bits) including HDMI, and WiFi (and maybe hardware video decoding?).
Hardware video decoding is currently limited to the 32-bit downstream rpi foundation kernel. An image with that one in place already exists here:
https://en.opensuse.org/HCL:Raspberry_Pi3#Installing_the_32-bit_non-upstream...
The devel:ARM:Factory:Contrib:RaspberryPi3 repo is for the 64bit variant which doesn't exist in raspberry foundation land.
Then, we might have a 2nd image which follow upstream and where we might have some things missing such as WiFi. If more versions are needed for testing/developing purpose, then we should use staging projects.
Yes, hence my suggestion to remove the RPi3 contrib and just move it all to Tumbleweed.
Yes, but the condition would be to not loose any functionality in the switch. Moreover, the current RPi3 Contrib is more a Leap 42.2 Contrib since it uses the 42.2 kernel. Maybe we could just rename it?
This is how is handled Raspberry Pi 1.
For RPi2, we have only a downstream image since JeOS-raspberrypi2 package is missing in Factory:ARM. I think we could add it. Dirk, could you do it, please?
For the RPi2 we're in the same situation: A downstream 32bit kernel with video decoding and an upstream 32bit kernel (that should work fine with the Tumbleweed kernel) that does not have video decoding capabilities.
Yes, we are just missing the downstream image. ;)
Once 4.8 will be in Factory, lets play with JeOS-raspberrypi3_aarch64 in Factory.
Agreed.
SR from Kernel:stable to Factory is on the way. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 10/13/2016 11:47 AM, Guillaume Gardet wrote:
Le 13/10/2016 à 11:40, Alexander Graf a écrit :
On 10/13/2016 11:34 AM, Guillaume Gardet wrote:
Le 13/10/2016 à 11:07, Alexander Graf a écrit :
On 10/13/2016 10:37 AM, Guillaume Gardet wrote:
Hi,
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
Yeah, that's Andreas' attempt to make a hacky interim solution cleaner.
* dtb-rpi3-aarch64 : pre-compiled bcm2837-rpi-3-b.dtb (from where?)
This is literally assembled by hand.
Current JeOS uses the pre-compiled DT.
WiFi is not working on AArch64 version, and I am wondering if it could be caused by the DTB used.
Probably, yes. IMHO we have 2 options:
1) Keep hacking on the contrib, try to make it work (pretty much a waste of time IMHO) 2) 4.8 has proper RPi3 support, just move all RPi3 enablement to Tumbleweed proper
Would you have time to work on option 2? 4.8 is missing Wifi (which the 4.4 based kernel in contrib includes), but for "normal" things it should be fine.
I do not have much time for that, sorry.
I think we should have a fully (downstream?) working image (32 or 64 bits) including HDMI, and WiFi (and maybe hardware video decoding?).
Hardware video decoding is currently limited to the 32-bit downstream rpi foundation kernel. An image with that one in place already exists here:
https://en.opensuse.org/HCL:Raspberry_Pi3#Installing_the_32-bit_non-upstream...
The devel:ARM:Factory:Contrib:RaspberryPi3 repo is for the 64bit variant which doesn't exist in raspberry foundation land.
Then, we might have a 2nd image which follow upstream and where we might have some things missing such as WiFi. If more versions are needed for testing/developing purpose, then we should use staging projects.
Yes, hence my suggestion to remove the RPi3 contrib and just move it all to Tumbleweed.
Yes, but the condition would be to not loose any functionality in the switch.
The current RPi3 contrib can do exactly as much as 4.8 can, so we don't lose anything :). If we started to enable wifi in the contrib now, we'd lose something. That'd be bad.
Moreover, the current RPi3 Contrib is more a Leap 42.2 Contrib since it uses the 42.2 kernel. Maybe we could just rename it?
42.2 should just natively support the RPi3, we don't need a contrib.
This is how is handled Raspberry Pi 1.
For RPi2, we have only a downstream image since JeOS-raspberrypi2 package is missing in Factory:ARM. I think we could add it. Dirk, could you do it, please?
For the RPi2 we're in the same situation: A downstream 32bit kernel with video decoding and an upstream 32bit kernel (that should work fine with the Tumbleweed kernel) that does not have video decoding capabilities.
Yes, we are just missing the downstream image. ;)
We're not. It's just in the RPi2 repo: http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 13/10/2016 à 11:53, Alexander Graf a écrit :
On 10/13/2016 11:47 AM, Guillaume Gardet wrote:
Le 13/10/2016 à 11:40, Alexander Graf a écrit :
On 10/13/2016 11:34 AM, Guillaume Gardet wrote:
Le 13/10/2016 à 11:07, Alexander Graf a écrit :
On 10/13/2016 10:37 AM, Guillaume Gardet wrote:
Hi,
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
Yeah, that's Andreas' attempt to make a hacky interim solution cleaner.
* dtb-rpi3-aarch64 : pre-compiled bcm2837-rpi-3-b.dtb (from where?)
This is literally assembled by hand.
Current JeOS uses the pre-compiled DT.
WiFi is not working on AArch64 version, and I am wondering if it could be caused by the DTB used.
Probably, yes. IMHO we have 2 options:
1) Keep hacking on the contrib, try to make it work (pretty much a waste of time IMHO) 2) 4.8 has proper RPi3 support, just move all RPi3 enablement to Tumbleweed proper
Would you have time to work on option 2? 4.8 is missing Wifi (which the 4.4 based kernel in contrib includes), but for "normal" things it should be fine.
I do not have much time for that, sorry.
I think we should have a fully (downstream?) working image (32 or 64 bits) including HDMI, and WiFi (and maybe hardware video decoding?).
Hardware video decoding is currently limited to the 32-bit downstream rpi foundation kernel. An image with that one in place already exists here:
https://en.opensuse.org/HCL:Raspberry_Pi3#Installing_the_32-bit_non-upstream...
The devel:ARM:Factory:Contrib:RaspberryPi3 repo is for the 64bit variant which doesn't exist in raspberry foundation land.
Then, we might have a 2nd image which follow upstream and where we might have some things missing such as WiFi. If more versions are needed for testing/developing purpose, then we should use staging projects.
Yes, hence my suggestion to remove the RPi3 contrib and just move it all to Tumbleweed.
Yes, but the condition would be to not loose any functionality in the switch.
The current RPi3 contrib can do exactly as much as 4.8 can, so we don't lose anything :). If we started to enable wifi in the contrib now, we'd lose something. That'd be bad.
Moreover, the current RPi3 Contrib is more a Leap 42.2 Contrib since it uses the 42.2 kernel. Maybe we could just rename it?
42.2 should just natively support the RPi3, we don't need a contrib.
This is how is handled Raspberry Pi 1.
For RPi2, we have only a downstream image since JeOS-raspberrypi2 package is missing in Factory:ARM. I think we could add it. Dirk, could you do it, please?
For the RPi2 we're in the same situation: A downstream 32bit kernel with video decoding and an upstream 32bit kernel (that should work fine with the Tumbleweed kernel) that does not have video decoding capabilities.
Yes, we are just missing the downstream image. ;)
We're not. It's just in the RPi2 repo:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
Sorry, I meant *upstream*. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 13.10.2016 um 11:34 schrieb Guillaume Gardet:
Once 4.8 will be in Factory, lets play with JeOS-raspberrypi3_aarch64 in Factory.
No, no, no! I have already done the heavy lifting for having a JeOS-raspberrypi3 in Factory! Please stop the travesty of suffixing a native aarch64 device's image _aarch64. https://build.opensuse.org/request/show/426843 Also, as I've already reported to Alex based on Kernel:HEAD, 4.8 doesn't boot, apparently due to U-Boot issues. There is no use in enabling an image to build that doesn't boot. Today I will be looking at rebasing your u-boot changelog and submitting it to Base:System, then Alex or Stefan can work on backporting fixes and once those and 4.8 are in Factory we can take the next image steps. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 13.10.2016 um 13:25 schrieb Andreas Färber:
as I've already reported to Alex based on Kernel:HEAD, 4.8 doesn't boot, apparently due to U-Boot issues. There is no use in enabling an image to build that doesn't boot.
Today I will be looking at rebasing your u-boot changelog and submitting it to Base:System,
Please review: https://build.opensuse.org/request/show/434752 Regards, Andreas
then Alex or Stefan can work on backporting fixes and once those and 4.8 are in Factory we can take the next image steps.
Regards, Andreas
-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 13.10.2016 um 11:34 schrieb Guillaume Gardet:
For RPi2, we have only a downstream image since JeOS-raspberrypi2 package is missing in Factory:ARM. I think we could add it. Dirk, could you do it, please?
Objection! Instead please test the remaining bits in: https://build.opensuse.org/package/show/home:a_faerber:branches:openSUSE:Fac... I do not want to needlessly enable a non-GRUB based image in Tumbleweed. Similarly I need someone to test on RPi1: https://build.opensuse.org/package/show/home:a_faerber:branches:openSUSE:Fac... If that works, I can submit it to Factory. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Here are my tests results. Le 13/10/2016 à 13:34, Andreas Färber a écrit :
Am 13.10.2016 um 11:34 schrieb Guillaume Gardet:
For RPi2, we have only a downstream image since JeOS-raspberrypi2 package is missing in Factory:ARM. I think we could add it. Dirk, could you do it, please? Objection! Instead please test the remaining bits in:
https://build.opensuse.org/package/show/home:a_faerber:branches:openSUSE:Fac...
GRUB boots but then I got a blinking underscore on the top left corner of the HDMI screen and finally a black screen. If I reboot after 5 or 10 minutes, I get a GRUB error: "attempt to read or write outside partition".
I do not want to needlessly enable a non-GRUB based image in Tumbleweed.
Similarly I need someone to test on RPi1:
https://build.opensuse.org/package/show/home:a_faerber:branches:openSUSE:Fac...
If that works, I can submit it to Factory.
GRUB boots but then I got a blinking underscore on the top left corner of the HDMI screen (with some vc4 error messages) and after a very long wait, I can ssh to it (no more HDMI output). 2nd boot is broken. I get a GRUB error: "attempt to read or write outside of partition". Guillaume
Regards, Andreas
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Guillaume, Am 13.10.2016 um 16:15 schrieb Guillaume Gardet:
Here are my tests results.
Many thanks for quick testing!
Le 13/10/2016 à 13:34, Andreas Färber a écrit :
Am 13.10.2016 um 11:34 schrieb Guillaume Gardet: please test the remaining bits in:
https://build.opensuse.org/package/show/home:a_faerber:branches:openSUSE:Fac...
GRUB boots but then I got a blinking underscore on the top left corner of the HDMI screen and finally a black screen.
Looks like I missed the config.sh change to switch from fbdev to modesetting. Not sure whether that's the cause though.
If I reboot after 5 or 10 minutes, I get a GRUB error: "attempt to read or write outside partition".
Reboot via SSH? I.e., just no HDMI?
Similarly I need someone to test on RPi1:
https://build.opensuse.org/package/show/home:a_faerber:branches:openSUSE:Fac... [...] GRUB boots but then I got a blinking underscore on the top left corner of the HDMI screen (with some vc4 error messages) and after a very long wait, I can ssh to it (no more HDMI output).
http://bugzilla.suse.com/show_bug.cgi?id=996614
2nd boot is broken. I get a GRUB error: "attempt to read or write outside of partition".
Is the 2nd boot a regression from the Contrib image? Or a general issue? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 13/10/2016 à 17:00, Andreas Färber a écrit :
Hi Guillaume,
Am 13.10.2016 um 16:15 schrieb Guillaume Gardet:
Here are my tests results. Many thanks for quick testing!
Le 13/10/2016 à 13:34, Andreas Färber a écrit :
Am 13.10.2016 um 11:34 schrieb Guillaume Gardet: please test the remaining bits in:
https://build.opensuse.org/package/show/home:a_faerber:branches:openSUSE:Fac... GRUB boots but then I got a blinking underscore on the top left corner of the HDMI screen and finally a black screen. Looks like I missed the config.sh change to switch from fbdev to modesetting. Not sure whether that's the cause though.
If I reboot after 5 or 10 minutes, I get a GRUB error: "attempt to read or write outside partition". Reboot via SSH? I.e., just no HDMI?
No ssh since there is no USB, there is no Ethernet. Just unplug/replug the power supply. ;)
Similarly I need someone to test on RPi1:
https://build.opensuse.org/package/show/home:a_faerber:branches:openSUSE:Fac... [...] GRUB boots but then I got a blinking underscore on the top left corner of the HDMI screen (with some vc4 error messages) and after a very long wait, I can ssh to it (no more HDMI output). http://bugzilla.suse.com/show_bug.cgi?id=996614
2nd boot is broken. I get a GRUB error: "attempt to read or write outside of partition". Is the 2nd boot a regression from the Contrib image? Or a general issue?
Last time I checked Contrib image worked fine. So it is a regression. Moreover, I think that Contrib image does not use GRUB, only u-boot. Maybe the repartition confuses GRUB? Guillaume
Regards, Andreas
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 13.10.2016 um 17:30 schrieb Guillaume Gardet:
Le 13/10/2016 à 17:00, Andreas Färber a écrit :
Am 13.10.2016 um 16:15 schrieb Guillaume Gardet: [RPi2:]
If I reboot [...], I get a GRUB error: "attempt to read or write outside partition".
I am able to reproduce this on second boot with serial (clean reboot). `/sbin/update-bootloader --reinit` did not help. [RPi1:]
2nd boot is broken. I get a GRUB error: "attempt to read or write outside of partition".
I tried some things on the Zero before rebooting: yast bootloader (disabling the gfx), update-bootloader --reinit and grub2-mkconfig -o /boot/grub2/grub.cfg Assuming it would've failed as you report, something I did made the boot succeed. So with the middle one ruled out, that leaves two things to try on the rpi2. I notice that raspberrypi sends output to console=tty1 also for JeOS, whereas raspberrypi2 and raspberrypi3 armv7l don't even for non-JeOS. raspberrypi3_aarch64 non-JeOS does to tty. Will clean that up. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 17.10.2016 um 19:32 schrieb Andreas Färber:
Am 13.10.2016 um 17:30 schrieb Guillaume Gardet:
Le 13/10/2016 à 17:00, Andreas Färber a écrit :
Am 13.10.2016 um 16:15 schrieb Guillaume Gardet: [RPi2:]
If I reboot [...], I get a GRUB error: "attempt to read or write outside partition".
This looks suspicious: [ 0.171496] Calling pre-init stage in system image [ 809.514233] systemd-udevd[1545]: starting version 228 [ 810.029519] device-mapper: uevent: version 1.0.3 [ 810.049938] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised: dm-devel@redhat.com [ 23.774995] Creating dracut based initrd [ 1016.740272] device-mapper: core: cleaned up skiped writing MBR ID for armv7l GPT fdisk (gdisk) version 1.0.1 Caution! After loading partitions, the CRC doesn't check out! Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: damaged Found valid MBR and corrupt GPT. Which do you want to use? (Using the GPT MAY permit recovery of GPT data.) 1 - MBR 2 - GPT 3 - Create blank GPT Your answer: Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu Command (? for help): Expert command (? for help): Recovery/transformation command (? for help): WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one, just hit the Enter key at the below prompt and your MBR partition table will be untouched. Type from one to three GPT partition numbers, separated by spaces, to be added to the hybrid MBR, in sequence: Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): Creating entry for GPT partition #1 (MBR partition #1) Enter an MBR hex code (default EF): Set the bootable flag? (Y/N): Creating entry for GPT partition #2 (MBR partition #2) Enter an MBR hex code (default 83): Set the bootable flag? (Y/N): Creating entry for GPT partition #3 (MBR partition #3) Enter an MBR hex code (default 83): Set the bootable flag? (Y/N): Recovery/transformation command (? for help): Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/mmcblk0. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully. So, apparently we fail to answer to the question, and as a result it doesn't use the new MBR but instead an old GPT it found on the disk? In my case switching from vboot to efi layout, it still had separate boot and root partitions after reboot. Formatting my rpi2 SD card now. My SD card for rpi1 was virgin. Not sure how uboot-image-install.in could handle this any better...? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 17.10.2016 um 20:00 schrieb Andreas Färber:
Am 17.10.2016 um 19:32 schrieb Andreas Färber:
Am 13.10.2016 um 17:30 schrieb Guillaume Gardet:
Le 13/10/2016 à 17:00, Andreas Färber a écrit :
Am 13.10.2016 um 16:15 schrieb Guillaume Gardet: [RPi2:]
If I reboot [...], I get a GRUB error: "attempt to read or write outside partition".
This looks suspicious:
[ 0.171496] Calling pre-init stage in system image [ 809.514233] systemd-udevd[1545]: starting version 228 [ 810.029519] device-mapper: uevent: version 1.0.3 [ 810.049938] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised: dm-devel@redhat.com [ 23.774995] Creating dracut based initrd [ 1016.740272] device-mapper: core: cleaned up skiped writing MBR ID for armv7l GPT fdisk (gdisk) version 1.0.1
Caution! After loading partitions, the CRC doesn't check out! Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: damaged
Found valid MBR and corrupt GPT. Which do you want to use? (Using the GPT MAY permit recovery of GPT data.) 1 - MBR 2 - GPT 3 - Create blank GPT
Your answer: Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu
Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu
Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu
Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu
Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu
Command (? for help): Expert command (? for help): Recovery/transformation command (? for help): WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one, just hit the Enter key at the below prompt and your MBR partition table will be untouched.
Type from one to three GPT partition numbers, separated by spaces, to be added to the hybrid MBR, in sequence: Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): Creating entry for GPT partition #1 (MBR partition #1) Enter an MBR hex code (default EF): Set the bootable flag? (Y/N): Creating entry for GPT partition #2 (MBR partition #2) Enter an MBR hex code (default 83): Set the bootable flag? (Y/N): Creating entry for GPT partition #3 (MBR partition #3) Enter an MBR hex code (default 83): Set the bootable flag? (Y/N): Recovery/transformation command (? for help): Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/mmcblk0. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully.
So, apparently we fail to answer to the question, and as a result it doesn't use the new MBR but instead an old GPT it found on the disk?
For comparison on blank SD card: skiped writing MBR ID for armv7l GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! *************************************************************** Command (? for help): Expert command (? for help): Partition number (1-3): Known attributes are: 0: system partition 1: hide from EFI 2: legacy BIOS bootable 60: read-only 62: hidden 63: do not automount Attribute value is 0000000000000000. Set fields are: No fields set Toggle which attribute field (0-63, 64 or <Enter> to exit): Have enabled the 'legacy BIOS bootable' attribute. Attribute value is 0000000000000004. Set fields are: 2 (legacy BIOS bootable) Toggle which attribute field (0-63, 64 or <Enter> to exit): Expert command (? for help): Command (? for help): Expert command (? for help): Recovery/transformation command (? for help): WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one, just hit the Enter key at the below prompt and your MBR partition table will be untouched. Type from one to three GPT partition numbers, separated by spaces, to be added to the hybrid MBR, in sequence: Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): Creating entry for GPT partition #1 (MBR partition #1) Enter an MBR hex code (default 07): Set the bootable flag? (Y/N): Creating entry for GPT partition #2 (MBR partition #2) Enter an MBR hex code (default 83): Set the bootable flag? (Y/N): Creating entry for GPT partition #3 (MBR partition #3) Enter an MBR hex code (default 82): Set the bootable flag? (Y/N): Recovery/transformation command (? for help): Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/mmcblk0. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 10/17/2016 08:53 PM, Andreas Färber wrote:
Am 17.10.2016 um 20:00 schrieb Andreas Färber:
Am 17.10.2016 um 19:32 schrieb Andreas Färber:
Am 13.10.2016 um 17:30 schrieb Guillaume Gardet:
Le 13/10/2016 à 17:00, Andreas Färber a écrit :
Am 13.10.2016 um 16:15 schrieb Guillaume Gardet: [RPi2:]
If I reboot [...], I get a GRUB error: "attempt to read or write outside partition". This looks suspicious:
[ 0.171496] Calling pre-init stage in system image [ 809.514233] systemd-udevd[1545]: starting version 228 [ 810.029519] device-mapper: uevent: version 1.0.3 [ 810.049938] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised: dm-devel@redhat.com [ 23.774995] Creating dracut based initrd [ 1016.740272] device-mapper: core: cleaned up skiped writing MBR ID for armv7l GPT fdisk (gdisk) version 1.0.1
Caution! After loading partitions, the CRC doesn't check out! Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: damaged
Found valid MBR and corrupt GPT. Which do you want to use? (Using the GPT MAY permit recovery of GPT data.) 1 - MBR 2 - GPT 3 - Create blank GPT
Your answer: Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu
Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu
Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu
Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu
Command (? for help): b back up GPT data to a file c change a partition's name d delete a partition i show detailed information on a partition l list known partition types n add a new partition o create a new empty GUID partition table (GPT) p print the partition table q quit without saving changes r recovery and transformation options (experts only) s sort partitions t change a partition's type code v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu
Command (? for help): Expert command (? for help): Recovery/transformation command (? for help): WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one, just hit the Enter key at the below prompt and your MBR partition table will be untouched.
Type from one to three GPT partition numbers, separated by spaces, to be added to the hybrid MBR, in sequence: Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): Creating entry for GPT partition #1 (MBR partition #1) Enter an MBR hex code (default EF): Set the bootable flag? (Y/N): Creating entry for GPT partition #2 (MBR partition #2) Enter an MBR hex code (default 83): Set the bootable flag? (Y/N): Creating entry for GPT partition #3 (MBR partition #3) Enter an MBR hex code (default 83): Set the bootable flag? (Y/N): Recovery/transformation command (? for help): Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/mmcblk0. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully.
So, apparently we fail to answer to the question, and as a result it doesn't use the new MBR but instead an old GPT it found on the disk? For comparison on blank SD card:
skiped writing MBR ID for armv7l GPT fdisk (gdisk) version 1.0.1
Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present
*************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! ***************************************************************
Command (? for help): Expert command (? for help): Partition number (1-3): Known attributes are: 0: system partition 1: hide from EFI 2: legacy BIOS bootable 60: read-only 62: hidden 63: do not automount
Attribute value is 0000000000000000. Set fields are: No fields set
Toggle which attribute field (0-63, 64 or <Enter> to exit): Have enabled the 'legacy BIOS bootable' attribute. Attribute value is 0000000000000004. Set fields are: 2 (legacy BIOS bootable)
Toggle which attribute field (0-63, 64 or <Enter> to exit): Expert command (? for help): Command (? for help): Expert command (? for help): Recovery/transformation command (? for help): WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one, just hit the Enter key at the below prompt and your MBR partition table will be untouched.
Type from one to three GPT partition numbers, separated by spaces, to be added to the hybrid MBR, in sequence: Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): Creating entry for GPT partition #1 (MBR partition #1) Enter an MBR hex code (default 07): Set the bootable flag? (Y/N): Creating entry for GPT partition #2 (MBR partition #2) Enter an MBR hex code (default 83): Set the bootable flag? (Y/N): Creating entry for GPT partition #3 (MBR partition #3) Enter an MBR hex code (default 82): Set the bootable flag? (Y/N): Recovery/transformation command (? for help): Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/mmcblk0. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully.
Ok, that basically means that kiwi doesn't fix up the GPT properly if it's installing onto a disk that already has a GPT. Marcus, if I dd a "short" OEM image with GPT onto a disk that already has a GPT, we now have 3 GPT tables: * beginning of the disk * middle of the disk (from the kiwi image) * end of the disk (from the old system) In such a situation I wouldn't be surprised if gdisk behaves differently from the typical case where we just find lots of zeros at the end of the disk. The errors above are really just a side effect of that. Thanks, Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
Ok, that basically means that kiwi doesn't fix up the GPT properly if it's installing onto a disk that already has a GPT.
Marcus, if I dd a "short" OEM image with GPT onto a disk that already has a GPT, we now have 3 GPT tables:
* beginning of the disk * middle of the disk (from the kiwi image) * end of the disk (from the old system)
In such a situation I wouldn't be surprised if gdisk behaves differently from the typical case where we just find lots of zeros at the end of the disk. The errors above are really just a side effect of that.
There is code in kiwi which should fix that. The method is called relocateGPTAtEndOfDisk and should cleanup the mismatch between new gpt at start and potentially old data at the end gdisk ist called with x e w y but only if gdisk ist part of the initrd. If not you should see a log message "Warning, gdisk tool not found" Could you check that ? Thanks Regards, Marcus -- Public Key available via: https://keybase.io keybase search marcus_schaefer ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE Linux GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg HRB: 21284 (AG Nürnberg) Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton 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 Marcus, Am 18.10.2016 um 19:21 schrieb Marcus Schäfer:
Marcus, if I dd a "short" OEM image with GPT onto a disk that already has a GPT, we now have 3 GPT tables:
* beginning of the disk * middle of the disk (from the kiwi image) * end of the disk (from the old system)
In such a situation I wouldn't be surprised if gdisk behaves differently from the typical case where we just find lots of zeros at the end of the disk. The errors above are really just a side effect of that.
There is code in kiwi which should fix that. The method is called relocateGPTAtEndOfDisk and should cleanup the mismatch between new gpt at start and potentially old data at the end
gdisk ist called with
x e w y
but only if gdisk ist part of the initrd. If not you should see a log message "Warning, gdisk tool not found"
Could you check that ?
Unfortunately I no longer have the full log in front of me right now... gdisk comes from package gptfdisk, right? We have: <package name="gptfdisk"/> Are you saying that needs a bootinclude="true"? https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/JeOS-... Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (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.10.2016 um 19:29 schrieb Andreas Färber:
Hi Marcus,
Am 18.10.2016 um 19:21 schrieb Marcus Schäfer:
Marcus, if I dd a "short" OEM image with GPT onto a disk that already has a GPT, we now have 3 GPT tables:
* beginning of the disk * middle of the disk (from the kiwi image) * end of the disk (from the old system)
In such a situation I wouldn't be surprised if gdisk behaves differently from the typical case where we just find lots of zeros at the end of the disk. The errors above are really just a side effect of that.
There is code in kiwi which should fix that. The method is called relocateGPTAtEndOfDisk and should cleanup the mismatch between new gpt at start and potentially old data at the end
gdisk ist called with
x e w y
but only if gdisk ist part of the initrd. If not you should see a log message "Warning, gdisk tool not found"
Could you check that ?
Unfortunately I no longer have the full log in front of me right now...
gdisk comes from package gptfdisk, right? We have: <package name="gptfdisk"/> Are you saying that needs a bootinclude="true"?
https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/JeOS-...
Untested proposal: https://build.opensuse.org/request/show/435950
Regards, Andreas
-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
gdisk comes from package gptfdisk, right? We have: <package name="gptfdisk"/> Are you saying that needs a bootinclude="true"?
yes Regards, Marcus -- Public Key available via: https://keybase.io keybase search marcus_schaefer ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE Linux GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg HRB: 21284 (AG Nürnberg) Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton 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 13.10.2016 um 11:34 schrieb Guillaume Gardet:
I think we should have a fully (downstream?) working image (32 or 64 bits) including HDMI, and WiFi (and maybe hardware video decoding?). Then, we might have a 2nd image which follow upstream and where we might have some things missing such as WiFi. If more versions are needed for testing/developing purpose, then we should use staging projects.
This is how is handled Raspberry Pi 1.
The way that Raspberry Pi 1 is "handled" is that no one is taking care of the downstream Contrib image [*], but most users are misguided to use that downstream image and complain about it on this list. Which is annoying for people like me working on the official Tumbleweed kernel, because no one involved with the Contrib project bothers to even reply to the reports... [*] As reported multiple times, kernel-raspberrypi fails to build: https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryP... Also keep in mind that openSUSE on x86 does not provide, e.g., Nvidia drivers in a Contrib either. Therefore I am a strong advocate of switching to an official openSUSE image once the core drivers are in place. If someone wants extra acceleration, they should build a KMP, not a full separate image. Compare my earlier work on Mali: https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Mali Even better work on or lobby the vendor for getting drivers upstream, if you need them. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 13/10/2016 à 13:58, Andreas Färber a écrit :
I think we should have a fully (downstream?) working image (32 or 64 bits) including HDMI, and WiFi (and maybe hardware video decoding?). Then, we might have a 2nd image which follow upstream and where we might have some things missing such as WiFi. If more versions are needed for testing/developing purpose, then we should use staging projects.
This is how is handled Raspberry Pi 1. The way that Raspberry Pi 1 is "handled" is that no one is taking care of the downstream Contrib image [*], but most users are misguided to use
Am 13.10.2016 um 11:34 schrieb Guillaume Gardet: that downstream image and complain about it on this list. Which is annoying for people like me working on the official Tumbleweed kernel, because no one involved with the Contrib project bothers to even reply to the reports...
What are the problems? I have some Pi 1 and Pi 2 running fine here with Contrib kernel.
[*] As reported multiple times, kernel-raspberrypi fails to build: https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryP...
Yes, I know, it is a warning which turned in an error with recent GCC. I will try to have a look.
Also keep in mind that openSUSE on x86 does not provide, e.g., Nvidia drivers in a Contrib either.
Therefore I am a strong advocate of switching to an official openSUSE image once the core drivers are in place. If someone wants extra acceleration, they should build a KMP, not a full separate image. Compare my earlier work on Mali: https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Mali Even better work on or lobby the vendor for getting drivers upstream, if you need them.
Yes, KMP would be far better, but, AFAIK, there is no KMP source package available for RPi. :( Guillaume
Regards, Andreas
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, dtb-rpi3-aarch64 is massively outdated and should not be used. Either the one integrated into u-boot (https://github.com/openSUSE/u-boot/pull/1) or a recent dtb-aarch64 must be used. The one in u-boot got reverted by Andreas. (In fact, the PR has the DT from the TW kernel, so no wifi either) To get WLAN to work, all following conditions must be met: - sdhci-iproc not in initrd (blacklisted in /etc/dracut.conf.d/*) - DT maps WiFi SDIO to bcm2835-sdhci/-iproc controller - DT maps MMC to bcm2835-sdhost controller - Firmware installed Cheers, Fabian Am Donnerstag, 13. Oktober 2016, 10:37:53 CEST schrieb Guillaume Gardet:
Hi,
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too. * dtb-rpi3-aarch64 : pre-compiled bcm2837-rpi-3-b.dtb (from where?)
Current JeOS uses the pre-compiled DT.
WiFi is not working on AArch64 version, and I am wondering if it could be caused by the DTB used.
Alex, Andreas, any idea?
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Freitag, 14. Oktober 2016, 17:36:14 CEST schrieb Fabian Vogt:
Hi,
dtb-rpi3-aarch64 is massively outdated and should not be used. Either the one integrated into u-boot (https://github.com/openSUSE/u-boot/pull/1) or a recent dtb-aarch64 must be used. The one in u-boot got reverted by Andreas. (In fact, the PR has the DT from the TW kernel, so no wifi either)
I have to correct this, I just looked at the wrong commit. Everything needed is in the PR. So u-boot with this PR un-reverted would work.
To get WLAN to work, all following conditions must be met:
- sdhci-iproc not in initrd (blacklisted in /etc/dracut.conf.d/*) - DT maps WiFi SDIO to bcm2835-sdhci/-iproc controller - DT maps MMC to bcm2835-sdhost controller - Firmware installed
Cheers, Fabian
Am Donnerstag, 13. Oktober 2016, 10:37:53 CEST schrieb Guillaume Gardet:
Hi,
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too. * dtb-rpi3-aarch64 : pre-compiled bcm2837-rpi-3-b.dtb (from where?)
Current JeOS uses the pre-compiled DT.
WiFi is not working on AArch64 version, and I am wondering if it could be caused by the DTB used.
Alex, Andreas, any idea?
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 14.10.2016 um 18:56 schrieb Fabian Vogt:
Am Freitag, 14. Oktober 2016, 17:36:14 CEST schrieb Fabian Vogt:
dtb-rpi3-aarch64 is massively outdated and should not be used. Either the one integrated into u-boot (https://github.com/openSUSE/u-boot/pull/1) or a recent dtb-aarch64 must be used. The one in u-boot got reverted by Andreas. (In fact, the PR has the DT from the TW kernel, so no wifi either)
I have to correct this, I just looked at the wrong commit. Everything needed is in the PR. So u-boot with this PR un-reverted would work.
Let's fully correct this then: You never did a Submit Request for Base:System/u-boot with those patches and a changelog entry. That blocked other OBS SRs after Dirk merged your GitHub PR, so reverting was the option we chose so that we could accept other incoming SRs again. Don't blame your omission on me! ;) Your patches are still archived in GitHub. They will need to be rebased from v2016.07 onto v2016.09.01 if you still want to submit them, and I was told there were newer versions of your patches, too. Please always submit the latest versions here, so that future rebases onto releases with those patches merged work without hassle (and that includes, e.g., trivial whitespace changes any upstream maintainers may request). Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Freitag, 14. Oktober 2016, 20:09:40 CEST schrieb Andreas Färber:
Am 14.10.2016 um 18:56 schrieb Fabian Vogt:
Am Freitag, 14. Oktober 2016, 17:36:14 CEST schrieb Fabian Vogt:
dtb-rpi3-aarch64 is massively outdated and should not be used. Either the one integrated into u-boot (https://github.com/openSUSE/u-boot/pull/1) or a recent dtb-aarch64 must be used. The one in u-boot got reverted by Andreas. (In fact, the PR has the DT from the TW kernel, so no wifi either)
I have to correct this, I just looked at the wrong commit. Everything needed is in the PR. So u-boot with this PR un-reverted would work.
Let's fully correct this then: You never did a Submit Request for Base:System/u-boot with those patches and a changelog entry.
I did: https://build.opensuse.org/request/show/427604
That blocked other OBS SRs after Dirk merged your GitHub PR, so reverting was the option we chose so that we could accept other incoming SRs again. Don't blame your omission on me! ;)
Your patches are still archived in GitHub. They will need to be rebased from v2016.07 onto v2016.09.01 if you still want to submit them, and I was told there were newer versions of your patches, too. Please always submit the latest versions here, so that future rebases onto releases with those patches merged work without hassle (and that includes, e.g., trivial whitespace changes any upstream maintainers may request).
Sure, tumbleweed or tumbleweed-staging?
Cheers, Andreas
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 14.10.2016 um 20:43 schrieb Fabian Vogt:
Am Freitag, 14. Oktober 2016, 20:09:40 CEST schrieb Andreas Färber:
Am 14.10.2016 um 18:56 schrieb Fabian Vogt:
Am Freitag, 14. Oktober 2016, 17:36:14 CEST schrieb Fabian Vogt:
dtb-rpi3-aarch64 is massively outdated and should not be used. Either the one integrated into u-boot (https://github.com/openSUSE/u-boot/pull/1) or a recent dtb-aarch64 must be used. The one in u-boot got reverted by Andreas. (In fact, the PR has the DT from the TW kernel, so no wifi either)
I have to correct this, I just looked at the wrong commit. Everything needed is in the PR. So u-boot with this PR un-reverted would work.
Let's fully correct this then: You never did a Submit Request for Base:System/u-boot with those patches and a changelog entry.
OK, correction: Nobody accepted sr#427604 despite merging the patches. Which blocked other SRs. In that case Dirk's fault for merging and Alex' for not reviewing the changes he suggested to you. ;)
That blocked other OBS SRs after Dirk merged your GitHub PR, so reverting was the option we chose so that we could accept other incoming SRs again. Don't blame your omission on me! ;)
Your patches are still archived in GitHub. They will need to be rebased from v2016.07 onto v2016.09.01 if you still want to submit them, and I was told there were newer versions of your patches, too. Please always submit the latest versions here, so that future rebases onto releases with those patches merged work without hassle (and that includes, e.g., trivial whitespace changes any upstream maintainers may request).
Sure, tumbleweed or tumbleweed-staging?
Neither, look at Base:System/u-boot update_git.sh: I renamed it to tumbleweed-2016.09 because I couldn't really submit update_git.sh with "tumbleweed-staging" to non-staging Base:System. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Guillaume, Am 13.10.2016 um 10:37 schrieb Guillaume Gardet:
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
I've recovered my rpi3 setup and successfully tested the above .dtb now: It showed the wlan0 interface. :) Booting required changes to /etc/dracut.conf.d/raspberrypi_modules.conf: * Add bcm2835-sdhost to add_drivers line * Add new line omit_drivers+=" sdhci-iproc" (courtesy of Fabian) (Remember to run mkinitrd or dracut with suitable options afterwards.) I'll later prepare a JeOS SR making the switch. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (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.10.2016 um 11:59 schrieb Andreas Färber <afaerber@suse.de>:
Hi Guillaume,
Am 13.10.2016 um 10:37 schrieb Guillaume Gardet: On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
I've recovered my rpi3 setup and successfully tested the above .dtb now: It showed the wlan0 interface. :)
Booting required changes to /etc/dracut.conf.d/raspberrypi_modules.conf: * Add bcm2835-sdhost to add_drivers line * Add new line omit_drivers+=" sdhci-iproc" (courtesy of Fabian)
(Remember to run mkinitrd or dracut with suitable options afterwards.)
I'll later prepare a JeOS SR making the switch.
Please beware that this renders the image incompatible with upstream kernels, so you can't just install 4.8 and have it work. Alex
Regards, Andreas
-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 15.10.2016 um 12:07 schrieb Alexander Graf:
Am 15.10.2016 um 11:59 schrieb Andreas Färber <afaerber@suse.de>:
Am 13.10.2016 um 10:37 schrieb Guillaume Gardet:
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
I've recovered my rpi3 setup and successfully tested the above .dtb now: It showed the wlan0 interface. :)
Booting required changes to /etc/dracut.conf.d/raspberrypi_modules.conf: * Add bcm2835-sdhost to add_drivers line * Add new line omit_drivers+=" sdhci-iproc" (courtesy of Fabian)
(Remember to run mkinitrd or dracut with suitable options afterwards.)
I'll later prepare a JeOS SR making the switch.
Please beware that this renders the image incompatible with upstream kernels, so you can't just install 4.8 and have it work.
Yes, but we don't yet have a working 4.8 image anyway. I have tested adding sdhci-iproc to add_drivers and commenting out the omit_drivers line, but we still get stuck in efistub with v2016.09.01. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (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.10.2016 um 12:14 schrieb Andreas Färber <afaerber@suse.de>:
Am 15.10.2016 um 12:07 schrieb Alexander Graf:
Am 15.10.2016 um 11:59 schrieb Andreas Färber <afaerber@suse.de>:
Am 13.10.2016 um 10:37 schrieb Guillaume Gardet: On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
I've recovered my rpi3 setup and successfully tested the above .dtb now: It showed the wlan0 interface. :)
Booting required changes to /etc/dracut.conf.d/raspberrypi_modules.conf: * Add bcm2835-sdhost to add_drivers line * Add new line omit_drivers+=" sdhci-iproc" (courtesy of Fabian)
(Remember to run mkinitrd or dracut with suitable options afterwards.)
I'll later prepare a JeOS SR making the switch.
Please beware that this renders the image incompatible with upstream kernels, so you can't just install 4.8 and have it work.
Yes, but we don't yet have a working 4.8 image anyway.
What I'm worried about is that we block the upgrade path. A JeOS image which blacklists iproc won't be able to upgrade to a newer kernel - unless the bcm2835-sdhost driver also goes upstream.
I have tested adding sdhci-iproc to add_drivers and commenting out the omit_drivers line, but we still get stuck in efistub with v2016.09.01.
Well, that's an orthogonal and temporary issue until we get a working u-boot binary which we can even push into 42.2. Writing unversioned blacklists is something we can't fix with a package update. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 15.10.2016 um 13:09 schrieb Alexander Graf:
Am 15.10.2016 um 12:14 schrieb Andreas Färber <afaerber@suse.de>:
Am 15.10.2016 um 12:07 schrieb Alexander Graf:
Am 15.10.2016 um 11:59 schrieb Andreas Färber <afaerber@suse.de>:
Am 13.10.2016 um 10:37 schrieb Guillaume Gardet:
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
I've recovered my rpi3 setup and successfully tested the above .dtb now: It showed the wlan0 interface. :)
Booting required changes to /etc/dracut.conf.d/raspberrypi_modules.conf: * Add bcm2835-sdhost to add_drivers line * Add new line omit_drivers+=" sdhci-iproc" (courtesy of Fabian)
(Remember to run mkinitrd or dracut with suitable options afterwards.)
I'll later prepare a JeOS SR making the switch.
Please beware that this renders the image incompatible with upstream kernels, so you can't just install 4.8 and have it work.
Yes, but we don't yet have a working 4.8 image anyway.
What I'm worried about is that we block the upgrade path. A JeOS image which blacklists iproc won't be able to upgrade to a newer kernel - unless the bcm2835-sdhost driver also goes upstream.
Well, what alternative solution is there? The upgrade path is already blocked today for rpi3, rpi2 and rpi for lack of sdhci-iproc. And I am trying to close a bug here: https://bugzilla.opensuse.org/show_bug.cgi?id=989713 We could add both drivers to add_drivers for raspberrypi3_aarch64 for futureproofness - that should not regress then. But supposedly without the omit_drivers there were probing issues. I can leave that commented out, but that's no full solution for the bug in the current image then. Also FTR I have repeatedly said that in order to update these config files we should put them in a package; but you Alex were against that, saying they were just temporary hacks and shouldn't need to exist at all. We need to die one death or another! Either people need to manually tweak the configs from time to time, or we can't just throw them into the JeOS package. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 15 Oct 2016, at 13:37, Andreas Färber <afaerber@suse.de> wrote:
Am 15.10.2016 um 13:09 schrieb Alexander Graf:
Am 15.10.2016 um 12:14 schrieb Andreas Färber <afaerber@suse.de>:
Am 15.10.2016 um 12:07 schrieb Alexander Graf:
Am 15.10.2016 um 11:59 schrieb Andreas Färber <afaerber@suse.de>:
Am 13.10.2016 um 10:37 schrieb Guillaume Gardet:
On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too.
I've recovered my rpi3 setup and successfully tested the above .dtb now: It showed the wlan0 interface. :)
Booting required changes to /etc/dracut.conf.d/raspberrypi_modules.conf: * Add bcm2835-sdhost to add_drivers line * Add new line omit_drivers+=" sdhci-iproc" (courtesy of Fabian)
(Remember to run mkinitrd or dracut with suitable options afterwards.)
I'll later prepare a JeOS SR making the switch.
Please beware that this renders the image incompatible with upstream kernels, so you can't just install 4.8 and have it work.
Yes, but we don't yet have a working 4.8 image anyway.
What I'm worried about is that we block the upgrade path. A JeOS image which blacklists iproc won't be able to upgrade to a newer kernel - unless the bcm2835-sdhost driver also goes upstream.
Well, what alternative solution is there? The upgrade path is already blocked today for rpi3, rpi2 and rpi for lack of sdhci-iproc. And I am trying to close a bug here:
https://bugzilla.opensuse.org/show_bug.cgi?id=989713
We could add both drivers to add_drivers for raspberrypi3_aarch64 for futureproofness - that should not regress then. But supposedly without the omit_drivers there were probing issues. I can leave that commented out, but that's no full solution for the bug in the current image then.
Also FTR I have repeatedly said that in order to update these config files we should put them in a package; but you Alex were against that, saying they were just temporary hacks and shouldn't need to exist at all. We need to die one death or another! Either people need to manually tweak the configs from time to time, or we can't just throw them into the JeOS package.
Yeah, I guess putting them into board support packages is the sane way to go in this case. Then we can at least have the “normal” upgrade path work. So people will be able to upgrade Tumbleweed from contrib to proper or 42.2 to 42.3. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 15.10.2016 um 13:37 schrieb Andreas Färber:
We could add both drivers to add_drivers for raspberrypi3_aarch64 for futureproofness - that should not regress then. But supposedly without the omit_drivers there were probing issues. I can leave that commented out, but that's no full solution for the bug in the current image then.
Alex, please review: https://build.opensuse.org/request/show/435498 Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (5)
-
Alexander Graf -
Andreas Färber -
Fabian Vogt -
Guillaume Gardet -
Marcus Schäfer