odoll

Members
  • Content Count

    34
  • Joined

  • Last visited

About odoll

  • Rank
    Advanced Member

Recent Profile Visitors

429 profile views
  1. I know it's not you to blame, but it's again disappointing with a GlobalScale product, which I bought as *up* to 1.2 GHz, just to find, that it's not even good enough to scale down to 1000/800, but even down to 800/800 to get a stable service.
  2. Started from 5.75 image again and installed the below one by one with a reboot in between linux-u-boot-espressobin-next 5.85 --> OK linux-stretch-root-next-espressobin 5.85 --> OK linux-image-next-mvebu64 5.84 --> hangs (linux-dtb-next-mvebu64 5.85) PS: Once again 5.75 -> linux-u-boot-espressobin-next 5.85 --> OK linux-stretch-root-next-espressobin 5.85 --> OK linux-dtb-next-mvebu64 5.85 --> OK but as there's no image between 5.75 and 5.84 I'll leave it that way for now (and I think you should revoke 5.84 as well!?)
  3. OT: when the PSUs of my SheevaPlugs started to fail I "swore" myself not buy any other device from Globalscale in the future, but even though I did it again ...
  4. OK, imaged Armbian_5.75_Espressobin_Debian_stretch_next_4.19.20.img to other SD and started from scratch --> OK Did apt-get update & upgrade which brought me back to 5.85 (5.84 image), but system hangs again after reboot So I think it's up to you now ;-)
  5. booting from SD, too. Checked FS of the SD which is clean and dd'ed to another SD, but same issue
  6. Just updated both my cubietruck and espressobin to 5.85, however the latter doesn't up come again after the update (from 5.83 IMO). (Had to get it out of the basement and) the console gives me the following error msg, now: Marvell>> boot starting USB... USB0: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found / ** Bad device usb 0 ** ## Executing script at 06d00000 Wrong image format for "source" command /boot/ ** Bad device usb 0 ** ## Executing script at 06d00000 Wrong image format for "source" command scanning bus for devices... Device 0: unknown device / ** Bad device scsi 0 ** ## Executing script at 06d00000 Wrong image format for "source" command /boot/ ** Bad device scsi 0 ** ## Executing script at 06d00000 Wrong image format for "source" command / Card did not respond to voltage select! ** Bad device mmc 1 ** ## Executing script at 06d00000 Wrong image format for "source" command /boot/ Card did not respond to voltage select! ** Bad device mmc 1 ** ## Executing script at 06d00000 Wrong image format for "source" command / ** File not found /boot.scr ** ## Executing script at 06d00000 Wrong image format for "source" command /boot/ 1119 bytes read in 13 ms (84 KiB/s) ## Executing script at 06d00000 221 bytes read in 5 ms (43 KiB/s) 16488960 bytes read in 706 ms (22.3 MiB/s) 6196865 bytes read in 275 ms (21.5 MiB/s) ** File not found /boot/dtb/marvell/armada-3720-community.dtb ** 8942 bytes read in 9 ms (969.7 KiB/s) ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 6196801 Bytes = 5.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 06000000 Booting using the fdt blob at 0x6000000 Loading Ramdisk to 3f042000, end 3f62ae41 ... OK Using Device Tree in place at 0000000006000000, end 00000000060052ed Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 4.19.41-mvebu64 (root@armbian.com) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #5.85 SMP PREEMPT Wed May 8 16:07:35 CEST 2019 [ 0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board [ 0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '') [ 0.000000] bootconsole [ar3700_uart0] enabled Loading, please wait... starting version 232 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.29.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk1p1] fsck.ext4 -a -C0 /dev/mmcblk1p1 /dev/mmcblk1p1: clean, 55272/444624 files, 453885/1900644 blocks done. done. Begin: Running /scripts/local-bottom ... /scripts/local-bottom/mdadm: 2: /scripts/local-bottom/mdadm: rm: not found done. Begin: Running /scripts/init-bottom ... done. [ 6.537013] SError Interrupt on CPU1, code 0xbf000001 -- SError [ 6.537017] CPU: 1 PID: 1 Comm: init Not tainted 4.19.41-mvebu64 #5.85 [ 6.537019] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT) [ 6.537021] pstate: 20000005 (nzCv daif -PAN -UAO) [ 6.537023] pc : get_page_from_freelist+0x5c/0x10e8 [ 6.537025] lr : __alloc_pages_nodemask+0xf4/0xb48 [ 6.537026] sp : ffffff8008033970 [ 6.537028] x29: ffffff8008033970 x28: 0000000000000002 [ 6.537032] x27: 00000000006200ca x26: 0000000000000081 [ 6.537035] x25: 0000000000000000 x24: 0000000000000000 [ 6.537039] x23: 0000000000000000 x22: ffffff8008033b38 [ 6.537042] x21: ffffffc03ffeb500 x20: 0000000000000081 [ 6.537046] x19: ffffffc03ffea180 x18: 0000000000000000 [ 6.537049] x17: 0000000000000000 x16: 0000000000000000 [ 6.537053] x15: 0000000000000000 x14: 0000000000000000 [ 6.537056] x13: 0000000000000000 x12: 0000000000000000 [ 6.537060] x11: 0000000000000000 x10: 0000000000000000 [ 6.537063] x9 : 0000000000000000 x8 : 0000000000000000 [ 6.537066] x7 : 0000000000000000 x6 : 0000000000000000 [ 6.537070] x5 : 0000000000000014 x4 : 0000000000000000 [ 6.537073] x3 : 0000000000000000 x2 : 00000000000000c0 [ 6.537077] x1 : 0000000000000001 x0 : 0000000000000068 [ 6.537081] Kernel panic - not syncing: Asynchronous SError Interrupt [ 6.537083] CPU: 1 PID: 1 Comm: init Not tainted 4.19.41-mvebu64 #5.85 [ 6.537085] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT) [ 6.537087] Call trace: [ 6.537088] dump_backtrace+0x0/0x1a0 [ 6.537089] show_stack+0x14/0x20 [ 6.537091] dump_stack+0x9c/0xbc [ 6.537092] panic+0x130/0x2a4 [ 6.537093] nmi_panic+0x6c/0x70 [ 6.537095] arm64_serror_panic+0x74/0x88 [ 6.537096] do_serror+0x134/0x138 [ 6.537098] el1_error+0x7c/0xdc [ 6.537099] get_page_from_freelist+0x5c/0x10e8 [ 6.537101] __alloc_pages_nodemask+0xf4/0xb48 [ 6.537102] alloc_pages_vma+0x88/0x210 [ 6.537104] __handle_mm_fault+0x3e8/0xdc8 [ 6.537105] handle_mm_fault+0x11c/0x1e0 [ 6.537107] do_page_fault+0x1c0/0x480 [ 6.537108] do_translation_fault+0x58/0x60 [ 6.537110] do_mem_abort+0x54/0x100 [ 6.537111] el0_da+0x20/0x24 [ 6.537130] SMP: stopping secondary CPUs [ 6.537131] Kernel Offset: disabled [ 6.537133] CPU features: 0x0,2080200c [ 6.537134] Memory Limit: none [ 6.755334] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
  7. Thx for the reply. That's odd, so the issue might be caused by the fact, that I'm not using an original Prolific, but cheap "China" clone cable!? I though this wouldn't cause an issue with Linux, as it does with Windows (with the latter I had to downgrade to a former Prolific driver to get it working, as the actual would detect the "fake".)
  8. Hello, I own boards of two different manufactures, namely a Cubietruck and an Espressobin. Before a recent Kernel update these days I was still greeted with the following messages: Welcome to ARMBIAN 5.73 stable Debian GNU/Linux 9 (stretch) 4.19.17-sunxi Welcome to ARMBIAN 5.73 stable Debian GNU/Linux 9 (stretch) 4.19.18-mvebu64 But even after the update - IMO apt-get was telling we're going from 5.73 to 5.75 versions of the files the version number in the greeting is still 5.73 Welcome to ARMBIAN 5.73 stable Debian GNU/Linux 9 (stretch) 4.19.20-sunxi Welcome to ARMBIAN 5.73 stable Debian GNU/Linux 9 (stretch) 4.19.20-mvebu64 I know that this might be a more cosmetic issue/question, but what criteria(s) drive(s) the version numbering?
  9. thx! - but don't think so (using armbian as didn't want to bother with those details myself ;-)
  10. Sorry for hijacking this thread, but I'm also having (two) issues with having USB Serial Support not working. Background: I plan to migrate my setup off a Cubiertuck over to an Espressobin, and as both devices are "remote" in the basement I thought I could ease my life by cross-connecting their "uart/serial/usb/jtag" ports. So a micro-usb cable is connected from the CT's USB to the EB's micro-USB port Cubietruck with ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.13-sunxi root@share:~# lsusb Bus 003 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port root@share:~# dmesg | grep -i usb usb 3-1: new full-speed USB device number 2 using ohci-platform usb 3-1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-1: Product: USB-Serial Controller D usb 3-1: Manufacturer: Prolific Technology Inc. usbcore: registered new interface driver usbserial_generic usbserial: USB Serial support registered for generic usbcore: registered new interface driver pl2303 usbserial: USB Serial support registered for pl2303 usb 3-1: pl2303 converter now attached to ttyUSB0 and an USB-TTL cable is connected from the EB's USB2.0 port to the CT's JTAG pins Espressobin with ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.14-mvebu64 root@espressobin:~# lsusb Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port root@espressobin:~# dmesg | grep -i USB usb 1-1: new high-speed USB device number 2 using orion-ehci usb 1-1: config 1 interface 0 altsetting 0 bulk endpoint 0x2 has invalid maxpacket 64 usb 1-1: config 1 interface 0 altsetting 0 bulk endpoint 0x83 has invalid maxpacket 64 usb 1-1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1: Product: USB-Serial Controller usb 1-1: Manufacturer: Prolific Technology Inc. usbcore: registered new interface driver uas Issue #1: On the CT I can connect to the EB via root@share:~# minicom -b 115200 --device /dev/ttyUSB0, but though I e.g. see the message on "the console" while rebooting the EB I can't interact with it, e.g. hitting "CR" during uboot does not work, nor can I logon via the console as it seems that no keystroke gets there. Issue #2: is even worse, as I don't have a ttyUSB0 port on the EB for CB's JTAG port at all. What's going wrong here? Why is it registered as an UAS? Using the same connection with puTTY on Windows I have noch issue to get to the CB's serial port. (Only issue is that the USB-TTL cable which I brought seems to be Prolific fake, which is disabled by recent Prolific's device drivers. Is that the same with Debian?)
  11. BTW: fell into the same pit and also got it working again with flash-image-1g-1cs-1000_800_boot_sd_and_usb.bin (v? from May 10th 2018). Got mine with only one chip on the back just a few days ago shipped from Amazon/US. However to You can obtain numbers from the current boot prompt., what are the appropriate commands to figure the right u-boot version for a board? It might be helpful to mention those on the site as well ;-)
  12. Maybe a long shot: rather than setting up armbian on my new ESPRESSObin (epb), installing needed SW and tools, porting configs off my Cubietruck (cbt), would it be possible to tweak the cbt's SDcard / FS to boot on the ESPRESSObin? If I'm not mistaken the cbtis armhf based and all those binaries should also run on the epb!? Would it be "good enough" to add the arm64 architecture to the CBT with "dpkg --add-architecture arm64" and then to install linux-u-boot-espressobin-next linux-image-next-mvebu64 linux-headers-next-mvebu64 linux-firmware-image-next-mvebu64 linux-dtb-next-mvebu64 linux-$(lsb_release -cs)-root-next-espressobin shut down the cbt and put the card into the epb, booting it in the epb?
  13. We're 10 days later and I'm happy to report that I haven't experienced any crashes or issues on this quoted setup (since upgraded back to v5.41 (or latest for dtb, image and u-boot)), though still having frozen tvheadend at 4.3-1067~g68d0bc5~xenial.
  14. I had another freeze though having downgraded my Cubietruck to v5.35 and I also had a suspicion about tvheadend and downgraded that to 4.3-1067~g68d0bc5~xenial and froze it as well. As the CB was running stable since the last 10 days I just unfroze the kernel and updated to v5.41, but left tvheadend at 4.3-1067~g68d0bc5~xenial. Will keep you updated