All Activity
This stream auto-updates
- Past hour
-
Bluetooth is supported in my kernel. All you need is have firmware in /lib/firmware and then run: btmgmt public-addr 00:03:19:9e:8b:00 or some other address. After boot. How to get FW is described here: https://megous.com/git/linux/commit/?h=opi3-5.2&id=9c296799c4d3dd90986833cfded392098c1979bd (On orange pi 3 that is)
- Today
-
For LibreELEC, this is possible.
-
Hi, I got a Phicomm N1 TV Box, which is Amlogic S905D. I'm trying to build libreelec/coreelect for it. I saw there is a step in the build script to build and write the u-boot to the header of the output disk image. I don't understand the purpose of this step. In my understanding, u-boot is already in the NAND of the box. What's the purpose to write it into the disk image? Is this step needed for my device? Currently I can see these u-boot env variables with my device: start_autoscript=if usb start ; then run start_usb_autoscript; fi; if mmcinfo; then run start_mmc_autoscript; fi; run start_emmc_autoscript; start_emmc_autoscript=if fatload mmc 1 1020000 emmc_autoscript; then autoscr 1020000; fi; start_mmc_autoscript=if fatload mmc 0 1020000 s905_autoscript; then autoscr 1020000; fi; start_usb_autoscript=if fatload usb 0 1020000 s905_autoscript; then autoscr 1020000; fi; if fatload usb 1 1020000 s905_autoscript; then autoscr 1020000; fi; if fatload usb 2 1020000 s905_autoscript; then autoscr 1020000; fi; if fatload usb 3 1020000 s905_autoscript; then autoscr 1020000; fi; Is it OK if I skip the u-boot writing step and just put the s905_autoscript and other necessary files in the root of the disk image the burn to the sdcard? I just want it boot into the libreelec/coreelect on the sdcard.
-
The result depends on the problem to be solved. In some tasks (terms of use) N2 is better and in others Khadas EDGE (RK3399) is better. To recommend something,you need to know the list of tasks and conditions of use. If you do not compile anything on the device, do not put extra packages, it can create unnecessary problems (if you do not understand their purpose). To update the kernel, you only need to install two packages "deb" "image"
-
Update image ver 5.86 For the N2 image version, the ability to directly start the system from USB has been added. Details can be seen in this topic.
-
I added to the site new images 5.87 for N2 with kernel 5.1 which already have the necessary scripts to start the activation of multi-boot (n2_autoscript) and start the system from USB (boot.scr). If activation is already done, then after burning the image to USB media, you do not need to add\change anything. When you connect to N2 in the USB stick, the system automatically starts up. By the way, I checked the fast USB 3.0 flash drive on N2 , the speed is higher than the SD card. And when using USB-SSD , much faster than eMMC. p.s. After comparing the operation of the system with eMMC and with a good USB-SSD, I concluded that eMMC is not needed for N2 at all.
-
it's a good idea to use tegrastats utility(for logging) or top-looks jtop from Raffaello Bonghi - it's show CPU\GPU\total power consumption, frequency and load graph for GPU too(on second tab - press 2)
-
I was just running "sudo dpkg -i *.deb" And the last message was "Compiling headers, please wait", and it never finished. On another box (Mini M8S) I installed the files one by one starting with the linux image and ending with headers if all worked well.
-
I had an attempt and building mainline uboot, adding in the N2 support and building the ATF firmware to run uboot. I did not have uboot working (some issues not long after uboot is started, I think I missed reserving memory) but I did manage to work out how to format the amlogic firmware to start uboot. It was a bit more complex and messy than the C2 process but can be scripted easy enough I believe, we would need some compiled blobs from the hardkernel git still I think for the moment as in the C2. I will keep trying uboot as baylibre add support for the g12a there. Would be nice to have mainline running on the SPI as many more possible features for booting images.
-
Try to press and hold the "CTRL+C" keys and only then turn on the power (do not release the keys until you get the output on the prompt screen from u-boot "#")
-
According to the log , you added support for USB in u-boot, which is located on eMMC. If you disable the eMMC module, you will not be able to start from USB. To fully support the launch from USB without any other media, it is necessary to add the update to the u-boot SPI.
-
I am checking on the latest version of the SPI image (20190417). After adding the launch from USB from u-boot SPI , the launch of all systems from both SD card and eMMC works perfectly in u-boot SPI. Thus, there is no need to add u-boot to SD card and EMMC, everything works with u-boot SPI.
-
it is a different issue here, cubietruck becomes progressively unresponsive and after a couple of days the only way to interact is to power it off holding the physical button. I'll try to use older kernels...
-
We are desperately waiting for the next release of u-boot / atf / A3700-utils by Marvell (enhanced DDR tuning for all EspressoBins is expected). Together with the pending patch performance may then increase by about 20 % and stability of V7 EspressoBins will hopefully be established too ...
-
you could check the - also new - following thread for informations:
-
Seems my espressoBin started randomly rebooting. sometimes it does it while sitting in a u boot prompt other times it will do it while bootting the os Any suggestions? anyone seen this before? Tried updateing uboot with no luck
-
Not sure if it's the same issue but i can't also connect to cubietruck (after update to armbian 5.85) via ssh, webmin, apache, node-red. Though I can connect via ftp and wireguard works!! I am away now so logs will be available next Saturday.
- Yesterday
-
While doing the kill, did you got the "got SIGTERM" ? If yes, you should add "gpio.output(REL, 0)" just after the print and before the "sys.exit(0)" ...
-
I tried to add at the end of the script, these 4 lines : def signal_term_handler(signal, frame): print 'got SIGTERM' sys.exit(0) signal.signal(signal.SIGTERM, signal_term_handler) but the relays maintain the status, even after the kill command.
-
@Igor Thanks! That seems to work fine. I only ran it for about 30 minutes though. root@espressobin:~# uname -a Linux espressobin 5.1.0-g72cf0b074 #1 SMP PREEMPT Sun May 19 18:21:04 CEST 2019 aarch64 GNU/Linux root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 439 450 368 589 591 505 585 487 RAM size: 984 MB, # CPU hardware threads: 2 RAM usage: 441 MB, # Benchmark threads: 2 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 438 122 349 427 | 13482 198 581 1151 23: 524 146 365 534 | 13276 198 580 1149 24: 520 147 381 560 | 12839 195 577 1127 25: 517 147 402 591 | 12862 198 580 1145 ---------------------------------- | ------------------------------ Avr: 141 374 528 | 197 580 1143 Tot: 169 477 835 I'm confused. I do not understand what this has to do with the U-Boot bootloader? 1000_800 worked fine with 4.4.8-armada-17.02-espressobin kernel. My board came with "U-Boot 2017.03-armada-17.10.2-g14aeedc" preinstalled, which on boot reported: CPU @ 1000 [MHz] L2 @ 800 [MHz] TClock @ 200 [MHz] DDR @ 800 [MHz] Which is why I choose to flash "flash-image-ddr4-1g-1cs-1000_800.bin". Espressobin v7 should run at 1.2 GHz, so I just tried flashing "flash-image-ddr4-1g-1cs-1200_750.bin", but now my board does not boot: Marvell>> bubt flash-image-ddr4-1g-1cs-1200_750.bin spi usb Burning U-BOOT image "flash-image-ddr4-1g-1cs-1200_750.bin" from "usb" to "spi" 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... 2 USB Device(s) found Image checksum...OK! SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB Erasing 917504 bytes (14 blocks) at offset 0 ...Done! Writing 889028 bytes from 0x8000000 to offset 0 ...Done! Marvell>> Marvell>> Marvell>> reset resetting ... TIM-1.0 WTMI-devel-18.12.0-a0a1cb8 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 0.898V It never gets any further than "SVC REV: 5, CPU VDD voltage: 0.898V" - any ideas?
-
Starting from SDCard, but check my EDIT2 above : I've found why, it was still taking boot.ini from eMMC, although booting SDCard ... Unfortunately, my SPINOR seems to be stuffed with a U-Boot that doesn´t have keyboard check, I've tried <space>, <return> and <ctrl-c>, none of them worked. So, I went back pluging the eMMC, and try it there, but here is the execution : odroidn2#usb start (Re)start USB... USB0: USB3.0 XHCI init start Register 3000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found odroidn2#fatload usb 0 3000000 n2_autoscript reading n2_autoscript 1107 bytes read in 22 ms (48.8 KiB/s) odroidn2#autoscr 3000000 ## Executing script at 03000000 Start add multiboot Saving Environment to MMC... Writing to MMC(0)... done Stop add multiboot bl31 reboot reason: 0x108 bl31 reboot reason: 0x108 system cmd 0. bl30 get wakeup sources! process command 00000006 bl30 enter suspend! Little core clk suspend rate 1200000000 Big core clk suspend rate 1200000000 store restore gp0 pll suspend_counter: 1 Enter ddr suspend ddr suspend time: 17us alarm=0S process command 00000001 cec ver:2018/04/19 CEC cfg:0x0000 WAKEUP GPIO cfg:0x00000000 use vddee new table! WAKEUP GPIO FAIL - invalid key After that, I've rebooted, it seems to start booting from USB, but stuck without reaching login prompt again ... I've added "loglevel=7" in boot.ini, and also in boot.cmd I've created to redo boot.scr using mkimage. But no success : booting from USB stall before login prompt without clue ... EDIT: It has finally booted, but without verbosity, and this time, it was present in /proc/cmdline.
-
no way, today i cannot even connect via ssh (timeout)
-
I’m using the Pine64 2GB Kickstarter’s board with the official LCD, running Armbian 5.25 Pine64 Debian (Jessie) 3.10.104 image. Everything works fine, display in terminal only and touch screen with the desktop. Now I would like to upgrade to the latest stable Armbian version (which on download page is 5.83). However now I can’t enable the LCD, although the download page says: It was a couple years back, I don’t remember exactly, but seems that was the same way I’ve used to enable the screen in old 5.25 Armbian. I’m no Linux kernel developer, but searching through the forum on the topic I found several mentions of “kernel recompile” - is there no other ways to enable the LCD in 5.83? Or I better stay with the old 5.25 Armbian? Just to clarify and rule out any hardware issues: I still have the uSD card with 5.25, swapping it back and everything shows up on the LCD. But booting the card with 5.83 and the LCD is blank, although everything works fine over ssh as well as on HDMI screen, if I connect it... Any help is very much appreciated. Thank you all very much in advance! Mac Ha
-
Ok, the old one has been delete, everything works fine: root@nanopineo:/# cd boot root@nanopineo:/boot# ls armbianEnv.txt dtb-4.19.38-sunxi armbianEnv.txte initrd.img-4.19.38-sunxi armbian_first_run.txt.template overlay-user bin script.bin bin.old System.map-3.4.113-sun8i boot.bmp System.map-4.19.38-sunxi boot.cmd uInitrd boot-desktop.png uInitrd-4.19.38-sunxi boot.scr vmlinuz-3.4.113-sun8i config-3.4.113-sun8i vmlinuz-4.19.38-sunxi config-4.19.38-sunxi zImage dtb root@nanopineo:/boot# apt-get remove linux-image-3.4.113-sun8i Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'linux-image-sun8i' instead of 'linux-image-3.4.113-sun8i' 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. root@nanopineo:/boot# apt-get remove linux-image-sun8i Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-image-sun8i 0 upgraded, 0 newly installed, 1 to remove and 2 not upgraded. After this operation, 48.6 MB disk space will be freed. Do you want to continue? [Y/n] y (Reading database ... 66591 files and directories currently installed.) Removing linux-image-sun8i (5.85) ... update-initramfs: Deleting /boot/initrd.img-3.4.113-sun8i root@nanopineo:/boot# I noticed that the idle temperature has increased from around 39°C to 47°C from the old kernel/version to the new one. Could the heartbeat feature (blue led flashing) be causing that (this wasn't present in the last version)?
-
Strange behaviour and boot log parameter on Nanopi NEO
Tungsteno74 replied to Tungsteno74's topic in SD card and PSU issues
Thanks @guidol, i solved this issue. Apparently for some unknown reason the sdcard bood image was corrupted. I reflashed it with the latest armbian and the boot log now is as expected. Cheers
