hmartin
-
Posts
67 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by hmartin
-
-
5 hours ago, ag123 said:
for the 1.5 GB and 4GB boards
there are some instructions and binaries here
Yes, I've followed the instructions:
$ sudo mount /dev/sda1 /mnt/ $ sudo cp sun50i-h616-orangepi-zero3-4gb.dtb /mnt/boot/dtb/allwinner/sun50i-h616-orangepi-zero3.dtb $ sudo dd bs=1k seek=8 if=u-boot-sunxi-with-spl-opizero3-4gb.bin of=/dev/sda 631+1 records in 631+1 records out 646523 bytes (647 kB, 631 KiB) copied, 0.156442 s, 4.1 MB/s
Unfortunately, it does not boot beyond "Trying to boot from MMC1" which makes me believe that there is probably an issue with the u-boot/SPL for the 4GB board. -
@ag123 can you post the full bootlog for the armbian release from GitHub (23.08)?
I tried both bookworm and jammy with several micro SD cards (including name brands like Samsung) and my board (4GB model) never gets further than the following:U-Boot SPL 2021.07-armbian (Jul 12 2023 - 10:04:49 +0000) DRAM: 4096 MiB Trying to boot from MMC1
* Armbian_23.08.0-trunk_Orangepizero3_bookworm_current_6.1.31-1GB-2GB.img.xz (sha256: 6c58ad6122fd62769e1063164df3cdf004af9d498f69db3f1c86094cc749a375)
* Armbian_23.08.0-trunk_Orangepizero3_jammy_current_6.1.31-1GB-2GB.img.xz (sha256: 7a794393ef8a5fedc73c4cc977cc5f29660ba106f17d0a6c2322a926f88e91fe)And yes, I did copy the 4GB dtb and u-boot as instructed.
I know this forum is not the place to ask for support for unofficial Armbian forks, but I'm just curious if you encountered any such issues. If I remove the micro SD card entirely, the board boots some kind of Android from the SPI:
U-Boot SPL 2021.07-orangepi (Jul 15 2023 - 15:02:23 +0800) DRAM: 4096 MiB Trying to boot from MMC1 [53]HELLO! BOOT0 is starting! [56]BOOT0 commit : 3ae35eb [59]set pll start [61]periph0 has been enabled [64]set pll end [67]unknow PMU [69]unknow PMU [73]PMU: AXP1530 [77]dram return write ok [80]board init ok [81]DRAM BOOT DRIVE INFO: V0.651 [85]the chip id is 0x2000 [87]chip id check OK [98]DRAM_VCC set to 1100 mv [101]DRAM CLK =792 MHZ [103]DRAM Type =8 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4) [114]Actual DRAM SIZE =4096 M [117]DRAM SIZE =4096 MBytes, para1 = 310a, para2 = 10001000, dram_tpr13 = 2006c61 [130]DRAM simple test OK. [133]rtc standby flag is 0x0, super standby flag is 0x0 [138]dram size =4096 [141]Use rtc to store dram tuning para [146]spinor id is: 5e 40 18, read cmd: 0b [150]Succeed in reading toc file head. [154]The size of toc is 9c000. [317]Entry_name = u-boot [322]Entry_name = monitor [326]Entry_name = dtb [330]Jump to second Boot. NOTICE: BL3-1: v1.0(debug):05d6c57 NOTICE: BL3-1: Built : 13:35:35, 2021-10-28 NOTICE: BL3-1 commit: 8 NOTICE: cpuidle init version V2.0 ERROR: Error initializing runtime service tspd_fast NOTICE: BL3-1: Preparing for EL3 exit to normal world NOTICE: BL3-1: Next image address = 0x4a000000 NOTICE: BL3-1: Next image spsr = 0x1d3<FF> U-Boot 2018.05 (Jul 10 2023 - 10:32:18 +0800) Allwinner Technology [00.408]CPU: Allwinner Family [00.411]Model: sun50iw9 I2C: ready [00.415]DRAM: 2 GiB [00.419]Relocation Offset is: 75f5d000 [00.439]secure enable bit: 0 [00.441]pmu_axp152_probe pmic_bus_read fail [00.445]PMU: AXP1530 [00.451]CPU=1008 MHz,PLL6=600 Mhz,AHB=200 Mhz, APB1=100Mhz MBus=400Mhz [00.457]gic: sec monitor mode [00.462]flash init start [00.464]workmode = 0,storage type = 3 SF: Detected zb25vq128as with page size 256 Bytes, erase size 64 KiB, total 16 MiB [00.481]sunxi flash init ok [00.485]Loading Environment from SUNXI_FLASH... OK [00.514]get secure storage map err [00.517]sunxi secure storage is not supported [00.521]usb burn from boot delay time 0 weak:otg_phy_config [00.535]usb prepare ok [53]HELLO! BOOT0 is starting! [56]BOOT0 commit : 3ae35eb [59]set pll start [61]periph0 has been enabled [64]set pll end [67]unknow PMU [69]unknow PMU [73]PMU: AXP1530 [77]dram return write ok [80]board init ok [81]DRAM BOOT DRIVE INFO: V0.651 [85]the chip id is 0x2000 [87]chip id check OK [98]DRAM_VCC set to 1100 mv [100]DRAM CLK =792 MHZ [103]DRAM Type =8 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4) [114]Actual DRAM SIZE =4096 M [117]DRAM SIZE =4096 MBytes, para1 = 310a, para2 = 10001000, dram_tpr13 = 2006c61 [130]DRAM simple test OK. [133]rtc standby flag is 0x0, super standby flag is 0x0 [138]dram size =4096 [141]Use rtc to store dram tuning para [146]spinor id is: 5e 40 18, read cmd: 0b [150]Succeed in reading toc file head. [154]The size of toc is 9c000. [312]Entry_name = u-boot [317]Entry_name = monitor [321]Entry_name = dtb [325]Jump to second Boot. NOTICE: BL3-1: v1.0(debug):05d6c57 NOTICE: BL3-1: Built : 13:35:35, 2021-10-28 NOTICE: BL3-1 commit: 8 NOTICE: cpuidle init version V2.0 ERROR: Error initializing runtime service tspd_fast NOTICE: BL3-1: Preparing for EL3 exit to normal world NOTICE: BL3-1: Next image address = 0x4a000000 NOTICE: BL3-1: Next image spsr = 0x1d3<FF> U-Boot 2018.05 (Jul 10 2023 - 10:32:18 +0800) Allwinner Technology [00.403]CPU: Allwinner Family [00.406]Model: sun50iw9 I2C: ready [00.410]DRAM: 2 GiB [00.413]Relocation Offset is: 75f5d000 [00.434]secure enable bit: 0 [00.436]pmu_axp152_probe pmic_bus_read fail [00.440]PMU: AXP1530 [00.445]CPU=1008 MHz,PLL6=600 Mhz,AHB=200 Mhz, APB1=100Mhz MBus=400Mhz [00.452]gic: sec monitor mode [00.457]flash init start [00.459]workmode = 0,storage type = 3 SF: Detected zb25vq128as with page size 256 Bytes, erase size 64 KiB, total 16 MiB [00.476]sunxi flash init ok [00.480]Loading Environment from SUNXI_FLASH... OK [00.509]get secure storage map err [00.512]sunxi secure storage is not supported [00.516]usb burn from boot delay time 0 weak:otg_phy_config [00.530]usb prepare ok [01.333]overtime [01.337]do_burn_from_boot usb : no usb exist [01.341]get secure storage map err [01.344]secure storage init fail [01.349]update dts [01.353]update part info [01.357]update bootcmd [01.359]No ethernet found. Hit any key to stop autoboot: 0 Android's image name: sun50i_arm64 [04.895]Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.9.170 (orangepi@ubuntu) (gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) ) #15 SMP PREEMPT Thu Jun 29 17:36:03 CST 2023 [ 0.000000] Boot CPU: AArch64 Processor [410fd034] [ 0.000000] bootconsole [earlycon0] enabled
On the HDMI output I have an error that it can't find initramfs, which is probably expected since there's no SD card present.
-
Hi, sorry if this is considered a necro bump.
I just received the Orange Pi Zero Plus H5, as it was seemingly out of production earlier this year. I have tried building u-boot from mainline (using v2020.07 and v2020.04) and both fail with the following error (SPI or FEL booting):
U-Boot SPL 2020.04-dirty (Sep 27 2020 - 20:11:48 +0000) DRAM: 512 MiB SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
Since I have read about people flashing u-boot from Armbian, I thought I would try FEL booting the u-boot included in the Armbian Focal image. Same deal:
U-Boot SPL 2020.04-armbian (Sep 02 2020 - 10:37:42 +0200) DRAM: 512 MiB SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
Yes, I did replace the Macronix 16MBit with Winbond 128MBit (25Q128FVSG), but I don't think this is the cause of my issues as they should both implement the same JEDEC commands.
Is u-boot SPI booting on the H5 just broken in recent u-boot releases? Or am I doing something fundamentally wrong?
I've spent many hours trying different u-boot configuration options (e.g. CONFIG_SPL_NOR_SUPPORT, CONFIG_SPL_SPI_SUPPORT, CONFIG_SPI_FLASH, etc), and I cannot figure out why it's broken. The dts is correct, and according to all the documentation I can find, the defconfig should be sufficient to support loading u-boot from SPI. -
On 12/4/2017 at 11:44 AM, Robert LabTeam said:
How to clone emmc content to another boards?
I would recommend instead that you install the base OS to NAND using the provided script and then use a configuration management tool like Ansible or Puppet to get the node into the final state.
Copying an image from one board to another is a bad idea for a few reasons:
- your SSH host keys will be the same
- your hostnames will be the same
- network configuration (if static) will need adjustment
If you want to provision and manage many boards, a configuration management system like Ansible or Puppet is the best method.
If this really doesn't work for you and you can only make a copy, then I would look into doing it at a filesystem level instead of a block level. rsync in archive mode (rsync -a) is a good tool for making filesystem level copies.
-
8 hours ago, zador.blood.stained said:
Looks like you are trying to build kernel 4.13.x while using a packaging patch for 4.14.x
Why do you think the patch is for 4.14? The patch has existed for many months, but Igor updated it recently.
(I'm genuinely curious, not trying to start an argument. I don't see 4.14 mentioned in the commit message or anywhere else. The similar patch for sun8i-dev is for 4.10 according to the commit message)
8 hours ago, zador.blood.stained said:In addition to this sunxi-dev target is mostly useless and is rarely updated, so it may break by itself too with upstream kernel updates.
Well it is the Banana Pi M2 Ultra, it would be more surprising if the kernel wasn't outdated. Anyway, it seems I can build the packages successfully without the patch, so I'll just exclude it from the build process.
-
Build environment is Ubuntu 16.04 in an lxc container.
Trying to build kernel + u-boot, I am repeatedly getting the following error:
patching file tools/include/tools/be_byteshift.h patching file tools/include/tools/le_byteshift.h CLEAN scripts/basic CLEAN scripts/dtc CLEAN scripts/kconfig CLEAN scripts/mod CLEAN scripts dpkg-deb: building package 'linux-firmware-image-4.13.0-rc4-next-20170811-sunxi' in '../linux-firmware-image-4.13.0-rc4-next-20170811-sunxi_5.34_armhf.deb'. gzip: /usr/share/doc//changelog.Debian.gz already exists; do you wish to overwrite (y or n)? y sh: 1: cannot create DEBIAN/md5sums: Directory nonexistent scripts/package/Makefile:97: recipe for target 'bindeb-pkg' failed make[1]: *** [bindeb-pkg] Error 2 Makefile:1343: recipe for target 'bindeb-pkg' failed make: *** [bindeb-pkg] Error 2 dpkg-deb: building package 'linux-source-4.13.0-rc4-dev-sunxi' in '/home/ubuntu/armbian/.tmp/linux-source-dev-sunxi_5.34_all.deb'. dpkg-deb: error: failed to read archive '/home/ubuntu/armbian/output/debs/linux-image-dev-sunxi_5.34_armhf.deb': No such file or directoryLooking at the root filesystem, I can see that something in the Armbian build process is actually overwriting /usr/share/doc/changelog.Debian.gz, which seems like it shouldn't be happening (e.g. files are supposed to be installed to a build directory):
Quoteubuntu@ubuntu_xenial:~/armbian$ ls -l /usr/share/doc/changelog.Debian.gz
-rw-rw-r-- 1 root root 184 Oct 19 19:37 /usr/share/doc/changelog.Debian.gzI've tried checking out armbian from github again, and the issue persists. Yes, I am building the kernel + u-boot for the Banana Pi M2 Ultra, which is unsupported (hence why I am posting here), but I cannot see anything in the configuration for this board that would be causing the above behaviour. Building the r40-v2 branch several months ago worked without issues. Since updating armbian to current, I am unable to package the r40-v2 or r40-v5 kernel.
If I remove the patch packaging-4.x-DEV-with-postinstall-scripts.patch I am able to successfully build the packages:
dpkg-deb: building package 'linux-firmware-image-4.13.0-rc4-next-20170811-sunxi' in '../linux-firmware-image-4.13.0-rc4-next-20170811-sunxi_5.34_armhf.deb'. dpkg-deb: building package 'linux-headers-4.13.0-rc4-next-20170811-sunxi' in '../linux-headers-4.13.0-rc4-next-20170811-sunxi_5.34_armhf.deb'. dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_5.34_armhf.deb'. dpkg-deb: building package 'linux-image-4.13.0-rc4-next-20170811-sunxi' in '../linux-image-4.13.0-rc4-next-20170811-sunxi_5.34_armhf.deb'. dpkg-genchanges: binary-only upload (no source code included) dpkg-deb: building package 'linux-source-4.13.0-rc4-dev-sunxi' in '/home/ubuntu/armbian/.tmp/linux-source-dev-sunxi_5.34_all.deb'. dpkg-deb: error: failed to read archive '/home/ubuntu/armbian/output/debs/linux-image-dev-sunxi_5.34_armhf.deb': No such file or directory [ o.k. ] Kernel build done [ @host ] [ o.k. ] Target directory [ /home/ubuntu/armbian/output/debs/ ] [ o.k. ] File name [ linux-image-dev-sunxi_5.34_armhf.deb ] [ o.k. ] Runtime [ 7 min ]@Igor I've looked at your modifications to the patch in commit 94bcf43 and I can't see anything obviously wrong, but it seems there is some regression in this patch which is causing packaging to fail now.
Could you confirm that kernel packaging is working correctly for you on sunxi-dev with the latest patch version?
-
Looks like the BananaPi M2 Ultra support is alive and well!
(this is sarcasm)
Mine was "working" until I decided to try mainline on it. Now I'm building Icesnowy's r40-v5 to see if there's been an progress. Please don't ask me for an Armbian image, support is nowhere near good enough to release even an alpha image.
-
On 5/4/2017 at 10:33 PM, tkaiser said:
For anyone else stumbling accross this thread: I referenced Icenowy's branches already in this thread for a reason and it should be noted that her patch series is called 'Initial Allwinner R40 support' -- not just Icenowy is concerned about still the only R40 device around being unfortunately a Banana product... and that pretty much sums it up why linux-sunxi devs are currently dealing with BPi M2 Ultra at all: no other R40 devices available
Glad I searched the forum. I'm trying to get 4.13-rc4 booting on the BPiM2U because apparently dwmac support is landing in 4.13. Unfortunately, it seems that we are still pretty far from mainline support for the R40, since trying to boot gets me this far:
http://i.imgur.com/gLRPxpE.png
I also found out that u-boot doesn't support USB, or Ethernet. So when I was missing the dtb (because 4.13 doesn't include one for the R40) the only way to recover was to boot from sdcard and copy the dtb. Thank goodness I still happened to have the armbian Banana Pi M2 Ultra image I made earlier on an sdcard. If not I would have just thrown it to the scrap.
I think I'll wait until 4.13 is released before I start hacking Icesnowy patches on top.
Exciting times ahead...
-
9 hours ago, TonyMac32 said:
So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero? I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions.
In my opinion this is not limited to the Orange Pi Zero, and I am definitely not the only one to experience it. I know this is another Orange Pi Zero thread, but please see:
Someone answered the question asked, but with an answer the user did not want to hear and did not accept. This in my opinion is a "garbage thread" candidate. It adds nothing, and attacks the person who answered the question.
It would be great to trial, but I'm not confident it will stop people from just going back to the original thread and posting even more hostile responses because their previous reply was censored. Perhaps it's possible to have a moderation team who are separate from the developers?
Anyway, I still say that it would be good to have a separation between "official" support of a limited # of boards, and "unofficial" support where stable/nightly releases are not provided and people can build and provide "unofficial" builds from git if they are willing to deal with users like the above. This method has worked well for the Android scene, and I don't see why it can't also work well for Armbian.
Official boards can have forum sections dedicated to support threads. Unofficial boards have their own "unofficial" area. To avoid too much moderation work, only official area would be moderated. Unofficial area is more like "wild west"
-
Just to update this thread: we now have kwboot working on Armada 38x boards. The trick to getting kwboot working was a patch which was never included in u-boot mainline: https://lists.denx.de/pipermail/u-boot/2015-August/226105.html
If you apply this patch to u-boot tree and build it, you will get a kwboot binary that works for Armada 38x chips. The timing is still variable, so it will take multiple attempts to successfully kwboot, but it is definitely possible.
I am quoting the post from Doozan:
QuoteHoly shit. It works!
Apply the attached patch to kwboot.c in v2017.05 u-boot source. The patch is originally from https://lists.denx.de/pipermail/u-boot/2015-August/226105.html
But it seems the patch was never applied to kwboot in the u-boot mainline (or at least, I cannot find it in the git log kwboot.c).
The timing isn't perfect, I have to try a few times (edit: maybe 1 in 6 attempts is successful) before I can reproduce it, but I can definitely boot the u-boot I built from WD source (see the boot log below for build date, version, and "I run u-boot from kwboot!").
I tried u-boot-spl.kwb from v2017.05 but no luck.
$ ./kwboot -f -t -B 115200 /dev/ttyUSB0 -b u-boot-a38x-Yosemite_2014T3_PQ-nand-uart.bin -s 0 -q 1 Sending boot message. Please reboot the target...-�$�"Ufw�$�"U����$ Dfw�$�"U�\�$�"U����$�DUf�$�"U�w���"U����$4"U���$�"U�w�$�"U���$�DUf|fD�&T����$�"U�E�$�"Df3DD�DU�E7$�"U����$4"U���$�"U�E��4"U�/7@� ���$�DU�w�$�"U����$�DUff�$�"D��fD$U�� Sending boot image... 0 % [......................................................................] <this goes on for a while> 99 % [...................................] [Type Ctrl-\ + c to quit] � __ __ _ _ | \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| ** LOADER ** U-Boot 2013.01_v1.08 (Jun 05 2017 - 14:51:29) hmartin version: 2014_T3.0p6 Board: Yosemite DB6820 SoC: MV88F6820 Rev A0 running 2 CPUs CPU: ARM Cortex A9 MPCore (Rev 1) LE CPU 0 CPU @ 1332 [MHz] L2 @ 666 [MHz] TClock @ 200 [MHz] DDR @ 666 [MHz] DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled DRAM: 1 GiB Map: Code: 0x3fece000:0x3ff95d58 BSS: 0x3ffef254 Stack: 0x3f9cdf20 Heap: 0x3f9ce000:0x3fece000 raise: Signal # 8 caught raise: Signal # 8 caught U-Boot Environment: 0x00000000:0x00080000 (NAND) NAND: ID: dcad ,512 MiB MMC: mv_sdh: 0 PCI-e 0: Detected No Link. USB2.0 0: Host Mode USB3.0 0: Host Mode USB3.0 1: Host Mode Board configuration detected: Creating 1 MTD partitions on "nand0": 0x00001f500000-0x00001ff00000 : "mtd=7" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 126976 bytes UBI: smallest flash I/O unit: 2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset: 4096 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=7" UBI: MTD device size: 10 MiB UBI: number of good PEBs: 80 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 32 UBI: total number of reserved PEBs: 48 UBI: number of PEBs reserved for bad PEB handling: 2 UBI: max/mean erase counter: 2/0 UBIFS: mounted UBI device 0, volume 0, name "reserve2" UBIFS: mounted read-only UBIFS: file system size: 4063232 bytes (3968 KiB, 3 MiB, 32 LEBs) UBIFS: journal size: 1015809 bytes (992 KiB, 0 MiB, 6 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: LZO UBIFS: reserved for root: 200807 bytes (196 KiB) Loading file '/mac_addr' to addr 0x02000000 with size 36 (0x00000024)... Done lan mac_addr : 00 90 a9 ff ff ff Set lan 0 WakeOnLan ok Set lan 2 WakeOnLan ok I run u-boot from kwboot! Enable HD1 Enable HD2 Net: | port | Interface | PHY address | |--------|-----------|--------------| | egiga0 | RGMII | 0x00 | | egiga1 | RGMII | In-Band | | egiga2 | SGMII | 0x01 | egiga0 [PRIME], egiga1, egiga2 Hit any key to stop autoboot: 0 Marvell>> 1111
-
2 hours ago, TonyMac32 said:
For a new Board, exactly as tkaiser opened the discussion, updating as new information becomes available. Once a decision has been made by the team (I would assume a dev or two would have to more or less "adopt" the board in question for hardware support), close the thread, maybe clean it of extraneous info if mods haven't been doing that actively, and archive it as reference on a wiki, or transfer its information to a wiki and link to an archived PDF/html/whatever of the original, maintaining the conversation, but not allowing it to get buried or cause a huge amount of "pinned" topics you have to drill through to get to "live" discussions.
Upon officially declaring a board to be supported, have a subforum for the board (I know, huge effort organizing), then open a discussion/debugging thread for each release. Lock that thread upon release and open a bugfixing thread, etc. Keep the last release or two on the forum as immediate reference, archive the rest as HTML/PDF/Whatever available via a Wiki page for the board. A "Hardware Support Status" table on a wiki would be ideal, just simple Green/Yellow/Red next to the supported bits per kernel, a simple visual aid goes a long way. I would include an * or <- or some other mark with a note about special patching if it's needed (WiFi on Tinker Board Kernel 4.4 as an example)
Now, boards may come about that initially seem like a great idea, check the boxes, but which later turn out to be piles of garbage. I would recommend having a mandatory "trial period" for a board before committing to support it, no matter how perfect it might seem. (Call it "Maybe-an"?
) Again, personal experience here, the Tinker Board BT, SD power supply, and MAC address issues all require hacking up the kernel in a not easily supportable way or writing our own drivers. Some of that wasn't obvious until the Rockchip/ASUS team released the source for their kernel. In a situation like this, a discussion needs to happen concerning how to support and if/why to support moving forward. I would personally wait another cycle for the next release and see if any more mainline work is done on the part of the vendor. If not, we need to decide if something as ridiculous as making the board capable of rebooting properly is our responsibility/interest.
Two things I want to bring up:
- "Trial period" is a great idea, and this is what I was getting at: During the "trial period" nightly/stable builds are not available. Anyone wanting to test out the board during the trial period has to build an image from git themselves. This prevents devs from being mobbed by people for support when there are still lingering issues.
-
Forums suck for finding information, and no one ever uses the search feature. So, wiki software. MediaWiki is FOSS, but the syntax sucks. Confluence isn't FOSS, but it is free for Open Source projects, and they have a really excellent editor. I'm not affiliated with Atlassian in any way, I just think if you want a usable, low-friction wiki, Confluence would be a good choice. I realize since Confluence is not FOSS, this has some negative appeal in some corners. Also it's Java...
2 hours ago, TonyMac32 said:While it will upset the low-information DIY-er, I think you'll find collecting such requests/feedback into dedicated "rubbish threads" that link to the FAQ and disclaimers won't be detrimental to the project.
We tried this already with the Orange Pi Zero. It just ended up pissing off everyone who was working on it (including me). No user seems willing to accept our explanations about performance and what is feasible. They think because the manufacturer says "WiFi" it will do the same things as their $1,200 laptop with dual-band 3x3 802.11ac.
Why should I sit here and take shit from people who expect perfect WiFi from a $9 SBC and pay nothing toward Armbian? Especially after we calmly explain what isn't possible, they say "well I was thinking about giving you money, but since you can't make magic unicorns out of thin air, forget it" Seriously?! Seriously?!!! No. Please go away.
-
3 hours ago, zador.blood.stained said:
Agree. Categories like "Recommended by Armbian for building a medium level NAS", "Recommended by Armbian for building a powerful router" or "Recommended by Armbian as a low cost IoT node" would be better - still suggesting users (that decided to check the software situation before buying the board) what to choose without creating false assumptions regarding product quality and support.
Unfortunately even if we tag i.e. Orange Pi Zero as "Not a good choice for making a multimedia center" and "Not a good choice for making a wireless AP", it won't stop people from trying to use the board for exactly those use cases.
I still have a problem with this. Because these devices are from China, and the manufacturer can change the board at any time. Maybe rev. 1 of the board was great, but they found a way to lower the cost (say, replace the WiFi module with a cheaper version, or replace EMMC with worse version) and rev. 2 is a pile of garbage.
Just look at the OpenWrt/LEDE wiki if you want to get an idea of all the stupid things companies will do to lower cost and raise profit. Reduce memory size, reduce flash size, change chipsets entirely.
I know this isn't very likely on these SBCs, because companies will just release a new version, but we have seen board revisions before (e.g. early Orange Pi Zero shipped without any SPI flash).
Saying "Certified/Recommended for X" is a trap, because as soon as the company revises the board and breaks something, people will come here and complain, so you don't want to go there. I would go so far as to say if a manufacturer releases a new revision of the board which breaks the build, then we stop supporting the board.
I would rather it go something like "Compatible with Orange Pi Zero Rev 1" or something which doesn't sound like a guarantee. Certified/Recommended to me says "it will work" instead of what Armbian should say, which is "it should work"
As we've said previously, the Orange Pi Zero should not even have stable/nightly builds, given the hardware issues. This is an example of a board I would say is only available to build from git for those who are very willing to try.
Edit: but this is getting pretty far from Rock64 topic... perhaps we can debate in another thread?
-
6 hours ago, gnasch said:
No hardware vendor will read the complaints in your forum. Armbian on the other side has quite the reputation. Do the same, define conditions for boards to be "Certified for Armbian" and push the vendors your way.
The problem with these "certifications" is that then people expect everything to work perfectly. This simply isn't possible where someone can install any software with apt-get or compile it themselves. You'll say "Certified for Armbian" and then someone will say "but it doesn't work when I try to compile Firefox from source" which is obvious to anyone that there isn't enough memory, but you said "Certified for Armbian" so they assumed it could do anything.
It's too difficult to say "Certified for X" and then expect the user to A. have reasonable expectations, and B. read the list of limitations (e.g. minor software/hardware issues).
18 hours ago, tkaiser said:Please remember situation with OPi Zero: we (some from the inner circle) were excited, added the board, improved settings like crazy. Later we discovered unfortunate Wi-Fi power management settings, then Wi-Fi here being somewhat crappy anyway. If there would have been a rather clean 'board bring up' thread such findings would have been documented (adjusting post #1 in the respective thread), board support rating would have been adjusted and post #1 of the thread could act as something like a landing page for the specific device (moderators pushing newbies to this 'page' for example).
I don't see any problem for people to add support for boards via git. The best solution to avoid dealing with angry users is to not provide stable/nightly builds. If you force someone to compile Armbian from source to support a board, it raises the level of effort and technical knowledge required massively. People who know enough to compile Armbian for a board from git are the kind of people you want to come here.
20 hours ago, tkaiser said:I call it inner circle if only those who have access to the Private forum are allowed to join these discussions. Again: I propose a new subforum to discuss board bring up decisions. That's not meant for end users but for a developer starting with something as proposed in post #1 of this thread (that's why this thread title has the '[Example] in its name): an overview where we are, what's to expect, pros/cons. This is the most basic requirement for starting a thread. Then I looked through this thread again and found exactly one single post that was 'end user stuff', all the others were more or less focused on device discussion. Also @Kwiboojoined and IMO this is something Armbian forum should allow. Joining development efforts even if the end result is not Armbian but something else (at least that's my goal since the two years I joined now: stop people wasting their time moronically in vendor forums and let Armbian be a place of interchange and development)
If people misuse the 'Board Bring Up Discussion' subforum for stupid 'Hey, when is XY ready?!' threads or start to destroy such threads then posts have to be moved to somewhere else. Now that a few more people join moderator crew that shouldn't be that hard to achieve.
I disagree with having any private areas for board support. The reason is simple, it will keep out talented people who don't otherwise know about the hidden areas.
I understand you want to avoid having users pile on with "+1" support for cheap shit, but there are easy ways to handle that.
I think any discussion among developers about supporting a new board should be publicly visible, if not necessarily open for public comment. IMHO transparency is very important in open source. To have a closed section for making these decisions could potentially remove developers who want to support but are not part of any "inner circle"
I would propose that the section is open for all users, but people who abuse it by starting threads full of "+1" are blocked from posting further. If this proves to be too difficult to maintain, then posting is restricted to developers.
But my biggest concern is friction. It's hard enough to get developers, but if you make it harder for them to contribute, they simply won't come. Therefore we should be trying to make it as easy as possible for the next developers, who may not be known to us yet, to come and start developing for Armbian too.
22 hours ago, Igor said:I thing we got the point. Not sure if we really behave exactly that way, but yes, we need to change pattern and not jumping up when boards arrive. Agree on that. It's in our own good. No doubts about that.
Well - what about community supported boards - which does not need our approval? It should be in our interest to provide opportunity for anyone who want's to bring board into Armbian and benefit from anything what build script offers ... but we have to make clear that there is no support within the build process, at first login, don't provide downloads, ... etc. One good example are balbes150 creations, which we even think to merge in once, but it's some work ...I still stand by my previous statements: Developer(s) commit to supporting a board. If the developer is no longer able to support the board, then someone else takes over. If the board is already "mature" and well supported, then perhaps no one is needed, but this would need to be considered for each board depending on the status.
I go back to what I said earlier, I think Armbian should not build stable/nightly builds for "community supported" boards. Make it like the Android ROM scene: you provide the source for popular/well supported devices (e.g. Lineage OS "Official" devices), and other people are free to build their own image from source and post it here if they want (e.g. "Unofficial" builds). But make it more like XDA: there is a dev db listing the source/version/credits, and a big disclaimer that Armbian does not support these, WARRANTY VOID, etc.
I think this would actually make more people contribute. Outside of the core devices, someone actually has to build the image themselves, post it here, and maybe provide support. If it gains enough traction, then Armbian could consider officially supporting it.
I guess my point, and I don't make it very well, is this: make it easier for developers to contribute. Make it harder for users to download an image with half support. If someone cares enough to build an image from the source and post it here, then that shows some commitment from them.
You don't necessarily have to stop supporting every board a vendor sends you. If you just love getting Armbian to boot on the latest hot garbage, then go for it. Why should we stop you? But leave these changes in git. Don't provide users with images they can easily flash.
-
13 minutes ago, Tido said:
So, does your thread address the somewhere in flight instead of pre-flight checks?
"If later on, no one is taking care of the board and things are breaking, we can have a discussion to remove support."
Does this not address "in flight" ?
If the board is added and builds are failing, or people are complaining that things are broken, and no developer is fixing it, then we drop support.
-
28 minutes ago, Tido said:
WTF, you need a tool and responsible people a so called 'group' or team.
The number must be uneven or there is a leader with the power of 'two-votes-in-one' in case the number is even.
- So you introduce.
- discuss.
- finalize discussion - close it.
- decide.
Done
I don't really think anyone disagrees with you. As I said in my previous post, this isn't a popularity contest of which boards are most popular (because that would probably end up being the cheapest, crappiest boards) but rather what Armbian developers are able to reasonably support.
So here we are having the discussion. It seems like people are receiving dev samples for testing. If they decide to put in the effort to add support to Armbian, then the board will be supported.
If later on, no one is taking care of the board and things are breaking, we can have a discussion to remove support. -
@tkaiser nice start!
- Has pricing been announced?
- What about availability? Is there sufficient supply that users can buy it? (Or what is the expected release date)
- Any armbian developers committing to getting the board included into nightly releases?
Any thoughts on an appropriate benchmark to test GbE and USB3? It would be great if we could standardize on something so people can use the test results to compare before purchasing.
-
On 5/11/2017 at 9:17 PM, exquisitus said:
uhuh, thank you for your reply... i hate to say that, i really do, but such a reply is indeed less useful than no reply at all. disapponting.
see my question is completely void of any emotional baggage. and your reply is loaded with it, patronizing, full of prejudice and attitude.
do i need that? not at all. last time i checked i had eyes and got an impression i could see, so it would be probably wiser if you assume you are the only one with eyes in a land of the blind.
want to communicate how cool you are? didn't work, better luck next time.
and yes, if i could fix the problem, i would have done that. if i had not done it, that simply means that i cannot do it and i would like to read useful opinions to get a better understanding from people who are perhaps more knowledgeable, ok?
not at all interested in wasting my time bickering or playing games.
why in hell is empty smartass talk even a trend here, what useful purpose does that serve... jesus...
exquisitus, I don't see how jhpadjustable's reply was patronizing, prejudiced, or full of attitude. He politely said that if you want to know the history of the module (and why it's not well supported) there are other threads talking about it. I really don't see how his reply is "less useful than no reply at all" since he told you where you can find more information (something you can also do with the forum's search feature).
When people here provide information to users, and then get replies like yours, it's no wonder the driver situation doesn't improve. Anyone who is working to make it better just gets people coming and being offended by their answers.
If you're unhappy with the state of the XR819 driver, I have the perfect place for you to go to solve your problems: https://github.com/fifteenhex/xradio/pulls
I hate to say it, I really do, but I think you need to see this: https://www.youtube.com/watch?v=F-mju_gW3c8
-
Hi all,
Over at Doozan we are having quite a time trying to get kwboot to work on the newer Armada 385 based boards. It works for the ClearFrog because there is a DIP switch to select UART boot. However on shipping products like the Zyxel NAS326 and the Western Digital EX2 Ultra/EX2100/EX4100 this is not an option.
Does anyone else have any of the above products? Were you ever successful in getting it to load u-boot via uart?
-
I have a NAS which can support iSCSI, NFS, or NBD. I have several years of experience using iSCSI on x86, but I was wondering if anyone is using it on these ARM boards.
I'm also looking at NBD, because it is supposedly lower overhead than iSCSI. Is anyone currently using NBD on their SBC?
I've heard NBD doesn't handle connectivity issues as well as iSCSI, so it's not wise to use for data you care about. However, providers such as Scaleway are using NBD as the rootfs for their ARM servers (not saying this is good or bad, just saying it).
I am thinking specifically of having the SBC be the client, not the server. However anyone who can provide insight into the performance of the boards using NBD/NFS/iSCSI as server/client it would be appreciated.
(Apologies if this is a duplicate, I searched for topics about NBD but couldn't find any existing discussion about it)
-
On 5/28/2017 at 8:11 PM, tkaiser said:
- immediately think about no more releasing those absolutely useless 'nightlies' any more
- prepare a board phase out process (to get rid of shitty hardware we started to support by accident, eg. Actions Semi S500 boards)
- stop stupidly trying to convert Armbian project (good, secure and stable OS images) into a board bring up adventure (crappy and instable OS images adding more and more questionable hardware and frustrated users)
-
I still find the nightlies useful, but then again I know they are in development and don't expect them to be perfect. I realize other people don't understand this.
- Maybe you want to switch to a different model? Semi-regular releases with some automated testing. For people who want nightly builds, they can build it themselves.
- Agree. There needs to be a way to phase out support for boards if there is no more community support or they cannot be maintained.
-
Agree. Armbian should not be "hey vendor, cheap out on software because Armbian will fix it for you" therefore I would propose:
- Only add boards where mainline support is coming/already implemented
- Only add boards where the hardware is of a certain quality (e.g. none of this micro USB powered shit, too time consuming to support people with stability issues)
- Only add boards when there is at least one dedicated developer who will be working on it (e.g. people can vote to support a new board, but unless someone is willing to contribute code, we aren't going to do the work. I'm thinking quite specifically of the Orange Pi Zero here, where people were complaining while contributing absolutely nothing)
-
On 27.5.2017 at 7:55 AM, tkaiser said:
Soon this forum will get flooded by Berry users asking for software that makes their BPi Berries stable if we don't take countermeasures.
While I agree that it is not our job to provide support to people buying the boards (that would be the manufacturer's responsibility) if someone wants to add support for the board in Armbian I don't see why we should refuse their help.
Of course I have zero sympathy for people who come here and complain about the hardware decisions the vendor made (e.g. microUSB power, crappy EMMC, bad 1T1R WiFi) because that is entirely outside our control.
So I would say, if someone does submit patches to support the Banana Pi M2U or Berry, we accept it. But it is also wise to put up a disclaimer that any images for Banana Pi come with zero support and we will ignore requests for free support on the forums.
-
On 4/27/2017 at 7:57 PM, hojnikb said:
Can any test actual battery capacity with discharging manually (like with imax b6). I'd really like to know if the batttery is really 10Ah or just 5Ah pretending to be 10Ah.
Also, what about power consumption when i use ?
My charger is unfortunately limited to 5W discharge, but since this is pretty close to the PineBook consumption it should be okay. It's certainly good enough to accurately determine the battery capacity.
I'm just waiting for my PineBook to ship. When it arrives I will do a few cycles on the battery to test the capacity outside the PineBook.
Edit: I have a coupon valid until 4 May 2017 (tomorrow) to order a 14" PineBook, if you want to skip the queue. The order is estimated to ship at the end of May. If anyone is interested, PM me your email address and I will send you the code to order. You'll have to use my email address, but I'm happy to forward any emails from Pine to you.
-
44 minutes ago, Tido said:
How many mAh does the accu have, so I can compare to a Tablet?
10,000mAh. They have the full specifications published on the website...
6 hours ago, tkaiser said:While watching the Pinebook's charging/discharging behaviour I noticed that consumption drawn from wall while charging oscillates between 9W and 15W
Can it still operate from AC power if you unplug the battery? Or is this a single power supply device like most cellphones?
Edit: according to the schematics, you should be able to disconnect the battery and still have it powered, unless I'm misunderstanding the function of the AXP803?
The only reason I ask is because it's probably easier to unplug the battery and observe the power consumption from the wall than trying to measure between the battery and the main PCB.
Or maybe there is a sysfs entry for the current out of the battery?
-
Hello, all! I got my second Zero in the mail yesterday (512MB w/2MB SPI). I also ordered the NAS board. Is there any kind of observations I can make or testing that anyone would like done?
Can you perform some benchmarks on the SATA performance? tkaiser has some interesting info about the SATA chip used, it seems like the performance will be above what USB 2.0 to SATA bridges normally offer.
Orange Pi Zero 3
in Allwinner sunxi
Posted · Edited by hmartin
I carved u-boot out of the Jammy image from Google Drive (Orangepizero3_1.0.0_ubuntu_jammy_server_linux6.1.31.7z) and applied it to the bookworm image (along with copying the dtb, as instructed) and now it's booting. I updated the GitHub issue with my test results.
I'll attach it here so that people don't have to download a 575MB image from Google Drive just to carve it (gunzip it first).
u-boot-jammy.bin.gz