[opensuse-arm] oS 13.2 on cubieboard1 doesn't start booting
I am trying to install openSUSE 13.2 on a cubieboard1 that I bought about 2 years ago. It has an A10 and the PCB is labelled 2012-09-09. Out of the box it boots flawlessly into the Android 4.0.4, kernel 3.0.8 Nov 2012, stored on its nand flash ex factory. See its serial output below. Putting this http://download.opensuse.org/ports/armv7hl/distribution/13.2/appliances/open... on a uSD card (32G Adata, 16G Lexar 600x - same result) and powering up the board gives a black screen and no keyboard or mouse activity. The serial terminal (once opened, somehow) only shows: U-Boot SPL 2014.10 (Nov 30 2014 - 00:17:30) DRAM: 1024 MiB CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2 ### ERROR ### Please RESET the board ### Anything I can do/test here? Thanks, Volker Booting the android in nand flash: HELLO! BOOT0 is starting! boot0 version : 1.5.1 dram size =1024 Succeed in opening nand flash. Succeed in reading Boot1 file head. The size of Boot1 is 0x0003c000. The file stored in 0X00000000 of block 2 is perfect. Check is correct. Ready to disable icache. Succeed in loading Boot1. Jump to Boot1. [ 0.133] boot1 version : 1.4.0 [ 0.133] pmu type = 3 [ 0.134] bat vol = 0 [ 0.161] axi:ahb:apb=3:2:2 [ 0.161] set dcdc2=1400, clock=1008 successed [ 0.163] key [ 0.175] no key found [ 0.175] flash init start [ 0.226] flash init finish [ 0.227] fs init ok [ 0.228] fattype FAT16 [ 0.229] fs mount ok [ 0.236] script finish [ 0.237] power finish [ 0.244] BootMain start [ 0.244] 0 [ 0.264] key value = 0 [ 0.264] recovery key high 6, low 4 [ 0.265] unable to find fastboot_key key_max value [ 0.273] test for multi os boot with display [ 0.274] show pic finish [ 0.277] load kernel start [ 0.301] load kernel successed [ 0.301] start address = 0x4a00000 U-Boot 2011.09-rc1 (Nov 26 2012 - 14:01:52) Allwinner Technology CPU: SUNXI Family Board: A10-EVB DRAM: 512 MiB NAND: 3776 MiB In: serial Out: serial Err: serial --------fastboot partitions-------- -total partitions:11- -name- -start- -size- bootloader : 1000000 1000000 env : 2000000 1000000 boot : 3000000 2000000 system : 5000000 14000000 data : 19000000 20000000 misc : 39000000 1000000 recovery : 3a000000 2000000 cache : 3c000000 8000000 private : 44000000 1000000 sysrecovery : 45000000 14000000 UDISK : 59000000 93000000 ----------------------------------- Hit any key to stop autoboot: 0 NAND read: device 0 offset 0x3000000, size 0x2000000 33554432 bytes read: OK Starting kernel ... [ 0.181151] cryptomgr_test used greatest stack depth: 6672 bytes left [ 0.181535] cryptomgr_test used greatest stack depth: 6480 bytes left [ 0.183443] cryptomgr_test used greatest stack depth: 6388 bytes left [ 0.184385] cryptomgr_test used greatest stack depth: 6280 bytes left [ 0.217351] sw_ahci sw_ahci.0: forcing PORTS_IMPL to 0x1 [ 0.790418] [LCD] lcd_module_init [ 0.857446] regulator_init_complete: axp20_buck3: incomplete constraints, leaving on [ 0.865489] regulator_init_complete: axp20_buck2: incomplete constraints, leaving on [ 0.873517] regulator_init_complete: axp20_ldo4: incomplete constraints, leaving on [ 0.881461] regulator_init_complete: axp20_ldo3: incomplete constraints, leaving on [ 0.889376] regulator_init_complete: axp20_ldo2: incomplete constraints, leaving on [ 0.897360] regulator_init_complete: axp20_ldo1: incomplete constraints, leaving on [ 0.905093] sunxi-rtc sunxi-rtc: hctosys: unable to read the hardware clock [ 0.966821] init: to sleep 1 seconds. [ 1.970789] init: has waken up. [ 1.973981] init: [william] hdmistatus = 1! [ 1.978578] init: width = 1280 [ 1.981696] init: height = 720 [ 1.984756] init: s.st_size = 3686400 [ 2.155357] init: do_umount: /data [ 2.279486] e2fsck used greatest stack depth: 5696 bytes left [ 2.413573] init: do_umount: /cache [ 2.452029] init: dont need format /dev/block/nandk [ 2.458235] init: dont need format /dev/block/nandi [ 2.519475] init (1): /proc/1/oom_adj is deprecated, please use /proc/1/oom_score_adj instead. [ 2.533583] init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery' [ 3.550659] android_usb: already disabled [ 5.110541] init: untracked pid 99 exited [ 5.114581] init: untracked pid 101 exited [ 5.118703] init: untracked pid 103 exited [ 11.876030] sunxi-rtc sunxi-rtc: rtc only supports 63��2010��2073�� years [ 12.145692] BatteryStats-Wr used greatest stack depth: 5648 bytes left [ 16.606513] wemac wemac.0: WARNING: no IRQ resource flags set. [ 18.727648] netd used greatest stack depth: 5416 bytes left -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 24.03.15 09:37, Volker Kuhlmann wrote:
I am trying to install openSUSE 13.2 on a cubieboard1 that I bought about 2 years ago. It has an A10 and the PCB is labelled 2012-09-09.
Out of the box it boots flawlessly into the Android 4.0.4, kernel 3.0.8 Nov 2012, stored on its nand flash ex factory. See its serial output below.
Putting this http://download.opensuse.org/ports/armv7hl/distribution/13.2/appliances/open... on a uSD card (32G Adata, 16G Lexar 600x - same result) and powering up the board gives a black screen and no keyboard or mouse activity. The serial terminal (once opened, somehow) only shows:
U-Boot SPL 2014.10 (Nov 30 2014 - 00:17:30) DRAM: 1024 MiB CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2 ### ERROR ### Please RESET the board ###
Anything I can do/test here?
I guess this means that the SPL doesn't find its non-SPL, proper u-boot binary counterpart. I'd say the most likely culprit is that the SPL can't find the SD card, but it could be anything. If you'd like to debug this down further, get yourself a copy of the u-boot sources using osc $ osc bco Base:System u-boot then extract them $ quilt setup u-boot-cubieboard.spec $ cd <foo> $ quilt push -a and compile u-boot manually. Try to add printfs at strategic places where SPL tries to find the real uboot binary. To put the compiled SPL back onto your SD card, you can find the respective command in the JeOS package: https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/uboot... Also before you dig into any of this, I'd recommend to try out a Factory image first. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
This image at least boots: http://download.opensuse.org/ports/armv7hl/factory/images/openSUSE-Factory-A... However it fails to activate networking in general (no IPv4 address, no routes, no gateway, no resolv.conf - yes the LAN DHCP server works well), so it's still of no use. On what hardware have these images been tested? Thanks, Volker U-Boot SPL 2015.04-rc3 (Mar 09 2015 - 21:02:35) DRAM: 1024 MiB CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2 U-Boot 2015.04-rc3 (Mar 09 2015 - 21:02:35) Allwinner Technology CPU: Allwinner A10 (SUN4I) I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment HDMI connected: Setting up a 1280x1024 hdmi console In: serial Out: vga Err: vga SCSI: SUNXI SCSI INIT SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: emac starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 4 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 2705 bytes read in 70 ms (37.1 KiB/s) ## Executing script at 43100000 switch to partitions #0, OK mmc0 is current device 6601032 bytes read in 719 ms (8.8 MiB/s) 42667801 bytes read in 3794 ms (10.7 MiB/s) 22591 bytes read in 204 ms (107.4 KiB/s) Kernel image @ 0x46000000 [ 0x000000 - 0x64b948 ] ## Loading init Ramdisk from Legacy Image at 4a000000 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 42667737 Bytes = 40.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 49000000 Booting using the fdt blob at 0x49000000 Using Device Tree in place at 49000000, end 4900883e Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 ... [ 39.893308] systemd-udevd[1354]: starting version 210 [ 11.930660] Creating dracut based initrd [ 130.856442] device-mapper: core: cleaned up Image Name: Boot-Script Created: Fri Mar 13 01:02:05 2015 Image Type: ARM Linux Script (uncompressed) Data Size: 2547 Bytes = 2.49 kB = 0.00 MB Load Address: 00000000 Entry Point: 00000000 Contents: Image 0: 2539 Bytes = 2.48 kB = 0.00 MB skiped writing MBR ID for armv7l [ 132.368539] systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP +APPARMOR) [ 132.401255] systemd[1]: Detected architecture 'arm'. Welcome to openSUSE Factory (Tumbleweed) (armv7hl)! ... Welcome to openSUSE Factory "Tumbleweed" - Kernel 3.19.1-1-default (ttyS0). linux login: -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 24.03.15 10:34, Volker Kuhlmann wrote:
This image at least boots: http://download.opensuse.org/ports/armv7hl/factory/images/openSUSE-Factory-A...
However it fails to activate networking in general (no IPv4 address, no routes, no gateway, no resolv.conf - yes the LAN DHCP server works well), so it's still of no use.
Does it find the network interface? Log in using the serial console and type "ip a".
On what hardware have these images been tested?
We don't currently have automated testing for physical ARM hardware. Ludwig was working on getting at least OpenQA running in KVM VMs for AArch64, but that wouldn't help you much in this case. As for releases, whoever feels responsible for a certain platform can / does test it. If you'd like to take over that role for Cubieboard, I'm sure people would be very happy about it :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue 24 Mar 2015 22:37:36 NZDT +1300, Alexander Graf wrote:
However it fails to activate networking in general (no IPv4 address, no routes, no gateway, no resolv.conf - yes the LAN DHCP server works well), so it's still of no use.
Does it find the network interface? Log in using the serial console and type "ip a".
ifconfig -a shows lo (with IP) and eth0 (without IP). # ip a -bash: ip: command not found Perhaps this is the problem, I thought distros went from ifconfig to ip many years ago. And now I must be seeing things because it's working now, although I tried several times before posting yesterday. Networking is working as expected, even with a fixed MAC address (blast android). I saw the same problem on an RPi with oS 13.2 and I could ping briefly after forcing an address so it's not the cable. I found the problem with the terminal not opening most of the time (device busy) after plugging in the USB/serial cable. Modem manager must be told to go away. I asked the MM devs a while ago about this problem and they said they can't change it because some modems look like this and have to be probed. Add ENV{ID_MM_DEVICE_IGNORE}="1" to udev rules for this USB device (on the USB end, not the cubie side).
As for releases, whoever feels responsible for a certain platform can / does test it. If you'd like to take over that role for Cubieboard, I'm sure people would be very happy about it :).
13.2 still doesn't boot, factory has the boot problem fixed. I only have one board which I'm trying to use as a server to replace a power-hungry old PC, so factory isn't so good. Would the 13.2 repos work with the factory image? Happy to do some testing, though I suspect buying another PC Engines APU1 (makes a splendid firewall) would be far faster... ;-) Anyone can make cheap ARM systems but timely security updates are another matter. The board's been bottom drawered for 2 years because cubie's images didn't inspire me. Cheers, Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 25.03.15 11:03, Volker Kuhlmann wrote:
On Tue 24 Mar 2015 22:37:36 NZDT +1300, Alexander Graf wrote:
However it fails to activate networking in general (no IPv4 address, no routes, no gateway, no resolv.conf - yes the LAN DHCP server works well), so it's still of no use.
Does it find the network interface? Log in using the serial console and type "ip a".
ifconfig -a shows lo (with IP) and eth0 (without IP).
# ip a -bash: ip: command not found
Ah, use ifconfig -a then.
Perhaps this is the problem, I thought distros went from ifconfig to ip many years ago.
Yup, we just don't include iproute2 in the JeOS description.
And now I must be seeing things because it's working now, although I tried several times before posting yesterday. Networking is working as expected, even with a fixed MAC address (blast android). I saw the same problem on an RPi with oS 13.2 and I could ping briefly after forcing an address so it's not the cable.
Oh, ok. All is well then I guess?
I found the problem with the terminal not opening most of the time (device busy) after plugging in the USB/serial cable. Modem manager must be told to go away. I asked the MM devs a while ago about this problem and they said they can't change it because some modems look like this and have to be probed. Add ENV{ID_MM_DEVICE_IGNORE}="1" to udev rules for this USB device (on the USB end, not the cubie side).
As for releases, whoever feels responsible for a certain platform can / does test it. If you'd like to take over that role for Cubieboard, I'm sure people would be very happy about it :).
13.2 still doesn't boot, factory has the boot problem fixed. I only have one board which I'm trying to use as a server to replace a power-hungry old PC, so factory isn't so good. Would the 13.2 repos work with the factory image? Happy to do some testing, though I suspect buying another PC Engines APU1 (makes a splendid firewall) would be far faster... ;-) Anyone can make cheap ARM systems but timely security updates are another matter. The board's been bottom drawered for 2 years because cubie's images didn't inspire me.
Since Factory is supposed to be super-stable now, I think you'd be better of with it than 13.2 :). That said, I don't know how many people have actually tested continuous updates of kernels for example on openSUSE ARM yet. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wed 25 Mar 2015 23:59:43 NZDT +1300, Alexander Graf wrote:
And now I must be seeing things because it's working now, although I tried several times before posting yesterday. Networking is working as expected, even with a fixed MAC address (blast android). I saw the same problem on an RPi with oS 13.2 and I could ping briefly after forcing an address so it's not the cable.
Oh, ok. All is well then I guess?
Well, *networking*, yes. Sorry about the noise there, I don't get it.
Since Factory is supposed to be super-stable now, I think you'd be better of with it than 13.2 :).
All depends on if I want it to boot, I guess... ;-) After a day of running it I'm not sure factory doesn't mean exactly what it suggests: bleeding edge. Have the list: No NTP (ok solved, but it's not "stable release"). Different packages install the same files, different content [1]. I wanted yast-x11, because yast-ncurses is, uhm, for emergencies. Disk space is cheap: zypper in yast2-x11 yast2-control-center-qt libyui-qt6 xauth Result: None of the text input fields in any of the yast modules accept keyboard input. No reaction to such. yast-ncurses now runs dooog-sloooowwww, just by installing (but not running) yast-x11. The ncurses and x11 versiosn don't behave the same. The x11 one shows a long list of autoinstall packages. Irritating. Thanks for all your help, Volker [1] Checking for file conflicts: ...............................[error] Detected 2 file conflicts: File /usr/share/locale-bundle/ar/LC_MESSAGES/libpwquality.mo from install of bundle-lang-common-ar-13.2-7.2.noarch(openSUSE-Factory-repo-oss) conflicts with file from install of bundle-lang-gnome-ar-12.3-8.1.noarch(openSUSE-Factory-repo-oss) File /usr/share/locale-bundle/ar/LC_MESSAGES/system-config-printer.mo from install of bundle-lang-common-ar-13.2-7.2.noarch(openSUSE-Factory-repo-oss) conflicts with file from install of bundle-lang-gnome-ar-12.3-8.1.noarch(openSUSE-Factory-repo-oss) -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Volker,
No NTP (ok solved, but it's not "stable release").
No, its not a stable release, but its definitely easier and quicker to fix factory than a "stable" release. the fixes to stable release require coordination with many people and usually have weeks/months of turnaround. Factory is quicker than that.
Different packages install the same files, different content [1].
I've submitted a fix for that. thanks!
I wanted yast-x11, because yast-ncurses is, uhm, for emergencies. Disk space is cheap: zypper in yast2-x11 yast2-control-center-qt libyui-qt6 xauth Result: None of the text input fields in any of the yast modules accept keyboard input. No reaction to such.
How do you start it? locally? x forwarding? vnc?
yast-ncurses now runs dooog-sloooowwww, just by installing (but not running) yast-x11.
Can anyone reproduce that? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon 06 Apr 2015 23:58:55 NZST +1200, Dirk Müller wrote: Thanks for all your input Dirk!
I wanted yast-x11, because yast-ncurses is, uhm, for emergencies. Disk space is cheap: zypper in yast2-x11 yast2-control-center-qt libyui-qt6 xauth Result: None of the text input fields in any of the yast modules accept keyboard input. No reaction to such.
How do you start it? locally? x forwarding? vnc?
ssh. I always install X clients on headless systems. If nothing else, nedit is the number 1, 2 and 3 tool for system configuration. That was easy (thanks to the kind soul who had packages). yast-x11 however just has dependencies on the kitchen sink. openSUSE dependencies for "minimal system" are plain foobared. Debian doesn't have that problem AFAICT. The keyboard input in X11 yast was dead because the several hundred MB of stuff yast-x11 pulls in didn't contain anything to handle keyboard input(!!). I think it was libyui-qt6 (plus dependencies) that was needed. xauth is missing too. Sorry it appears I forgot to post about the keyboard problem. There may be other fundamental problems. I don't expect installing yast2-x11 to give me a running X server. It does. xdm is running. OK if it's required for console logins - which I'll follow up later, my HDMI/VGA adapter died. Or is the serial login the only one supposed to work on the cubieboard image out of the box? On x86 I'd expect runlevel 3, X clients, local console logins, no graphical login. Maybe ARM is different.
yast-ncurses now runs dooog-sloooowwww, just by installing (but not running) yast-x11.
Can anyone reproduce that?
yast2 over ssh starts up in 7s. yast in a terminal (also ssh) 49s. Just to show their start windows, not doing anything useful yet. Both are de-facto useless at this point (yast2 shows a big pile of stuff to install for no reason, still looking for why, no-one has time for yast on a Commodore C64). Memory use around 155MB, both started. Unsetting DISPLAY does not speed up yast. Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wed 25 Mar 2015 23:59:43 NZDT +1300, Alexander Graf wrote:
Since Factory is supposed to be super-stable now, I think you'd be better of with it than 13.2 :). That said, I don't know how many people have actually tested continuous updates of kernels for example on openSUSE ARM yet.
Running factory worked (mostly) very well for 2 weeks, until I ran zypper up. Things move forward all the time, but unfortunately not simultaneously, meaning the system as a whole just tumbles into the weeds... Some updated software package starts moving things around and the rest hasn't caught up yet. That's a play system, but I wanted to actually use it, and I am lacking the time to duplicate the efforts of the developers to track all the changes and get things running again. I am however not averse to getting a second board for playing. Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
El 2015-03-25 11:03, Volker Kuhlmann escribió:
On Tue 24 Mar 2015 22:37:36 NZDT +1300, Alexander Graf wrote:
However it fails to activate networking in general (no IPv4 address, no routes, no gateway, no resolv.conf - yes the LAN DHCP server works well), so it's still of no use.
Does it find the network interface? Log in using the serial console and type "ip a".
ifconfig -a shows lo (with IP) and eth0 (without IP).
# ip a -bash: ip: command not found
Perhaps this is the problem, I thought distros went from ifconfig to ip many years ago.
And now I must be seeing things because it's working now, although I tried several times before posting yesterday. Networking is working as expected, even with a fixed MAC address (blast android). I saw the same problem on an RPi with oS 13.2 and I could ping briefly after forcing an address so it's not the cable.
I found the problem with the terminal not opening most of the time (device busy) after plugging in the USB/serial cable. Modem manager must be told to go away. I asked the MM devs a while ago about this problem and they said they can't change it because some modems look like this and have to be probed. Add ENV{ID_MM_DEVICE_IGNORE}="1" to udev rules for this USB device (on the USB end, not the cubie side).
As for releases, whoever feels responsible for a certain platform can / does test it. If you'd like to take over that role for Cubieboard, I'm sure people would be very happy about it :).
13.2 still doesn't boot, factory has the boot problem fixed. I only have one board which I'm trying to use as a server to replace a power-hungry old PC, so factory isn't so good. Would the 13.2 repos work with the factory image? Happy to do some testing, though I suspect buying another PC Engines APU1 (makes a splendid firewall) would be far faster... ;-) Anyone can make cheap ARM systems but timely security updates are another matter. The board's been bottom drawered for 2 years because cubie's images didn't inspire me.
Yeah, we fixed all bugs in factory, use that. I have a cubieboard2 (same as you except for the dual-core CPU) and is running factory just fine: ixia:~ # uptime; uname -a 19:58 up 7 days 23:03, 1 user, load average: 0,22, 0,08, 0,06 Linux ixia 3.17.1-1.g5c4d099-default #1 SMP Sat Oct 18 23:36:23 UTC 2014 (5c4d099) armv7l armv7l armv7l GNU/Linux -- Cheers -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (4)
-
Alexander Graf -
Dirk Müller -
Oscar C -
Volker Kuhlmann