Jump to content

hmartin

Members
  • Posts

    67
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2966 profile views
  1. 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
  2. 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.
  3. @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.
  4. 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.
  5. 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.
  6. 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) 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.
  7. 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 directory Looking 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): I'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?
  8. 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.
  9. 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...
  10. 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"
  11. 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: kwboot-x86_64.gz kwboot.patch
  12. 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... 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.
  13. 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?
  14. 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). 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. 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. 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.
  15. "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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines