Re: [opensuse-arm] Samsung Chromebook current tumbleweed images
Hello, Just get time to run more tests. Kernel-source branch stable compiled with exynos_defconfig boots fine, tried 4.1.3, screen working i was able to reach login on first boot. Dmesg http://paste.opensuse.org/54891427 --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Thu, Jul 23, 2015 at 3:16 PM, Andreas Färber afaer...@suse.de wrote: Hi, Am 20.07.2015 um 14:28 schrieb Guillaume Gardet: Le 19/07/2015 18:15, Misha Komarovskiy a écrit : Also lcd screen stays black after kernel start, probably some drm module still missing. Upstream kernel is broken. :( How did you test? Actually there's a known issue that the Exynos IOMMU support breaks graphics on the Chromebooks because they enable a framebuffer early in bootloaders, before Linux initializes the IOMMU. Since some other platforms do need the IOMMU, I fear that we're going to need a new kernel flavor... :/ Not sure if that can be scripted as lpae minus certain options? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Samsung Chromebook current tumbleweed images
Hello Guillaume, I tested both exynos_defconfig and multi_v7_defconfig, they work fine. But ill test lpae config without EXYNOS_IOMMU today and will report. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Mon, Aug 17, 2015 at 9:59 AM, Guillaume Gardet guillaume.gar...@free.fr wrote: Hi, Le 16/08/2015 21:59, Misha Komarovskiy a écrit : Hello, Maybe we can disable only Exynos IOMMU in configs for now? Same way it is disabled in current exynos_defconfig here https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/configs/exynos_defconfig?id=6562f3bd396ab6d2c9b455e95c67e33bab73bff5 As i understand it is broken for all exynos devices not only snow. That is exactly what I would like to do since I read this thread: https://lkml.org/lkml/2015/2/17/163 Before submitting the idea here, I wanted to check if disabling Exynos IOMMU in config was enough. I had only time to test the exynos_defconfig with openSUSE kernel and it was OK (boot messages and login prompt displayed). Guillaume --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Thu, Jul 23, 2015 at 4:29 PM, Alexander Graf ag...@suse.de wrote: Am 23.07.2015 um 15:15 schrieb Andreas Färber afaer...@suse.de: Am 23.07.2015 um 15:12 schrieb Alexander Graf: On 07/23/15 14:43, Andreas Färber wrote: Am 23.07.2015 um 14:22 schrieb Guillaume Gardet: Maybe some config options compiled as module (which?) and blacklisted for chromebooks could be ok? Maybe. Someone with a Chromebook needs to sit down and try. :) Hrm, rather than disable it one way or another manually, couldn't we just blacklist it inside the kernel? I doubt that we can load iommu as module... You mean as in patch the iommu probe code to check for google,snow, google,spring, etc.? For example - or remove the respective dt node. Or as a property to the IOMMU dt node... Alex Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Samsung Chromebook current tumbleweed images
I made test on already installed image. Connected with usb network dongle, cloned kernel-source git, made sequence-patch to 4.1 source, copied modified lpae kernel config then booted resulting kernel. This extra modules i tried to add to /etc/modules-load.d/ and system start fine this way without manual modprobing, but this is not same as dracut config as i understand. I never tried to branch kernel-source repo on obs to create custom config, i can make this test also if you can give me please some directions on how to properly create modified kernel branch. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Mon, Aug 17, 2015 at 2:53 PM, Guillaume Gardet guillaume.gar...@free.fr wrote: Le 17/08/2015 13:30, Misha Komarovskiy a écrit : Just tested lpae config without CONFIG_EXYNOS_IOMMU on snow, system boots with black screen same, then modprobe cros_ec_devs, ptn3460, pwm-samsung makes panel start to work without kernel panic. Thanks for your tests. Could you add thoses modules to /etc/dracut.conf.d/exynos_modules.conf with the new line: add_drivers += cros_ec_devs ptn3460 pwm-samsung and recreate initrd with dracut and check if it boots fine? If it does not work, try 'force_drivers+=' instead of 'add_drivers +=' and recreate initrd. Guillaume --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Mon, Aug 17, 2015 at 12:01 PM, Misha Komarovskiy zom...@gmail.com wrote: Hello Guillaume, I tested both exynos_defconfig and multi_v7_defconfig, they work fine. But ill test lpae config without EXYNOS_IOMMU today and will report. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Mon, Aug 17, 2015 at 9:59 AM, Guillaume Gardet guillaume.gar...@free.fr wrote: Hi, Le 16/08/2015 21:59, Misha Komarovskiy a écrit : Hello, Maybe we can disable only Exynos IOMMU in configs for now? Same way it is disabled in current exynos_defconfig here https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/configs/exynos_defconfig?id=6562f3bd396ab6d2c9b455e95c67e33bab73bff5 As i understand it is broken for all exynos devices not only snow. That is exactly what I would like to do since I read this thread: https://lkml.org/lkml/2015/2/17/163 Before submitting the idea here, I wanted to check if disabling Exynos IOMMU in config was enough. I had only time to test the exynos_defconfig with openSUSE kernel and it was OK (boot messages and login prompt displayed). Guillaume --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Thu, Jul 23, 2015 at 4:29 PM, Alexander Graf ag...@suse.de wrote: Am 23.07.2015 um 15:15 schrieb Andreas Färber afaer...@suse.de: Am 23.07.2015 um 15:12 schrieb Alexander Graf: On 07/23/15 14:43, Andreas Färber wrote: Am 23.07.2015 um 14:22 schrieb Guillaume Gardet: Maybe some config options compiled as module (which?) and blacklisted for chromebooks could be ok? Maybe. Someone with a Chromebook needs to sit down and try. :) Hrm, rather than disable it one way or another manually, couldn't we just blacklist it inside the kernel? I doubt that we can load iommu as module... You mean as in patch the iommu probe code to check for google,snow, google,spring, etc.? For example - or remove the respective dt node. Or as a property to the IOMMU dt node... Alex Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Samsung Chromebook current tumbleweed images
Just tested lpae config without CONFIG_EXYNOS_IOMMU on snow, system boots with black screen same, then modprobe cros_ec_devs, ptn3460, pwm-samsung makes panel start to work without kernel panic. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Mon, Aug 17, 2015 at 12:01 PM, Misha Komarovskiy zom...@gmail.com wrote: Hello Guillaume, I tested both exynos_defconfig and multi_v7_defconfig, they work fine. But ill test lpae config without EXYNOS_IOMMU today and will report. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Mon, Aug 17, 2015 at 9:59 AM, Guillaume Gardet guillaume.gar...@free.fr wrote: Hi, Le 16/08/2015 21:59, Misha Komarovskiy a écrit : Hello, Maybe we can disable only Exynos IOMMU in configs for now? Same way it is disabled in current exynos_defconfig here https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/configs/exynos_defconfig?id=6562f3bd396ab6d2c9b455e95c67e33bab73bff5 As i understand it is broken for all exynos devices not only snow. That is exactly what I would like to do since I read this thread: https://lkml.org/lkml/2015/2/17/163 Before submitting the idea here, I wanted to check if disabling Exynos IOMMU in config was enough. I had only time to test the exynos_defconfig with openSUSE kernel and it was OK (boot messages and login prompt displayed). Guillaume --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Thu, Jul 23, 2015 at 4:29 PM, Alexander Graf ag...@suse.de wrote: Am 23.07.2015 um 15:15 schrieb Andreas Färber afaer...@suse.de: Am 23.07.2015 um 15:12 schrieb Alexander Graf: On 07/23/15 14:43, Andreas Färber wrote: Am 23.07.2015 um 14:22 schrieb Guillaume Gardet: Maybe some config options compiled as module (which?) and blacklisted for chromebooks could be ok? Maybe. Someone with a Chromebook needs to sit down and try. :) Hrm, rather than disable it one way or another manually, couldn't we just blacklist it inside the kernel? I doubt that we can load iommu as module... You mean as in patch the iommu probe code to check for google,snow, google,spring, etc.? For example - or remove the respective dt node. Or as a property to the IOMMU dt node... Alex Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] U-Boot 2015.10-rc1 ASIX Usb ethernet dongle
Hello, With update to U-Boot 2015.10-rc1 ASIX Usb ethernet dongle not detected as ethernet device anymore, but visible as usb device in usb info, tested on Chromebook Snow. Worked fine with 2015.07-rc3 in both usb2 and usb3 ports. Maybe this happen because of removal add_snow_usb_boot.patch? I didn't tried clean upstream versions yet, specific snow patch was my first guess. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] U-Boot 2015.10-rc1 ASIX Usb ethernet dongle
I have some problems with serial console connection, cant catch error without noise, but maybe this can say you something where to start or better to write to u-boot ml? U-Boot 2015.10-rc2-00064-g8d77576 (Aug 21 2015 - 15:33:06 +) for snow CPU: Exynos5250 @ 9.7 GH� ERROR: read error from`devmce���?�mm~�?686.g44/max77686_read() initcall sequence bfdaf3dc failed at call 43e04190 (err=-5) ### ERROR ### Please RESET the board ### --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Fri, Aug 21, 2015 at 6:14 PM, Guillaume Gardet guillaume.gar...@free.fr wrote: Le 21/08/2015 17:08, Misha Komarovskiy a écrit : Hello Guillaume, I confirm it is upstream U-Boot problem. Something between 2015.07 and 2015.10-rc1 breaks detection of asix dongle here as Usb ethernet device, but continue to see it as just plain usb device. 2015.10-rc2 wont boot on snow at all for me. I will continue research and let you know. Wow. If 2015.10-rc2 does not boot at all whereas 2015.10-rc1 did, you should give the information upstream! To help you find where the problem is, you can use git bisect tool with the u-boot git repo. Guillaume --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Fri, Aug 21, 2015 at 4:08 PM, Guillaume Gardet guillaume.gar...@free.fr wrote: Hi, Le 21/08/2015 14:39, Misha Komarovskiy a écrit : Hello, With update to U-Boot 2015.10-rc1 ASIX Usb ethernet dongle not detected as ethernet device anymore, but visible as usb device in usb info, tested on Chromebook Snow. Worked fine with 2015.07-rc3 in both usb2 and usb3 ports. Could you try with upstream 2015.10-rc1 and 2015.07-rc3, please? It is maybe you just need to run 'usb start' and/or other commands? Maybe this happen because of removal add_snow_usb_boot.patch? I didn't tried clean upstream versions yet, specific snow patch was my first guess. I do not think this old patch is the cause since it has been dropped because upstream was fixed. Guillaume --- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] U-Boot 2015.10-rc1 ASIX Usb ethernet dongle
Hello Guillaume, I confirm it is upstream U-Boot problem. Something between 2015.07 and 2015.10-rc1 breaks detection of asix dongle here as Usb ethernet device, but continue to see it as just plain usb device. 2015.10-rc2 wont boot on snow at all for me. I will continue research and let you know. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Fri, Aug 21, 2015 at 4:08 PM, Guillaume Gardet guillaume.gar...@free.fr wrote: Hi, Le 21/08/2015 14:39, Misha Komarovskiy a écrit : Hello, With update to U-Boot 2015.10-rc1 ASIX Usb ethernet dongle not detected as ethernet device anymore, but visible as usb device in usb info, tested on Chromebook Snow. Worked fine with 2015.07-rc3 in both usb2 and usb3 ports. Could you try with upstream 2015.10-rc1 and 2015.07-rc3, please? It is maybe you just need to run 'usb start' and/or other commands? Maybe this happen because of removal add_snow_usb_boot.patch? I didn't tried clean upstream versions yet, specific snow patch was my first guess. I do not think this old patch is the cause since it has been dropped because upstream was fixed. Guillaume --- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Samsung Chromebook current tumbleweed images
Hello, Maybe we can disable only Exynos IOMMU in configs for now? Same way it is disabled in current exynos_defconfig here https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/configs/exynos_defconfig?id=6562f3bd396ab6d2c9b455e95c67e33bab73bff5 As i understand it is broken for all exynos devices not only snow. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Thu, Jul 23, 2015 at 4:29 PM, Alexander Graf ag...@suse.de wrote: Am 23.07.2015 um 15:15 schrieb Andreas Färber afaer...@suse.de: Am 23.07.2015 um 15:12 schrieb Alexander Graf: On 07/23/15 14:43, Andreas Färber wrote: Am 23.07.2015 um 14:22 schrieb Guillaume Gardet: Maybe some config options compiled as module (which?) and blacklisted for chromebooks could be ok? Maybe. Someone with a Chromebook needs to sit down and try. :) Hrm, rather than disable it one way or another manually, couldn't we just blacklist it inside the kernel? I doubt that we can load iommu as module... You mean as in patch the iommu probe code to check for google,snow, google,spring, etc.? For example - or remove the respective dt node. Or as a property to the IOMMU dt node... Alex Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] armv7hl kernel-default config have tegra20 serial output broken
Hello, I found that latest images for my armv7 board (paz00/ac100) which use kernel-default have kernel panic on start without any output to serial console, but serial output was working last time i tested image back in may. I cloned kernel-source git repo made sequence-patched kernel and recompiled it with enabling DEBUG_LL,TEGRA UART_A and EARLYPRINTK config options added to config/armv7hl/default config, but found that there is no ttyS0 output, only earlycon here is paste: http://paste.opensuse.org/31390203 Recompiling same kernel with multi_v7_defconfig config and same debug/earlyprintk options have no panics and normal serial output: http://paste.opensuse.org/13080662 Maybe kernel-default config require some extra tricks now to have serial output? I want to catch that panic. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] Re: [opensuse-kernel] Re: armv7hl kernel-default config have tegra20 serial output broken
Hello, I have no experience with kgdb. As system restarts after panic timeout i wanted to catch oops message in kernel output via serial console. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Sat, Aug 1, 2015 at 1:46 PM, Matwey V. Kornilov matwey.korni...@gmail.com wrote: 01.08.2015 12:48, Misha Komarovskiy пишет: Hello, I found that latest images for my armv7 board (paz00/ac100) which use kernel-default have kernel panic on start without any output to serial console, but serial output was working last time i tested image back in may. I cloned kernel-source git repo made sequence-patched kernel and recompiled it with enabling DEBUG_LL,TEGRA UART_A and EARLYPRINTK config options added to config/armv7hl/default config, but found that there is no ttyS0 output, only earlycon here is paste: http://paste.opensuse.org/31390203 Have you tried to use kgdb? Does it not work too? Recompiling same kernel with multi_v7_defconfig config and same debug/earlyprintk options have no panics and normal serial output: http://paste.opensuse.org/13080662 Maybe kernel-default config require some extra tricks now to have serial output? I want to catch that panic. --- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-kernel+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-kernel+ow...@opensuse.org -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] armv7hl kernel-default config have tegra20 serial output broken
Hello Andreas, You are right, serial console output is back with CONFIG_SERIAL_OF_PLATFORM=y --- Best Regards, Misha Komarovskiy zombahatgmaildotcom On Sat, Aug 1, 2015 at 4:37 PM, Andreas Färber afaer...@suse.de wrote: Hi, Am 01.08.2015 um 11:48 schrieb Misha Komarovskiy: I found that latest images for my armv7 board (paz00/ac100) which use kernel-default have kernel panic on start without any output to serial [...] I cloned kernel-source git repo made sequence-patched kernel and recompiled it with enabling DEBUG_LL,TEGRA UART_A and EARLYPRINTK config options added to config/armv7hl/default config, but found that there is no ttyS0 Since you have a test setup, could you try changing CONFIG_SERIAL_OF_PLATFORM from =m to =y as previously suggested? Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Re: u-boot: bootmenu cmd
Hello Matwey, On Thu, Oct 29, 2015 at 11:28 PM, Matwey V. Kornilov <matwey.korni...@gmail.com> wrote: > 28.10.2015 19:11, Misha Komarovskiy пишет: >> Hello Matwey, >> >> On Wed, Oct 28, 2015 at 11:31 AM, Matwey V. Kornilov >> <matwey.korni...@gmail.com> wrote: >>> 27.10.2015 22:43, Misha Komarovskiy пишет: >>>> >>>> Hello Matwey, >>>> >>>> On Tue, Oct 27, 2015 at 9:52 PM, Matwey V. Kornilov >>>> <matwey.korni...@gmail.com> wrote: >>>>> >>>>> 27.10.2015 11:04, Guillaume Gardet пишет: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Le 26/10/2015 19:52, Matwey V. Kornilov a écrit : >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Why bootmenu command is not used atm? Are there any reasons? >>>>>>> >>>>>> >>>> >>>> You mean ansi bootmenu? If yes, ac100 community member tried to enable >>>> it for our board, >>>> but extlinux.conf was proposed as better solution, here is link >>>> http://patchwork.ozlabs.org/patch/450122/ >>>> >>>> I tried to use extlinux.conf with openSUSE on Chromebook Snow, >>>> because its support already enabled there, and it work flawlessly and >>>> very flexible, >>>> take a look at README.distro in u-boot repo, also as it is same as pxe >>>> config file kiwi probably already have >>>> support for it. >>>> >>>> Here is example of my test extlinux.conf: >>>> >>>> TIMEOUT 1000 >>>> ONTIMEOUT localboot >>>> DEFAULT default >>>> MENU TITLE Boot menu >>>> PROMPT 0 >>>> >>>> LABEL default >>>> MENU LABEL Default >>>> LINUX /boot/zImage >>>> FDT /boot/dtb/exynos5250-snow.dtb >>>> INITRD /boot/initrd >>>> APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 >>>> loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 >>>> resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 >>>> console=ttySAC3,115200n8 console=tty >>>> >>>> LABEL failsafe >>>> MENU LABEL Failsafe >>>> LINUX /boot/zImage-4.1.5-exynos_defconfig >>>> FDT /boot/dtb/exynos5250-snow.dtb >>>> INITRD /boot/initrd-4.1.5-exynos_defconfig >>>> APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 >>>> loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 >>>> resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 >>>> console=ttySAC3,115200n8 console=tty >>>> >>>> LABEL localboot >>>> MENU LABEL Local boot script (boot.scr) >>>> LOCALBOOT 1 >>>> >>> >>> Nice. I cannot understand is it uboot who runs extlinux or just support of >>> extlinux configuration file syntax inside uboot? >>> >>> >> >> It is pxe boot support inside u-boot, but this support can fallback to >> reading extlinux.conf from external media located in extlinux folder >> if no pxe network server was available on boot. >> And boards which have pxe/extlinux support available in their u-boot >> configs read extlinux.conf file prior to boot.scr file. >> > > In our am335x_evm config, bootloader selects dtb file name based on the > data read from EEPROM. How could this be implemented with extlinux? > Then you probably need to export this data from eeprom to $board_name and $cpu u-boot variables (CONFIG_ENV_VARS_UBOOT_CONFIG content if i remember right), which exlinux use to load dtb file if only FDTDIR supplied. Probably some extra setting to your defconfig also required, check README.distro for full list of requirements: http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.distro;h=9e4722a86ee562fdc80b675f5be9d30e30e61597;hb=refs/heads/master > > -- > To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Re: u-boot: bootmenu cmd
Hello Matwey, On Tue, Oct 27, 2015 at 9:52 PM, Matwey V. Kornilov <matwey.korni...@gmail.com> wrote: > 27.10.2015 11:04, Guillaume Gardet пишет: >> Hi, >> >> Le 26/10/2015 19:52, Matwey V. Kornilov a écrit : >>> Hello, >>> >>> Why bootmenu command is not used atm? Are there any reasons? >>> >> You mean ansi bootmenu? If yes, ac100 community member tried to enable it for our board, but extlinux.conf was proposed as better solution, here is link http://patchwork.ozlabs.org/patch/450122/ I tried to use extlinux.conf with openSUSE on Chromebook Snow, because its support already enabled there, and it work flawlessly and very flexible, take a look at README.distro in u-boot repo, also as it is same as pxe config file kiwi probably already have support for it. Here is example of my test extlinux.conf: TIMEOUT 1000 ONTIMEOUT localboot DEFAULT default MENU TITLE Boot menu PROMPT 0 LABEL default MENU LABEL Default LINUX /boot/zImage FDT /boot/dtb/exynos5250-snow.dtb INITRD /boot/initrd APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 console=ttySAC3,115200n8 console=tty LABEL failsafe MENU LABEL Failsafe LINUX /boot/zImage-4.1.5-exynos_defconfig FDT /boot/dtb/exynos5250-snow.dtb INITRD /boot/initrd-4.1.5-exynos_defconfig APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 console=ttySAC3,115200n8 console=tty LABEL localboot MENU LABEL Local boot script (boot.scr) LOCALBOOT 1 >> I think nobody worked on it until now. >> > > Oh, I see. > > But first I am going to introduce additional env variable to simplify > selection of the kernel version from u-boot command line. > > After then, I would highly want to have fallback possibility like the > following: > https://www.gnu.org/software/grub/manual/legacy/Booting-fallback-systems.html > which can be implemented using u-boot uEnv.txt file > > > -- > To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Re: u-boot: bootmenu cmd
Hello Andreas, On Wed, Oct 28, 2015 at 5:10 PM, Andreas Färber <afaer...@suse.de> wrote: > Am 28.10.2015 um 09:31 schrieb Matwey V. Kornilov: >> 27.10.2015 22:43, Misha Komarovskiy пишет: >>> On Tue, Oct 27, 2015 at 9:52 PM, Matwey V. Kornilov >>> <matwey.korni...@gmail.com> wrote: >>>> 27.10.2015 11:04, Guillaume Gardet пишет: >>>>> Le 26/10/2015 19:52, Matwey V. Kornilov a écrit : >>>>>> Why bootmenu command is not used atm? Are there any reasons? >>> >>> You mean ansi bootmenu? If yes, ac100 community member tried to enable >>> it for our board, >>> but extlinux.conf was proposed as better solution, here is link >>> http://patchwork.ozlabs.org/patch/450122/ >>> >>> I tried to use extlinux.conf with openSUSE on Chromebook Snow, >>> because its support already enabled there, and it work flawlessly and >>> very flexible, >>> take a look at README.distro in u-boot repo, also as it is same as pxe >>> config file kiwi probably already have >>> support for it. >>> >>> Here is example of my test extlinux.conf: > [...] >> Nice. I cannot understand is it uboot who runs extlinux or just support >> of extlinux configuration file syntax inside uboot? > > As far as I understand, someone would need to generate such config file > into the filesystem for U-Boot to read. That's the big problem I see > with it. If you want to dive into YaST, perl-bootloader or whatever is > involved there, feel free to give it a try! Yes we need to generate this file and put inside resulting JeOS image, same way we generate boot.scr but to /extlinux folder on boot partition and extlinux.conf is not compiled it is plain text file. Maybe it abilities not that flexible as boot.scr yet, i dont know for sure, need to make tests. > > Some solution for handling multiple kernels is bitterly needed. > > In YaST not even grub2 was supported on ARMv7 last time I tried - that's > the alternative to extlinux. It requires CONFIG_API to be enabled, for > which I have a u-boot branch. It also requires grub2 to be patched for > the RAM address of some boards. > > 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+unsubscr...@opensuse.org > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Re: u-boot: bootmenu cmd
Hello Matwey, On Wed, Oct 28, 2015 at 11:31 AM, Matwey V. Kornilov <matwey.korni...@gmail.com> wrote: > 27.10.2015 22:43, Misha Komarovskiy пишет: >> >> Hello Matwey, >> >> On Tue, Oct 27, 2015 at 9:52 PM, Matwey V. Kornilov >> <matwey.korni...@gmail.com> wrote: >>> >>> 27.10.2015 11:04, Guillaume Gardet пишет: >>>> >>>> Hi, >>>> >>>> Le 26/10/2015 19:52, Matwey V. Kornilov a écrit : >>>>> >>>>> Hello, >>>>> >>>>> Why bootmenu command is not used atm? Are there any reasons? >>>>> >>>> >> >> You mean ansi bootmenu? If yes, ac100 community member tried to enable >> it for our board, >> but extlinux.conf was proposed as better solution, here is link >> http://patchwork.ozlabs.org/patch/450122/ >> >> I tried to use extlinux.conf with openSUSE on Chromebook Snow, >> because its support already enabled there, and it work flawlessly and >> very flexible, >> take a look at README.distro in u-boot repo, also as it is same as pxe >> config file kiwi probably already have >> support for it. >> >> Here is example of my test extlinux.conf: >> >> TIMEOUT 1000 >> ONTIMEOUT localboot >> DEFAULT default >> MENU TITLE Boot menu >> PROMPT 0 >> >> LABEL default >> MENU LABEL Default >> LINUX /boot/zImage >> FDT /boot/dtb/exynos5250-snow.dtb >> INITRD /boot/initrd >> APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 >> loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 >> resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 >> console=ttySAC3,115200n8 console=tty >> >> LABEL failsafe >> MENU LABEL Failsafe >> LINUX /boot/zImage-4.1.5-exynos_defconfig >> FDT /boot/dtb/exynos5250-snow.dtb >> INITRD /boot/initrd-4.1.5-exynos_defconfig >> APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 >> loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 >> resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 >> console=ttySAC3,115200n8 console=tty >> >> LABEL localboot >> MENU LABEL Local boot script (boot.scr) >> LOCALBOOT 1 >> > > Nice. I cannot understand is it uboot who runs extlinux or just support of > extlinux configuration file syntax inside uboot? > > It is pxe boot support inside u-boot, but this support can fallback to reading extlinux.conf from external media located in extlinux folder if no pxe network server was available on boot. And boards which have pxe/extlinux support available in their u-boot configs read extlinux.conf file prior to boot.scr file. >> >>>> I think nobody worked on it until now. >>>> >>> >>> Oh, I see. >>> >>> But first I am going to introduce additional env variable to simplify >>> selection of the kernel version from u-boot command line. >>> >>> After then, I would highly want to have fallback possibility like the >>> following: >>> >>> https://www.gnu.org/software/grub/manual/legacy/Booting-fallback-systems.html >>> which can be implemented using u-boot uEnv.txt file >>> >>> >>> -- >>> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org >>> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org >>> >> >> >> > > > -- > To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Samsung Chromebook current tumbleweed images
Hello Guillaume, On Tue, Sep 1, 2015 at 11:17 AM, Guillaume Gardet <guillaume.gar...@free.fr> wrote: > > > Le 31/08/2015 16:39, Misha Komarovskiy a écrit : >> >> Hello Guillaume, >> >> On Mon, Aug 31, 2015 at 5:08 PM, Guillaume Gardet >> <guillaume.gar...@free.fr> wrote: >>> >>> Hi, >>> >>> Le 17/08/2015 17:41, Guillaume Gardet a écrit : >>>> >>>> Yes, this the way to do. >>>> >>>> Please patch lpae, default and vanilla to be consistent across configs. >>> >>> >>> >>> The patched kernel reached Factory/Tumbleweed but there is still a black >>> screen! :( >>> >> Are you sure it is included? I see 4.1.5 version in >> http://download.opensuse.org/ports/armv7hl/factory/repo/oss/suse/armv7hl/ >> And my patch was applied to Kernel:stable after 4.1.6 patch. > > > Yes, I can see: kernel-lpae-4.1.6-2.1.armv7hl.rpm in this repo and in the > build log of JeOS-chromebook image, it is the same version. > You are right. Kernel is fine now, but but required modules won't auto load even with force_drivers 8( If i run dracut -f manually output is: line 2: force_drivers: command not found but this fix worked for me before, maybe something changed in dracut itself? > > Guillaume > > > >> >>> The boot (and reboot) problem is fixed with latest image. >>> >>> >>> Guillaume >>> >>> >>>> >>>> Guillaume >>>> >>>> >>>> Le 17/08/2015 17:27, Misha Komarovskiy a écrit : >>>>> >>>>> I can send patch to opensuse-kernel ml if thats suitable, this way is >>>>> described on the wiki >>>>> >>>>> >>>>> https://en.opensuse.org/openSUSE:Kernel_git#Submitting_your_changes_to_the_kernel_team >>>>> What do you think is patch for lpae enough or better add default and >>>>> vanilla also? >>>>> --- >>>>> Best Regards, >>>>> Misha Komarovskiy >>>>> zombahatgmaildotcom >>>>> >>>>> >>>>> On Mon, Aug 17, 2015 at 5:59 PM, Guillaume Gardet >>>>> <guillaume.gar...@free.fr> wrote: >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Could you submit your patch to stable branch for default, lpae and >>>>>> vanilla >>>>>> flavours, please? >>>>>> >>>>>> Patches against master branch should follow once git repo fixed. >>>>>> >>>>>> >>>>>> Guillaume >>>>>> >>>>>> >>>>>> Le 17/08/2015 16:07, Misha Komarovskiy a écrit : >>>>>>> >>>>>>> My patch in attach >>>>>>> --- >>>>>>> Best Regards, >>>>>>> Misha Komarovskiy >>>>>>> zombahatgmaildotcom >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 17, 2015 at 4:13 PM, Guillaume Gardet >>>>>>> <guillaume.gar...@free.fr> wrote: >>>>>>>> >>>>>>>> Perfect! >>>>>>>> >>>>>>>> I submitted an update request to include it: >>>>>>>> https://build.opensuse.org/request/show/323645 >>>>>>>> >>>>>>>> We still need to update our kernel config to disable exynos IOMMU. >>>>>>>> But >>>>>>>> kernel repo is currently broken for master. >>>>>>>> Could send your config patch against stable kernel (4.1), please? >>>>>>>> >>>>>>>> >>>>>>>> Guillaume >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Le 17/08/2015 14:31, Misha Komarovskiy a écrit : >>>>>>>>> >>>>>>>>> Adding them with force_drivers do the trick. >>>>>>>>> --- >>>>>>>>> Best Regards, >>>>>>>>> Misha Komarovskiy >>>>>>>>> zombahatgmaildotcom >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Aug 17, 2015 at 3:09 PM, Guillaume Gardet >>>>>>>>> <guillaume.gar...@free.fr> wrote: >>>>>
Re: [opensuse-arm] Samsung Chromebook current tumbleweed images
On Tue, Sep 1, 2015 at 3:35 PM, Misha Komarovskiy <zom...@gmail.com> wrote: > Hello Guillaume, > > On Tue, Sep 1, 2015 at 11:17 AM, Guillaume Gardet > <guillaume.gar...@free.fr> wrote: >> >> >> Le 31/08/2015 16:39, Misha Komarovskiy a écrit : >>> >>> Hello Guillaume, >>> >>> On Mon, Aug 31, 2015 at 5:08 PM, Guillaume Gardet >>> <guillaume.gar...@free.fr> wrote: >>>> >>>> Hi, >>>> >>>> Le 17/08/2015 17:41, Guillaume Gardet a écrit : >>>>> >>>>> Yes, this the way to do. >>>>> >>>>> Please patch lpae, default and vanilla to be consistent across configs. >>>> >>>> >>>> >>>> The patched kernel reached Factory/Tumbleweed but there is still a black >>>> screen! :( >>>> >>> Are you sure it is included? I see 4.1.5 version in >>> http://download.opensuse.org/ports/armv7hl/factory/repo/oss/suse/armv7hl/ >>> And my patch was applied to Kernel:stable after 4.1.6 patch. >> >> >> Yes, I can see: kernel-lpae-4.1.6-2.1.armv7hl.rpm in this repo and in the >> build log of JeOS-chromebook image, it is the same version. >> > > You are right. Kernel is fine now, but but required modules won't auto > load even with force_drivers 8( > If i run dracut -f manually output is: line 2: force_drivers: command not > found > but this fix worked for me before, maybe something changed in dracut itself? It seems the problem that force_drivers line must not contain empty spaces, now it look like: force_drivers += "cros_ec_devs ptn3460 pwm-samsung" and correct one is force_drivers+="cros_ec_devs ptn3460 pwm-samsung" with such line, dracut parse force_drivers fine. > >> >> Guillaume >> >> >> >>> >>>> The boot (and reboot) problem is fixed with latest image. >>>> >>>> >>>> Guillaume >>>> >>>> >>>>> >>>>> Guillaume >>>>> >>>>> >>>>> Le 17/08/2015 17:27, Misha Komarovskiy a écrit : >>>>>> >>>>>> I can send patch to opensuse-kernel ml if thats suitable, this way is >>>>>> described on the wiki >>>>>> >>>>>> >>>>>> https://en.opensuse.org/openSUSE:Kernel_git#Submitting_your_changes_to_the_kernel_team >>>>>> What do you think is patch for lpae enough or better add default and >>>>>> vanilla also? >>>>>> --- >>>>>> Best Regards, >>>>>> Misha Komarovskiy >>>>>> zombahatgmaildotcom >>>>>> >>>>>> >>>>>> On Mon, Aug 17, 2015 at 5:59 PM, Guillaume Gardet >>>>>> <guillaume.gar...@free.fr> wrote: >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Could you submit your patch to stable branch for default, lpae and >>>>>>> vanilla >>>>>>> flavours, please? >>>>>>> >>>>>>> Patches against master branch should follow once git repo fixed. >>>>>>> >>>>>>> >>>>>>> Guillaume >>>>>>> >>>>>>> >>>>>>> Le 17/08/2015 16:07, Misha Komarovskiy a écrit : >>>>>>>> >>>>>>>> My patch in attach >>>>>>>> --- >>>>>>>> Best Regards, >>>>>>>> Misha Komarovskiy >>>>>>>> zombahatgmaildotcom >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 17, 2015 at 4:13 PM, Guillaume Gardet >>>>>>>> <guillaume.gar...@free.fr> wrote: >>>>>>>>> >>>>>>>>> Perfect! >>>>>>>>> >>>>>>>>> I submitted an update request to include it: >>>>>>>>> https://build.opensuse.org/request/show/323645 >>>>>>>>> >>>>>>>>> We still need to update our kernel config to disable exynos IOMMU. >>>>>>>>> But >>>>>>>>> kernel repo is currently broken for master. >>>>>>>>> Could send your config patch against stable kernel (4.1), please? >>>>>>>>> >>>>>>>
[opensuse-arm] Re: [opensuse-kernel] Re: armv7hl kernel-default config have tegra20 serial output broken
Hello, On Wed, Aug 5, 2015 at 5:12 PM, Misha Komarovskiy <zom...@gmail.com> wrote: > Hello Matwey, > I hope soon to be able to collect panic log, as tegra20 serial output > is fixed in kernel-source now. Panic happen before simple serial console started, but i made package of kernel-default with tegra DEBUG_LL enabled and now i have panic logs: http://paste.opensuse.org/15729922, log with initcall_debug http://paste.opensuse.org/76504505 I blame some kernel-default config option, because same kernel compiled with tegra_defconfig boots fine, but how to find which one? > --- > Best Regards, > Misha Komarovskiy > zombahatgmaildotcom > > > On Wed, Aug 5, 2015 at 3:27 PM, Matwey V. Kornilov > <matwey.korni...@gmail.com> wrote: >> That is strange, as far as I remember there is no panic timeout in JeOS >> >> 2015-08-03 14:17 GMT+03:00 Misha Komarovskiy <zom...@gmail.com>: >>> Hello, >>> I have no experience with kgdb. As system restarts after panic timeout >>> i wanted to catch oops message in kernel output via serial console. >>> --- >>> Best Regards, >>> Misha Komarovskiy >>> zombahatgmaildotcom >>> >>> >>> On Sat, Aug 1, 2015 at 1:46 PM, Matwey V. Kornilov >>> <matwey.korni...@gmail.com> wrote: >>>> 01.08.2015 12:48, Misha Komarovskiy пишет: >>>>> Hello, >>>>> I found that latest images for my armv7 board (paz00/ac100) which use >>>>> kernel-default have kernel panic on start without any output to serial >>>>> console, but serial output was working last time i tested image back >>>>> in may. >>>>> >>>>> I cloned kernel-source git repo made sequence-patched kernel and >>>>> recompiled it with >>>>> enabling DEBUG_LL,TEGRA UART_A and EARLYPRINTK config options added to >>>>> config/armv7hl/default config, but found that there is no ttyS0 >>>>> output, only earlycon here is paste: >>>>> http://paste.opensuse.org/31390203 >>>>> >>>> >>>> Have you tried to use kgdb? Does it not work too? >>>> >>>>> Recompiling same kernel with multi_v7_defconfig config and same >>>>> debug/earlyprintk options have no panics and normal serial output: >>>>> http://paste.opensuse.org/13080662 >>>>> >>>>> Maybe kernel-default config require some extra tricks now to have serial >>>>> output? >>>>> I want to catch that panic. >>>>> --- >>>>> Best Regards, >>>>> Misha Komarovskiy >>>>> zombahatgmaildotcom >>>>> >>>> >>>> >>>> -- >>>> To unsubscribe, e-mail: opensuse-kernel+unsubscr...@opensuse.org >>>> To contact the owner, e-mail: opensuse-kernel+ow...@opensuse.org >>>> >> >> >> >> -- >> With best regards, >> Matwey V. Kornilov >> http://blog.matwey.name >> xmpp://0x2...@jabber.ru -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] Re: [opensuse-kernel] Re: armv7hl kernel-default config have tegra20 serial output broken
Hello Matwey, On Thu, Sep 3, 2015 at 10:35 PM, Matwey V. Kornilov <matwey.korni...@gmail.com> wrote: > 2015-09-03 19:23 GMT+03:00 Misha Komarovskiy <zom...@gmail.com>: >> Hello, >> >> On Wed, Aug 5, 2015 at 5:12 PM, Misha Komarovskiy <zom...@gmail.com> wrote: >>> Hello Matwey, >>> I hope soon to be able to collect panic log, as tegra20 serial output >>> is fixed in kernel-source now. >> >> Panic happen before simple serial console started, but i made package >> of kernel-default with tegra DEBUG_LL enabled >> and now i have panic logs: http://paste.opensuse.org/15729922, log >> with initcall_debug http://paste.opensuse.org/76504505 > > I would suggest using gdb to understand where the issue appears, it is > probably the fastest way. > I wrote an instruction for myself how to do that, but unfortunately it > is written in Russian and Google Translate doesn't help much: > https://goo.gl/7LlcEz > I'll try to find more details with kgdb, it seems problems on my tegra20 family board starts after 3.19 kernel. Russian is my native language, i will follow your guide, thanks. >> >> I blame some kernel-default config option, because same kernel >> compiled with tegra_defconfig boots fine, >> but how to find which one? >> >> >>> --- >>> Best Regards, >>> Misha Komarovskiy >>> zombahatgmaildotcom >>> >>> >>> On Wed, Aug 5, 2015 at 3:27 PM, Matwey V. Kornilov >>> <matwey.korni...@gmail.com> wrote: >>>> That is strange, as far as I remember there is no panic timeout in JeOS >>>> >>>> 2015-08-03 14:17 GMT+03:00 Misha Komarovskiy <zom...@gmail.com>: >>>>> Hello, >>>>> I have no experience with kgdb. As system restarts after panic timeout >>>>> i wanted to catch oops message in kernel output via serial console. >>>>> --- >>>>> Best Regards, >>>>> Misha Komarovskiy >>>>> zombahatgmaildotcom >>>>> >>>>> >>>>> On Sat, Aug 1, 2015 at 1:46 PM, Matwey V. Kornilov >>>>> <matwey.korni...@gmail.com> wrote: >>>>>> 01.08.2015 12:48, Misha Komarovskiy пишет: >>>>>>> Hello, >>>>>>> I found that latest images for my armv7 board (paz00/ac100) which use >>>>>>> kernel-default have kernel panic on start without any output to serial >>>>>>> console, but serial output was working last time i tested image back >>>>>>> in may. >>>>>>> >>>>>>> I cloned kernel-source git repo made sequence-patched kernel and >>>>>>> recompiled it with >>>>>>> enabling DEBUG_LL,TEGRA UART_A and EARLYPRINTK config options added to >>>>>>> config/armv7hl/default config, but found that there is no ttyS0 >>>>>>> output, only earlycon here is paste: >>>>>>> http://paste.opensuse.org/31390203 >>>>>>> >>>>>> >>>>>> Have you tried to use kgdb? Does it not work too? >>>>>> >>>>>>> Recompiling same kernel with multi_v7_defconfig config and same >>>>>>> debug/earlyprintk options have no panics and normal serial output: >>>>>>> http://paste.opensuse.org/13080662 >>>>>>> >>>>>>> Maybe kernel-default config require some extra tricks now to have >>>>>>> serial output? >>>>>>> I want to catch that panic. >>>>>>> --- >>>>>>> Best Regards, >>>>>>> Misha Komarovskiy >>>>>>> zombahatgmaildotcom >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> To unsubscribe, e-mail: opensuse-kernel+unsubscr...@opensuse.org >>>>>> To contact the owner, e-mail: opensuse-kernel+ow...@opensuse.org >>>>>> >>>> >>>> >>>> >>>> -- >>>> With best regards, >>>> Matwey V. Kornilov >>>> http://blog.matwey.name >>>> xmpp://0x2...@jabber.ru >> >> >> >> -- >> Best Regards, >> Misha Komarovskiy >> zombahatgmaildotcom > > > > -- > With best regards, > Matwey V. Kornilov > http://blog.matwey.name > xmpp://0x2...@jabber.ru -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Re: [opensuse-kernel] Re: armv7hl kernel-default config have tegra20 serial output broken
Hello Andreas, On Mon, Sep 7, 2015 at 4:35 PM, Andreas Färber <afaer...@suse.de> wrote: > Hi, > > Am 03.09.2015 um 18:23 schrieb Misha Komarovskiy: >> On Wed, Aug 5, 2015 at 5:12 PM, Misha Komarovskiy <zom...@gmail.com> wrote: >>> Hello Matwey, >>> I hope soon to be able to collect panic log, as tegra20 serial output >>> is fixed in kernel-source now. >> >> Panic happen before simple serial console started, but i made package >> of kernel-default with tegra DEBUG_LL enabled >> and now i have panic logs: http://paste.opensuse.org/15729922, log >> with initcall_debug http://paste.opensuse.org/76504505 >> >> I blame some kernel-default config option, because same kernel >> compiled with tegra_defconfig boots fine, >> but how to find which one? > > Please take a look at function tegra_pmc_probe() (`git grep > tegra_pmc_probe -- drivers/` to find the corresponding file). > I'm guessing it tries to of_node_put() a NULL pointer or something else > it shouldn't touch. Thierry Reding pointed me to patch that fixes this oops in tegra pmc, it is already accepted for linux-next, http://patchwork.ozlabs.org/patch/493307/ and it should go to 4.1.7 or next stable release I just tested this patch with kernel-source stable branch and it fix boot for paz00 board, no panic anymore. > > Regards, > Andreas > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Samsung Chromebook current tumbleweed images
Hello, I just tested openSUSE-Tumbleweed-ARM-JeOS-chromebook.armv7l-1.12.1-Build326.1.raw.xz: 1. On first boot screen still stays black, starts to work only after first reboot. Maybe we need to force_drivers for initial initrd also? 2. rtc_max77686 spam log and tty output with messages: rtc_max77686: RTC cannot handle the year 1970. Assume it's 2000. As i understand rtc drivers built-in inside kernel, but i2c driver which it use built as module and i2c driver init call happen too late for rtc on system power on? This is probably not chromebook specific issue but for all boards with i2c rtc drivers. On Wed, Sep 2, 2015 at 10:21 AM, Guillaume Gardet <guillaume.gar...@free.fr> wrote: > > > Le 01/09/2015 15:42, Andreas Färber a écrit : >> >> Am 01.09.2015 um 15:37 schrieb Guillaume Gardet: >>> >>> Le 01/09/2015 14:49, Misha Komarovskiy a écrit : >>>> >>>> On Tue, Sep 1, 2015 at 3:35 PM, Misha Komarovskiy <zom...@gmail.com> >>>> wrote: >>>>> >>>>> Kernel is fine now, but but required modules won't auto >>>>> load even with force_drivers 8( >>>>> If i run dracut -f manually output is: line 2: force_drivers: command >>>>> not found >>>>> but this fix worked for me before, maybe something changed in dracut >>>>> itself? >>>> >>>> It seems the problem that force_drivers line must not contain empty >>>> spaces, now it look like: >>>> force_drivers += "cros_ec_devs ptn3460 pwm-samsung" >>>> and correct one is >>>> force_drivers+="cros_ec_devs ptn3460 pwm-samsung" >>>> >>>> with such line, dracut parse force_drivers fine. >>> >>> Indded. Just tried it and I get the display! :D >>> Thanks a lot! >>> >>> SR #328325 is pending: https://build.opensuse.org/request/show/328325 >> >> Guillaume, I'm pretty sure I saw a comment in the JeOS script that says >> that add_drivers (or so) needs the string to start with a space, to >> avoid that being concatenated to a previously added driver. I imagine >> the same applies to force_drivers as well then. > > > Fixed in SR #328558. > > > Guillaume > >> >> Regards, >> Andreas >> > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Re: [opensuse-kernel] Re: armv7hl kernel-default config have tegra20 serial output broken
Hello, On Mon, Sep 7, 2015 at 7:37 PM, Misha Komarovskiy <zom...@gmail.com> wrote: > Hello Andreas, > > On Mon, Sep 7, 2015 at 4:35 PM, Andreas Färber <afaer...@suse.de> wrote: >> Hi, >> >> Am 03.09.2015 um 18:23 schrieb Misha Komarovskiy: >>> On Wed, Aug 5, 2015 at 5:12 PM, Misha Komarovskiy <zom...@gmail.com> wrote: >>>> Hello Matwey, >>>> I hope soon to be able to collect panic log, as tegra20 serial output >>>> is fixed in kernel-source now. >>> >>> Panic happen before simple serial console started, but i made package >>> of kernel-default with tegra DEBUG_LL enabled >>> and now i have panic logs: http://paste.opensuse.org/15729922, log >>> with initcall_debug http://paste.opensuse.org/76504505 >>> >>> I blame some kernel-default config option, because same kernel >>> compiled with tegra_defconfig boots fine, >>> but how to find which one? >> >> Please take a look at function tegra_pmc_probe() (`git grep >> tegra_pmc_probe -- drivers/` to find the corresponding file). >> I'm guessing it tries to of_node_put() a NULL pointer or something else >> it shouldn't touch. > > Thierry Reding pointed me to patch that fixes this oops in tegra pmc, > it is already accepted > for linux-next, http://patchwork.ozlabs.org/patch/493307/ > and it should go to 4.1.7 or next stable release > I just tested this patch with kernel-source stable branch and it fix > boot for paz00 board, > no panic anymore. Current image openSUSE-Tumbleweed-ARM-JeOS-paz00.armv7l-1.12.1-Build331.3.raw.xz now include kernel 4.2.1 which have tegra pmc fix included, kernel start to load now but i have new different oops, here is log http://paste.opensuse.org/3794617 > >> >> Regards, >> Andreas >> >> -- >> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany >> GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) > > > > -- > Best Regards, > Misha Komarovskiy > zombahatgmaildotcom -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Request for testing help: openSUSE Leap 42.2 for ARMv7 images
Hello Dirk, On Wed, Nov 23, 2016 at 4:00 PM, Dirk Müller <d...@dmllr.de> wrote: > Hi All, > > over the last few days I've been pretty busy with enabling > pre-configured appliances for ARMv7 and AArch64 on openSUSE Leap 42.2, > and I'm happy to report that we now have some images available: > > http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/appliances/ > http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/appliances/ > > As you can see its a pretty elaborative list of images, and I don't > have time to test all of them myself. so whoever is interested in > having some of those variants working for him, please try them out and > report both successes and failures. The overall goal is to announce > the ARM port end of next week (Dec 1st) so it would be great to have > some testing feedback before that (and << before that so that we can > maybe even fix it before announcement). > I just tested openSUSE-Leap42.2-ARM-XFCE-paz00.armv7l-2016.11.21-Build3.1.raw.xz with paz00 (Toshiba AC100 smartbook), but with old non EFI U-Boot preloaded on device: 1. First boot: boot to login - fine, xdm start - fine, reboot - fine. 2. Second boot: boot to login - fine, xdm start - fine, start xfce - very long start (starting gnome keyring daemon), but fine in the end. Wifi - working fine. I will test mainline and Tumbleweed U-Boot versions later, but overall everything working as expected for kernel version bundled with Leap 42.2 and ready for Toshiba AC100 users. Thank you very much. > > Thanks a lot in advance, > Dirk > -- > To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Samsung Chromebook (Snow) status?
Hello Daniel, On Sat, Aug 12, 2017 at 3:16 PM, Daniel Bischof <suse-b...@bischof.org> wrote: > Hi, > > I tried openSUSE-Tumbleweed-ARM-XFCE-chromebook.armv7l-2017.07.22-Build1.1 > recently, but it just beeps and kicks me back to the boot screen > immediately. No messages on screen, partition resizing, etc. > Last version i tested was openSUSE-Tumbleweed-ARM-JeOS-chromebook.armv7l-2017.06.10-Build2.10.raw.xz, it worked fine except outdated armsoc driver. But after that i updated vboot package to newer version to play with newer chromebooks, maybe it is broken with snow, i will try newer builds to find out. > Any hints? Some cgpt magic I could try from ChromeOS perhaps? > You can try to boot old openSUSE 13.1 version to find out that your sdcard or usb flash is ok first, if yes try to rebuild chaniloading partition. > > Best regards, --D. > -- > To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Samsung Chromebook (Snow) status?
Hello Daniel, On Sun, Aug 20, 2017 at 3:09 PM, Daniel Bischof <suse-b...@bischof.org> wrote: > Hi, > > On Mon, 14 Aug 2017, msuchanek wrote: > >> On Sat, 12 Aug 2017 14:16:51 +0200 (CEST) Daniel Bischof >> <suse-b...@bischof.org> wrote: >> >>> I tried >>> openSUSE-Tumbleweed-ARM-XFCE-chromebook.armv7l-2017.07.22-Build1.1 recently, >>> but it just beeps and kicks me back to the boot screen immediately. No >>> messages on screen, partition resizing, etc. >>> >>> Any hints? Some cgpt magic I could try from ChromeOS perhaps? >> >> >> You can try installing upstream u-boot following the chainload steps >> deteailed in several places on the interwebs - eg here >> http://chrodyssey.blogspot.cz/2015/04/the-bootloader-chained.html >> >> The current u-boot supports display on Snow but the EFI GOP emulation >> (which the Tumbleweed image would use if it booted) is broken. >> >> It probably does not boot because the loader is missing or not marked as >> bootable or you did not enable USB boot on the chromebook. >> >> The developer mode on current versions of ChromeOS has more features than >> it used to but is also more flaky - it seems services tend to stop working >> randomly and currently I Cannot boot at all after the devmode installation >> fell apart. > > > thanks to both of you (Michal and Misha) for your answers, nice to hear that > you didn't give up on Snow, even since it is no longer available for > purchase. > I partly revived my chromebook snow and i was able to test current Tumbleweed image openSUSE-Tumbleweed-ARM-JeOS-chromebook.armv7l-2017.08.13-Build1.6.raw.xz I found that factory U-Boot for some reason don't like our chainloading U-BOOT partition with message: GptNextKernelEntry looking at new prio partition 1 GptNextKernelEntry s1 t5 p10 GptNextKernelEntry likes partition 1 Found kernel entry at 2048 size 409604 Not a valid verified boot key block. Verifying key block signature failed. Not a valid verified boot key block. Verifying key block hash failed. Marking kernel as invalid. GptNextKernelEntry looking at new prio partition 1 GptNextKernelEntry s1 t5 p10 GptNextKernelEntry no more kernels i will try to investigate further why this happen. > I played around a little with the broken image, but failed to recompile > u-boot as described in the above link - need to dig into this. > > I switched (temporarily, i hope) to archlinuxARM [1], which works fine (all > HW incl. 2d acceleration), but it is uncomfortable for me, since i've never > used archlinux before. Kali (Debian-based) works, too, but has no 2d > acceleration. Both appear to use the ChromeOS-kernel. > > I don't use ChromeOS, but keep it up-to-date via guest mode - maybe a > not-so-good idea afterwards... > > [1] https://archlinuxarm.org/platforms/armv7/samsung/samsung-chromebook > > > Best regards, > > --D. > --- > Daniel Bischof <suse-b...@bischof.org> > -- > To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] xf86-video-armsoc crashes X server
Hello Guillaume,
On Sat, Nov 18, 2017 at 12:41 PM, Guillaume Gardet
<guillaume.gar...@free.fr> wrote:
>
>
> Le 17/11/2017 à 20:55, Misha Komarovskiy a écrit :
>>
>> Hello Guillaume,
>>
>> On Fri, Nov 17, 2017 at 4:32 PM, Guillaume Gardet
>> <guillaume.gar...@free.fr> wrote:
>>>
>>> Hi,
>>>
>>> I did not tested Chromebook for a while... and it was quite broken.
>>>
>>> I fixed our JeOS image boot, and now, I am working on graphic images.
>>>
>> Cool, what was the problem? I tried to find but was stuck at u-boot not
>> loading
>> for some reason.
>
>
> vboot package was updated but the new version required a new argument to
> work and failed more or less silently in image creation. So, u-boot could
> not be loaded since no signed version was copied.
I see, it is my fault, i updated vboot because i plan to add
chromebook nyan-big and veyron support which
require newer vboot.
>
>>
>>> The problem is if we use xf86-video-armsoc, it crashes X server. A
>>> workaround is to use FBDEV driver, but it would be nice to fix ARMSOC
>>> driver!
>>>
>>> If you have any idea or want to join to help to fix it, please do it. :)
>>>
>> Also noticed that armsoc not working. But there is no reason to keep it,
>> it is only viable for opengl blobs from Chrome OS and they work only with
>> downstream kernel. Without them it is useless and buggy with no upstream
>> support and no speed benefits vs fbdev/modesetting drivers.
>
>
> I think armsoc driver uses DRM interface and can work without openGL. No ?
>
Yes it can work without blobs, but last time i tried it this way with
mainlike kernel
it has no speed benefits vs fbdev and crashed from time to time.
>> Fbturbo driver probably will give some 2d boots to snow mali gpu
>> but thats optional.
>
>
> I do not know this driver. I will google it.
>
>>
>> I made SR of vboot to hardware repo if/once it is accepted we can get
>> rid of devel:chromebook at all with its legacy stuff.
>
>
> Before, you should rework the version scheme using something like
> 0.0~git2017XXYY
Thanks, fixed.
>
>
> Guillaume
>
>
>>
>>> GDB output:
>>>
>>>
>>> Program terminated with signal SIGABRT, Aborted.
>>> #0 0xb6967e5c in raise () from /lib/libc.so.6
>>>
>>> Thread 1 (Thread 0xb6fc3010 (LWP 1967)):
>>> #0 0xb6967e5c in raise () from /lib/libc.so.6
>>> No symbol table info available.
>>> #1 0xb69695e0 in abort () from /lib/libc.so.6
>>> No symbol table info available.
>>> #2 0x005cf7b8 in OsAbort () at utils.c:1361
>>> No locals.
>>> #3 0x00497f20 in ddxGiveUp (error=EXIT_ERR_ABORT, error@entry=6184816)
>>> at
>>> xf86Init.c:1011
>>> i =
>>> #4 0x0049800c in AbortDDX (error=6184816, error@entry=EXIT_ERR_ABORT) at
>>> xf86Init.c:1055
>>> i =
>>> #5 0x005d590c in AbortServer () at log.c:874
>>> No locals.
>>> #6 0x005d6490 in FatalError (f=0x60142c "Caught signal %d (%s). Server
>>> aborting\n") at log.c:1015
>>> args = {__ap = 0xbef1e024}
>>> args2 = {__ap = 0xbef1e024}
>>> beenhere = 1
>>> #7 0x005cc49c in OsSigHandler (signo=11, sip=0xbef1e040,
>>> unused=>> out>) at osinit.c:154
>>> unused =
>>> sip = 0xbef1e040
>>> signo = 11
>>> #8
>>> No symbol table info available.
>>> #9 xf86InitViewport (pScr=0x835398) at xf86Cursor.c:104
>>> No locals.
>>> #10 0x0049a1cc in InitOutput (pScreenInfo=0xbef1e604,
>>> pScreenInfo@entry=0x639464 , argc=6440076,
>>> argc@entry=4534188,
>>> argv=0x833c88, argv@entry=0x0) at xf86Init.c:634
>>> i = 0
>>> j =
>>> k =
>>> scr_index =
>>> modulelist =
>>> optionlist = 0x859008
>>> screenpix24 =
>>> pix24 =
>>> pix24From = X_DEFAULT
>>> pix24Fail = 0
>>> autoconfig =
>>> sigio_blocked = 0
>>> want_hw_access =
>>> configured_device =
>>> #11 0x00452fac in dix_main (argc=4534188, argv=0x0, envp=)
>>> at
>>> main.c:197
>>> i =
>>> alwaysCheckForInput = {0, 1}
>>> #12 0xb6950b68 in __libc_start
Re: [opensuse-arm] Samsung Chromebook (Snow) status?
Hello Daniel, On Sat, Oct 7, 2017 at 3:06 PM, Daniel Bischof <suse-b...@bischof.org> wrote: > Hi, > > On Mon, 21 Aug 2017, Misha Komarovskiy wrote: > >> On Sun, Aug 20, 2017 at 3:09 PM, Daniel Bischof <suse-b...@bischof.org> >> wrote: >>> >>> On Mon, 14 Aug 2017, msuchanek wrote: >>> >>>> On Sat, 12 Aug 2017 14:16:51 +0200 (CEST) Daniel Bischof >>>> <suse-b...@bischof.org> wrote: >>>> >>>>> I tried >>>>> openSUSE-Tumbleweed-ARM-XFCE-chromebook.armv7l-2017.07.22-Build1.1 >>>>> recently, >>>>> but it just beeps and kicks me back to the boot screen immediately. No >>>>> messages on screen, partition resizing, etc. >>>>> >>>>> Any hints? Some cgpt magic I could try from ChromeOS perhaps? >>>> >>>> >>>> You can try installing upstream u-boot following the chainload steps >>>> deteailed in several places on the interwebs - eg here >>>> http://chrodyssey.blogspot.cz/2015/04/the-bootloader-chained.html >>>> >>>> The current u-boot supports display on Snow but the EFI GOP emulation >>>> (which the Tumbleweed image would use if it booted) is broken. >>>> >>>> It probably does not boot because the loader is missing or not marked as >>>> bootable or you did not enable USB boot on the chromebook. >>>> >>>> The developer mode on current versions of ChromeOS has more features >>>> than it used to but is also more flaky - it seems services tend to stop >>>> working randomly and currently I Cannot boot at all after the devmode >>>> installation fell apart. >>> >>> >>> thanks to both of you (Michal and Misha) for your answers, nice to hear >>> that you didn't give up on Snow, even since it is no longer available for >>> purchase. >> >> >> I partly revived my chromebook snow and i was able to test current >> Tumbleweed image >> openSUSE-Tumbleweed-ARM-JeOS-chromebook.armv7l-2017.08.13-Build1.6.raw.xz I >> found that factory U-Boot for some reason don't like our chainloading U-BOOT >> partition with message: >> >> GptNextKernelEntry looking at new prio partition 1 >> GptNextKernelEntry s1 t5 p10 >> GptNextKernelEntry likes partition 1 >> Found kernel entry at 2048 size 409604 >> Not a valid verified boot key block. >> Verifying key block signature failed. >> Not a valid verified boot key block. >> Verifying key block hash failed. >> Marking kernel as invalid. >> GptNextKernelEntry looking at new prio partition 1 >> GptNextKernelEntry s1 t5 p10 >> GptNextKernelEntry no more kernels >> >> i will try to investigate further why this happen. [...] > > > i tried openSUSE-Tumbleweed-ARM-JeOS-chromebook.armv7l-2017.10.02-Build1.1 > today and still no luck. Did you dig into this already? I'm not skilled > enough to be helpful in this stage, i'm afraid... > Guillaume fixed chromebook snow images you can try current TW build http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Chromebook/images/openSUSE-Tumbleweed-ARM-JeOS-chromebook.armv7l-2017.11.17-Build2.2.raw.xz It boots fine here, i only expirienced hard freeze on first boot which chanhes partition setup, here is fault output to serial uart http://paste.opensuse.org/98361543 If it wont reboot for too long on first boot you probably also caught this fault just reboot by power key, second boot is fine. > > Best regards, > > --D. > --- > Daniel Bischof <suse-b...@bischof.org> > -- > To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Samsung Chromebook (Snow) status?
Hello Guillaume, On Mon, Nov 20, 2017 at 4:51 PM, Guillaume Gardet <guillaume.gar...@free.fr> wrote: > > > Le 18/11/2017 à 21:12, Misha Komarovskiy a écrit : >> >> Hello Daniel, >> >> On Sat, Oct 7, 2017 at 3:06 PM, Daniel Bischof <suse-b...@bischof.org> >> wrote: >>> >>> Hi, >>> >>> On Mon, 21 Aug 2017, Misha Komarovskiy wrote: >>> >>>> On Sun, Aug 20, 2017 at 3:09 PM, Daniel Bischof <suse-b...@bischof.org> >>>> wrote: >>>>> >>>>> On Mon, 14 Aug 2017, msuchanek wrote: >>>>> >>>>>> On Sat, 12 Aug 2017 14:16:51 +0200 (CEST) Daniel Bischof >>>>>> <suse-b...@bischof.org> wrote: >>>>>> >>>>>>> I tried >>>>>>> openSUSE-Tumbleweed-ARM-XFCE-chromebook.armv7l-2017.07.22-Build1.1 >>>>>>> recently, >>>>>>> but it just beeps and kicks me back to the boot screen immediately. >>>>>>> No >>>>>>> messages on screen, partition resizing, etc. >>>>>>> >>>>>>> Any hints? Some cgpt magic I could try from ChromeOS perhaps? >>>>>> >>>>>> >>>>>> You can try installing upstream u-boot following the chainload steps >>>>>> deteailed in several places on the interwebs - eg here >>>>>> http://chrodyssey.blogspot.cz/2015/04/the-bootloader-chained.html >>>>>> >>>>>> The current u-boot supports display on Snow but the EFI GOP emulation >>>>>> (which the Tumbleweed image would use if it booted) is broken. >>>>>> >>>>>> It probably does not boot because the loader is missing or not marked >>>>>> as >>>>>> bootable or you did not enable USB boot on the chromebook. >>>>>> >>>>>> The developer mode on current versions of ChromeOS has more features >>>>>> than it used to but is also more flaky - it seems services tend to >>>>>> stop >>>>>> working randomly and currently I Cannot boot at all after the devmode >>>>>> installation fell apart. >>>>> >>>>> >>>>> thanks to both of you (Michal and Misha) for your answers, nice to hear >>>>> that you didn't give up on Snow, even since it is no longer available >>>>> for >>>>> purchase. >>>> >>>> >>>> I partly revived my chromebook snow and i was able to test current >>>> Tumbleweed image >>>> >>>> openSUSE-Tumbleweed-ARM-JeOS-chromebook.armv7l-2017.08.13-Build1.6.raw.xz I >>>> found that factory U-Boot for some reason don't like our chainloading >>>> U-BOOT >>>> partition with message: >>>> >>>> GptNextKernelEntry looking at new prio partition 1 >>>> GptNextKernelEntry s1 t5 p10 >>>> GptNextKernelEntry likes partition 1 >>>> Found kernel entry at 2048 size 409604 >>>> Not a valid verified boot key block. >>>> Verifying key block signature failed. >>>> Not a valid verified boot key block. >>>> Verifying key block hash failed. >>>> Marking kernel as invalid. >>>> GptNextKernelEntry looking at new prio partition 1 >>>> GptNextKernelEntry s1 t5 p10 >>>> GptNextKernelEntry no more kernels >>>> >>>> i will try to investigate further why this happen. [...] >>> >>> >>> i tried >>> openSUSE-Tumbleweed-ARM-JeOS-chromebook.armv7l-2017.10.02-Build1.1 >>> today and still no luck. Did you dig into this already? I'm not skilled >>> enough to be helpful in this stage, i'm afraid... >>> >> Guillaume fixed chromebook snow images you can try current TW build >> >> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Chromebook/images/openSUSE-Tumbleweed-ARM-JeOS-chromebook.armv7l-2017.11.17-Build2.2.raw.xz >> It boots fine here, i only expirienced hard freeze on first boot which >> chanhes partition setup, here is fault output to serial >> uart http://paste.opensuse.org/98361543 >> If it wont reboot for too long on first boot you probably also caught >> this fault just reboot by power key, second boot is fine. > > > It seems that Build2.4 has video output broken. I guess this is due to new > 4.14.0 kernel? > Unfortunately, I do not have any serial access on my chromebook. Could you > have a look, since it seems you have serial on your chromebook. > Or anyone else? There is hard freeze near 4 of 5 times, here is output from serial http://paste.opensuse.org/96574215 Maybe misconfig in our kernel config or regression in 4.14 need to investigate. > > > Guillaume > > > >>> Best regards, >>> >>> --D. >>> --- >>> Daniel Bischof <suse-b...@bischof.org> >>> -- >>> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org >>> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org >>> >> >> > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Tests of ARM Leap 15.0
Hello, On Tue, Jun 5, 2018 at 1:37 PM Guillaume Gardet wrote: > > Hi, > > here are some results of my tests of Leap 15.0 images. > * JeOS-beagle : OK. (DVI output not working on BBxM, as on Tumbleweed) > * JeOS-beaglebone: OK on BB Black. HDMI not tested. > * XFCE-raspberrypi2: OK > * XFCE-sabrelite : USB not working (fine in TW), only 1/4 of the screen is > used for display (same in TW), otherwise ok. => not blocking since Ethernet > is working and will allow updates. > * KDE-chromebook: (not built, JeOS needs to be updated) u-boot ok, but get a > black screen then, no repartition happened (same in latest TW). > > openQA looks fine: > https://openqa.opensuse.org/tests/overview?distri=opensuse=15.0=124.1=52 > * Firefox problem is fixed in devel and Factory. Should be released to > Leap:15.0 through updates. > * Gnome terminal problem is an openQA problem (color font mismatch) > > If people could also share there tests, it would help to decide when we could > release Leap 15.0 for ARM. :) > Just found time to test Toshiba AC100 with Leap 15.0, tested this build: openSUSE-Leap15.0-ARM-XFCE-paz00.armv7l-2018.05.20-Buildlp150.6.1.raw.xz it is fully functional and everything working as expected. > > Guillaume > > > -- > To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
