Re: [opensuse-arm] JeOS-beaglebone doesn't boot (uboot 2016.01-rc1)

[Matwey V. Kornilov]

2015-12-11 12:42 GMT+03:00 Guillaume Gardet :
>
>
> Le 11/12/2015 10:10, Matwey V. Kornilov a écrit :
>>
>> 2015-12-11 12:04 GMT+03:00 Guillaume Gardet :
>>>
>>> Hi,
>>>
>>> Le 11/12/2015 09:55, Matwey V. Kornilov a écrit :

 Hello,

 I am using
 openSUSE-Tumbleweed-ARM-JeOS-beaglebone.armv7l-1.12.1-Build350.1.raw
 from openSUSE:Factory:ARM and see the following:

 U-Boot SPL 2016.01-rc1 (Dec 01 2015 - 16:30:32)
 bad magic
 bad magic
 spl_register_fat_device: fat register err - -1
 spl_register_fat_device: fat register err - -1
 spl_load_image_fat: error reading image u-boot.img, err - -1
 spl: ext4fs_open failed
 spl: ext4fs_open failed
 spl_load_image_ext: error reading image uImage, err - -1


 U-Boot 2016.01-rc1 (Dec 01 2015 - 16:30:32 +)

  Watchdog enabled
 I2C:   ready
 DRAM:  512 MiB
 NAND:  0 MiB
 MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
 *** Error - No Valid Environment Area found
 *** Warning - bad CRC, using default environment

 Net:not set. Validating first E-fuse MAC
 cpsw, usb_ether
 =>

 Something is probably wrong.
>>>
>>>
>>> What happen if you type 'boot' command?
>>
>> It boots! Magic!
>> Thank  you, but why it doesn't happen automatically?
>
>
> Maybe you hit a key on your keyboard stopping autoboot?
>
> Is the autoboot count down shown?

No, I've tried several times. It is just waiting for a command in prompt.

>
>>
 p.s. I am not sure that it is related to u-boot, but is there any reason
 why rc-s of u-boot appear in Factory? Would it be better to test them on
 kittens instead of users?

>>> Most of the time, I test u-boot on boards available to me when I update
>>> it.
>>> But, I do not have all boards supported by openSUSE, so it may break some
>>> boards, but the sooner it is detected, the better it is! ;)
>>>
>>>
>> It makes sense.
>> Still would be great to have another JeOS which is guaranteed working
>> out of the box.
>
>
> Standard release (13.2 or 13.1). ;)
>

Which is not there anymore, leap doesn't support armv7 and tumbleweed
is supplied with rc of u-boot :)

>
> Guillaume
>



-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] JeOS-beaglebone doesn't boot (uboot 2016.01-rc1)

[Guillaume Gardet]

Le 11/12/2015 10:46, Matwey V. Kornilov a écrit :

2015-12-11 12:42 GMT+03:00 Guillaume Gardet :


Le 11/12/2015 10:10, Matwey V. Kornilov a écrit :

2015-12-11 12:04 GMT+03:00 Guillaume Gardet :

Hi,

Le 11/12/2015 09:55, Matwey V. Kornilov a écrit :

Hello,

I am using
openSUSE-Tumbleweed-ARM-JeOS-beaglebone.armv7l-1.12.1-Build350.1.raw
from openSUSE:Factory:ARM and see the following:

U-Boot SPL 2016.01-rc1 (Dec 01 2015 - 16:30:32)
bad magic
bad magic
spl_register_fat_device: fat register err - -1
spl_register_fat_device: fat register err - -1
spl_load_image_fat: error reading image u-boot.img, err - -1
spl: ext4fs_open failed
spl: ext4fs_open failed
spl_load_image_ext: error reading image uImage, err - -1


U-Boot 2016.01-rc1 (Dec 01 2015 - 16:30:32 +)

  Watchdog enabled
I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Error - No Valid Environment Area found
*** Warning - bad CRC, using default environment

Net:not set. Validating first E-fuse MAC
cpsw, usb_ether
=>

Something is probably wrong.


What happen if you type 'boot' command?

It boots! Magic!
Thank  you, but why it doesn't happen automatically?


Maybe you hit a key on your keyboard stopping autoboot?

