On 01/26/2015 12:28 PM, Stefan Botter wrote:

Hi Oscar,

On Mon, 26 Jan 2015 10:19:09 +0100 Oscar C wrote:

...

El 2015-01-25 11:44, Stefan Botter escribió:

...

Hi all,

I am trying to run the cubietruck JeOS image from d.o.o://ports/armv7hl/factory/images/, but so far without success. I have the image on a sd card, and put both partitions also on a connected sata disk. As far as I can see the kernel starts, but everything comes to a sudden stop where - I believe - the init/systemd process should take over.

I also tried the 13.2 image, but that did not work either, for sure because of the uboot version (mentioned here on the list earlier).

Is there any magic to perform? Can I help?

Could you attach the output of the serial console? The attached file is the log from reset of the board until the system is stuck, and after a reset I stoped the boot process and print the environment.

How did you find out that the system is indeed stuck? Could you please just leave it running for say 20 minutes and see whether it makes any progress? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 01/26/2015 12:28 PM, Stefan Botter wrote:

Hi Oscar,

On Mon, 26 Jan 2015 10:19:09 +0100 Oscar C wrote:

...

El 2015-01-25 11:44, Stefan Botter escribió:

...

Hi all,

I am trying to run the cubietruck JeOS image from d.o.o://ports/armv7hl/factory/images/, but so far without success. I have the image on a sd card, and put both partitions also on a connected sata disk. As far as I can see the kernel starts, but everything comes to a sudden stop where - I believe - the init/systemd process should take over.

I also tried the 13.2 image, but that did not work either, for sure because of the uboot version (mentioned here on the list earlier).

Is there any magic to perform? Can I help?

Could you attach the output of the serial console? The attached file is the log from reset of the board until the system is stuck, and after a reset I stoped the boot process and print the environment.

Please tell me, if you need more information. I used openSUSE-Factory-ARM-JeOS-cubietruck.armv7l-1.12.1-Build257.8.raw.xz downloaded last Friday.

[ 4.349256] ahci-5v: 5000 mV [ 4.352838] usb1-vbus: 5000 mV [ 4.356408] usb2-vbus: 5000 mV [ 4.360052] vmmc3: 3300 mV [ 4.363104] sunxi-rtc 1c20d00.rtc: setting system clock to 2085-01-26 11:23:16 UTC (3631346596) [ 4.371840] sr_init: No PMIC hook to init smartreflex [ 4.377113] sr_init: platform driver register failed for SR [ 4.388375] Unable to find PPMU node [ 4.392071] exynos5-bus-int: probe of exynos5-bus-int failed with error -2 [ 4.399082] vmmc3: disabling [ 4.401997] usb2-vbus: disabling [ 4.405223] usb1-vbus: disabling [ 4.408464] ahci-5v: disabling [ 4.411516] vcc3v3: disabling [ 4.414492] vcc3v0: disabling

This is where it stops. As a rough guess, maybe the 3v line is the one driving the CPU? :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Mon, 26 Jan 2015 20:28:03 +0100 Oscar C wrote:

El 2015-01-26 12:28, Stefan Botter escribió:

...

Hi Oscar,

On Mon, 26 Jan 2015 10:19:09 +0100 Oscar C wrote:

...

El 2015-01-25 11:44, Stefan Botter escribió:

...

Hi all,

I am trying to run the cubietruck JeOS image from d.o.o://ports/armv7hl/factory/images/, but so far without success. I have the image on a sd card, and put both partitions also on a connected sata disk. As far as I can see the kernel starts, but everything comes to a sudden stop where - I believe - the init/systemd process should take over.

I also tried the 13.2 image, but that did not work either, for sure because of the uboot version (mentioned here on the list earlier).

Is there any magic to perform? Can I help?

Could you attach the output of the serial console?

The attached file is the log from reset of the board until the system is stuck, and after a reset I stoped the boot process and print the environment.

Please tell me, if you need more information. I used openSUSE-Factory-ARM-JeOS-cubietruck.armv7l-1.12.1-Build257.8.raw.xz downloaded last Friday.

I have a cubieboard2 which is very similar to cubietruck (only dtb is different) and the last lines before systemd is launched are more or less similar to yours:

[ 3.556478] sunxi-rtc 1c20d00.rtc: setting system clock to 1970-01-01 00:00:09 UTC (9) [ 3.564429] sr_init: No PMIC hook to init smartreflex [ 3.569700] sr_init: platform driver register failed for SR [ 3.580194] Unable to find PPMU node [ 3.583804] exynos5-bus-int: probe of exynos5-bus-int failed with error -2 [ 3.590814] PM: Checking hibernation image partition /dev/disk/by-id/mmc-USD_0xe6300973-part3 [ 3.590832] PM: Hibernation image not present or could not be loaded. [ 3.590848] usb2-vbus: disabling [ 3.594078] usb1-vbus: disabling [ 3.597330] ahci-5v: disabling [ 3.600394] vcc3v3: disabling [ 3.603358] vcc3v0: disabling [ 3.607914] Freeing unused kernel memory: 1000K (c0d6a000 - c0e64000) [ 3.627665] random: systemd urandom read with 0 bits of entropy available [ 3.638585] systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP +APPARMOR)

However, I see something weird in your u-boot script: the variables and their values doesn't match what it should be. For example, the initial ramdisk should load from address 0x4a000000 but in the u-boot environment it seems to load from address 0x43300000. Could you post the file boot.scr which is on the first partition of the sd card? Thanks!

I have skipped the gobbledygook at the beginning of that file - 72 characters. The rest: === setenv ramdisk boot/initrd.uboot setenv kernel boot/linux.vmx setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs " plymouth.enable=0 console=ttyS0,115200n8 showopts ${append}" setenv kernel 'boot/linux.vmx' setenv initrd 'boot/initrd.uboot' setenv fdtfile 'dtb/sun7i-a20-cubietruck.dtb' setenv flavor 'cubietruck' setenv target 'firstboot' setenv bootdevs 'mmc' setenv bootparts '${unit}:1' setenv initrd_high '0xffffffff' setenv fdt_high '0xffffffff' setenv boottype 'bootz' setenv kerneladdr '0x46000000' setenv ramdiskaddr '0x4a000000' setenv should_use_fdt '1' setenv should_load_fdt '1' setenv fdtaddr '0x49000000' setenv setdev 'mmc dev ${unit}' setenv units '0' setenv sizeprefix '0x' setenv fs 'ext2' test -n "$kerneladdr" || setenv kerneladdr ${kernel_addr_r} test -n "$ramdiskaddr" || setenv ramdiskaddr ${ramdisk_addr_r} setenv load_kernel '${fs}load ${bootdev} ${bootpart} ${kerneladdr} ${kernel}' setenv load_initrd '${fs}load ${bootdev} ${bootpart} ${ramdiskaddr} ${initrd}; setenv rd_filesize ${sizeprefix}${filesize}' if test 1${should_load_fdt} = 11; then if test 0${fdtfile} = 0call_findfdt; then run findfdt setenv fdtfile dtb/${fdtfile} fi if test 0${fdtfile} = 0call_autodetectfdt; then run autodetectfdt setenv fdtfile dtb/${fdt_file} fi if test -n "$validatefdt"; then # Beagleboard xM needs to run validatefdt with latest u-boot run validatefdt fi setenv loadfdt '${fs}load ${bootdev} ${bootpart} ${fdtaddr} ${fdtfile}' else setenv loadfdt '' fi if test 1${use_fdt_addr} = 11; then # Calxeda systems use $fdt_addr rather than $fdtaddr setenv fdtaddr $fdt_addr fi if test 1${use_fdt_addr_r} = 11; then # At least upstream rpi_b uses $fdt_addr_r rather than $fdtaddr setenv fdtaddr ${fdt_addr_r} fi if test 1${should_use_fdt} = 11; then setenv boot_kernel '${boottype} ${kerneladdr} ${ramdiskaddr}:${rd_filesize} ${fdtaddr}' else setenv boot_kernel '${boottype} ${kerneladdr} ${ramdiskaddr}:${rd_filesize}' fi if test 1${remove_fdt_high} = 11; then setenv fdt_high fi setenv doit 'if run load_kernel; then; run load_initrd; run loadfdt; run boot_kernel; fi' setenv bootcmd 'for bootdev in ${bootdevs}; do for unit in ${units}; do setenv bootpart; for bootpart in ${bootparts}; do setenv fix_bootpart "setenv bootpart $bootpart"; run fix_bootpart; run setdev; run doit; done; done; done' boot === Greetings, Stefan -- Stefan Botter zu Hause Bremen