Is the autoboot count down shown?

No, I've tried several times. It is just waiting for a command in prompt.


Could you try 2016.01-rc2 available at: home:Guillaume_G:branches:Base:System

If you still have this problem, please report it upstream.




p.s. I am not sure that it is related to u-boot, but is there any reason
why rc-s of u-boot appear in Factory? Would it be better to test them on
kittens instead of users?


Most of the time, I test u-boot on boards available to me when I update
it.
But, I do not have all boards supported by openSUSE, so it may break some
boards, but the sooner it is detected, the better it is! ;)



It makes sense.
Still would be great to have another JeOS which is guaranteed working
out of the box.


Standard release (13.2 or 13.1). ;)


Which is not there anymore, leap doesn't support armv7 and tumbleweed
is supplied with rc of u-boot :)


Yes, Leap without 32 bits support (both ARM and x86) is very annoying... :(


Guillaume

--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] No new JeOS images for Raspberry Pi 1, also meant for Raspberry Pi Zero?

[Andreas Färber]

Am 10.12.2015 um 23:03 schrieb Freek de Kruijf:
> Since September there are new images for other environments than JeOS, but 
> not 
> anymore for this environment. These last images did not work, I don't know 
> why. Is that the reason there are no new images?

No, they simply hang during build (kpartx under recent kernels) and get
killed after a timeout.

I was assuming a qemu-linux-user issue, but according to Alex it may be
related to udev not running in the chroot and some package update having
broken that use case.

> Are these images also meant for Raspberry Pi Zero?

Someone with such a board would need to test which changes (e.g., for
fdtfile handling) may be necessary.

Also, you may have noticed that I have been cleaning up the images
lately, and a raspberrypi-firmware submission is in flight and will
require changes to the JeOS image once accepted into 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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] No new JeOS images for Raspberry Pi 1, also meant for Raspberry Pi Zero?

[Dirk Müller]

Hi Freek,

> Since September there are new images for other environments than JeOS, but not
> anymore for this environment. These last images did not work, I don't know
> why. Is that the reason there are no new images?

Yeah, we're having issues with the build emulation. A fix is in
preparation, one of the next builds should work (I hope)...

Greetings,
Dirk
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Udoo Quad (IMX6Q) hangs at kernel boot

[Dirk Müller]

Hi Oscar,

> Now I would like to debug why it doesn't work with a current kernel. First
> step (IMHO) is to try the same kernel version but with the default config.
> Is there a way in OBS to recover a package to a point in time? If that's not
> possible, what should I do now?

you can recover the sources of an older state, but not the binary
packages,they don't get preserved. it is likely that you can rebuild
the older state of the kernel though.

Which state do you want to recover? basically you can narrow it down
by doing a branch of the kernel-source from factory, and then
selecting with "osc log openSUSE:Factory kernel-source" the revision
of the kernel that you want to try, and then do osc copypac
-r -K -e openSUSE:Factory kernel-source


Greetings,
Dirk
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Udoo Quad (IMX6Q) hangs at kernel boot

[Oscar C]

El 2015-12-02 13:52, Andreas Färber escribió:

Hi,

Am 01.12.2015 um 08:08 schrieb Oscar C:
I'm trying to boot my udoo-quad (it's very similar to the cubox-i 
that
we already support) using u-boot and kernel from mainline. Although 
it

boots the kernel fine, it hangs somewhere in the middle without any
error. The hang is not always in the same point, sometimes is goes
further while others not. Using the same u-boot but with a 
downstream

kernel works fine, so u-boot is not the problem here. Any idea?


It looks like it's recognizing mmcblk0 with p1 and p2, so I don't see 
an

immediate reason for it not to boot into your root. The HDMI error
should not be fatal.

Maybe some driver is missing in the initrd and needs to be added
manually via some /etc/dracut.conf.d/udoo_modules.conf  Welcome to openSUSE 20151118 "Tumbleweed" - Kernel 
4.0.5-20.gd3f999c-vanilla (ttymxc1).


Now I would like to debug why it doesn't work with a current kernel. 
First step (IMHO) is to try the same kernel version but with the default 
config. Is there a way in OBS to recover a package to a point in time? 
If that's not possible, what should I do now?


--
Cheers
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org