piter75

  • Content Count

    287
  • Joined

  • Last visited

Reputation Activity

  1. Like
    piter75 reacted to Igor in Armbian v20.05 (Kagu) Planning Thread   
    For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
     
    Thank you all for attending the meeting!
  2. Like
    piter75 reacted to magixx256 in Orange pi 4   
    So initially I had some trouble booting the Armbian images even the one I built locally.
    I'm certain this was because I had not properly wiped the MicroSD card after trying out the images from Orange Pi (I ended up using gparted to create an new msdos partition table) .
    Anyway I got around to testing some of the images and though I'd post the state of those as well:
     
    1. Armbian_19.11.9_Orangepi4_buster_current_5.4.16_minimal.img
    This was the image found here on Page 3 posted by @piter75
    It seemed to boot fine. eth0 and WLAN exist but I did not get connectivity (this was an issue with my router)
    https://asciinema.org/a/313413
    2. Armbian_20.02.6_Orangepi4_bionic_current_5.4.27_minimal.img
    Downloaded from https://www.armbian.com/orange-pi-4/#kernels-archive-all
    Some issues seen during booting, but eventually it boots.
    eth0 and WLAN exist but I did not get connectivity due to my router
    https://asciinema.org/a/313424
    3. Armbian_20.05.0-trunk_Orangepi4_bionic_current_5.4.27_minimal.img
    Image built locally using the docker guide.
    Kernel seems to take a bit longer to boot and there is no output from it as before.
    eth0 and WLAN exist, after messing with router eth0 works as expected.
    https://asciinema.org/a/313427
    Image available at https://mega.nz/#!jgZmzAzb!yp-g2viNrXAjO-rpM_25meDVBNSxOo2I8gOqD6t-p7g
    4. Armbian_20.05.0-trunk_Orangepi4_bionic_dev_5.5.13_minimal.img
    Image built locally using the docker guide.
    Kernel seems to take a bit longer to boot and there is no output from it as before.
    eth0 and WLAN exist, after messing with router eth0 works as expected.
    https://asciinema.org/a/313445
    Image available at https://mega.nz/#!LpIinS5I!MzscJ_tS5S4_5pcxpz5CZXKUeFxf3LdeE8IBIfORl-A

    All images flashed with Etcher
    MicroSD was Samsung Evo Select 64GB
    Board was OrangePi 4 4GB v1.3 without eMMC (cheapest config for this RAM)
    PSU was the USB barrel connector to a known good phone charger.
     
    I also tried out the mPCIe adapter with a mPCIe SATA card (ASM1061). The speeds were disappointing at max 210mb/s considering the card can definitely do 350mb/s+ in my laptop.
    I had hoped the newest os/kernel version would solve this, but it does not appear to do so. Maybe my testing methodology is wrong but I am doubting this after trying 2 different cards and multiple OSs.
    Another thing to note is that this board runs hot at ~75*C even with a small heatsink (no fan was used) and little going on.
     
    If anyone has something they'd like me to try then please ask.
  3. Like
    piter75 got a reaction from manuti in Rock Pi S, RK3308 CPU, is it supported by anything?   
    Unfortunately... yes. I did not test the upgrade path with latest changes
     
    At this point, if you can discard your install, you can download latest image (v20.02.06 / v4.4.217).
    If you want to recover your install you need to mount the SD in some other PC or SBC and modify "boot/armbianEnv.txt" as follows:
    add line overlays=uart0 change overlay_prefix line to overlay_prefix=rk3308 I will be more careful next time...
     
    As for the Radxa repos I don't use them.
  4. Like
    piter75 reacted to Igor in Added Nanopi R2S   
    + updates to: rockpis, rockchip64 and odroidxu4 legacy kernel
  5. Like
    piter75 got a reaction from gounthar in Orange pi 4   
    Do you happen to be using the same SD card that you used previously for Xunlong's BSP?
    If so this is a known issue: 
     
  6. Like
    piter75 got a reaction from aaditya in Potential OPP issue with NanoPi M4V2   
    We could do that but I am pretty sure, although of course may be wrong ;p, that it's not a CPU frequency issue.
     
    What I observed so far is that most of the time when I cold boot the board I see following lines at the end of DDR training in Rockchip's binary:
    change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 0, cs 1, advanced training done channel 1, cs 0, advanced training done channel 1, cs 1, advanced training done channel 1, cs 0, dq 31 RISK!!! TdiVW_total violate spec channel 1, cs 1, dq 31 RISK!!! TdiVW_total violate spec ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 Those "dq 31 RISK!!! TdiVW_total violate spec" lines do not look promising.
    OTOH most of the times when I reboot the board after some time I do not see those lines which may mean that memory chips used in M4V2 require a bit different params.
    As a piece of additional info, I also tried to use u-boot's TPL to train LPDDR4 in v2020.01 and although it works well for RockPi 4, RockPro64 and ROC-RK3399-PC it ends up with a kernel crash on 100% of boots with M4V2
  7. Like
    piter75 got a reaction from aaditya in Potential OPP issue with NanoPi M4V2   
    I don't know the reason for the decision to do it, as it predates the beginning of my usage of Armbian, but I tend to agree that we should play safe by default.
     
    I did not have any issues with it on my boards so I did not pursue to change it but...
    When I was suspecting CPU issues with M4V2 I created the changes to disable the overclocking but also to make it easy to overclock with the overlay if one wanted to experiment:
    https://github.com/armbian/build/compare/rk3399-disable-overclocking
     
    It did not fix the M4V2 mainline issues but I think we can reconsider the default behaviour anyway.
  8. Like
    piter75 got a reaction from aaditya in Armbian images do not boot on RockPi4a (with workaround)   
    The reason for this patch to exist is that it is difficult to remove / insert the eMMC module of RockPi 4 while installed with large heatsink and in general I think that SD should take precedence over eMMC in our tinkerers' world ;-)
    Nonetheless I think your use case is valid and it would be great to have a solution that switches to SD only if it is actually bootable. It would then satisfy both cases.
  9. Like
    piter75 got a reaction from aaditya in Armbian images do not boot on RockPi4a (with workaround)   
    Wanted to be sure of that. It was not that long ago that we were chasing issues with OrangePi 4 not booting from Armbian with SD that had Xunlong's BSP image on that card before (because of secondary GPT) ;-)
     
    Now it looks more clear and a bit unfortunate... ;-)
    U-Boot 2017.09-02676-g4490220395 (Jul 01 2019 - 07:49:56 +0000) The u-boot image is pretty ancient:
    g4490220395 => https://github.com/radxa/u-boot/commit/44902203959cef9d92dff2f36896c7ec27fb3d88
    in next commit Radxa added DOS partition support to it => https://github.com/radxa/u-boot/commit/59412e4610af669538a057995ed2d418703723a2
    I have a later g674eaa57f0 in SPI and it boots Armbian fine  => https://github.com/radxa/u-boot/commit/674eaa57f03d48aa1803650a901f0244563eea60
    Full history here: https://github.com/radxa/u-boot/commits/rk3399-pie-gms-express-baseline
     
    Now the positive stuff...
    @raidboy to boot Armbian images without creating GPT on them you can simply connect pin 23 with 25 (or any other GND/black) pin on GPIO header. This disables onboard SPI.
    To erase the SPI you could use this guide: https://wiki.radxa.com/Rockpi4/dev/spi-install#Erase_images_on_SPI_device.
    Writing zeroes with dd to /dev/mtdblock0 while being booted with Radxa's image should also do the trick ;-)
  10. Like
    piter75 got a reaction from TRS-80 in Armbian images do not boot on RockPi4a (with workaround)   
    Wanted to be sure of that. It was not that long ago that we were chasing issues with OrangePi 4 not booting from Armbian with SD that had Xunlong's BSP image on that card before (because of secondary GPT) ;-)
     
    Now it looks more clear and a bit unfortunate... ;-)
    U-Boot 2017.09-02676-g4490220395 (Jul 01 2019 - 07:49:56 +0000) The u-boot image is pretty ancient:
    g4490220395 => https://github.com/radxa/u-boot/commit/44902203959cef9d92dff2f36896c7ec27fb3d88
    in next commit Radxa added DOS partition support to it => https://github.com/radxa/u-boot/commit/59412e4610af669538a057995ed2d418703723a2
    I have a later g674eaa57f0 in SPI and it boots Armbian fine  => https://github.com/radxa/u-boot/commit/674eaa57f03d48aa1803650a901f0244563eea60
    Full history here: https://github.com/radxa/u-boot/commits/rk3399-pie-gms-express-baseline
     
    Now the positive stuff...
    @raidboy to boot Armbian images without creating GPT on them you can simply connect pin 23 with 25 (or any other GND/black) pin on GPIO header. This disables onboard SPI.
    To erase the SPI you could use this guide: https://wiki.radxa.com/Rockpi4/dev/spi-install#Erase_images_on_SPI_device.
    Writing zeroes with dd to /dev/mtdblock0 while being booted with Radxa's image should also do the trick ;-)
  11. Like
    piter75 got a reaction from Neko May in Potential OPP issue with NanoPi M4V2   
    I don't know the reason for the decision to do it, as it predates the beginning of my usage of Armbian, but I tend to agree that we should play safe by default.
     
    I did not have any issues with it on my boards so I did not pursue to change it but...
    When I was suspecting CPU issues with M4V2 I created the changes to disable the overclocking but also to make it easy to overclock with the overlay if one wanted to experiment:
    https://github.com/armbian/build/compare/rk3399-disable-overclocking
     
    It did not fix the M4V2 mainline issues but I think we can reconsider the default behaviour anyway.
  12. Like
    piter75 got a reaction from aaditya in rk3399-bluetooth.service is still present in "systemctl list-jobs"   
    I would add the mentioned options to kernel config, built the kernel, copied resulting ".config" file over "linux-rockchip64-current.config" and then commit it.
    It would be great to do the same with "dev" kernel (which is now 5.5.y in Armbian's master) in the same PR for feature parity  
  13. Like
    piter75 reacted to chwe in rk3399-bluetooth.service is still present in "systemctl list-jobs"   
    IMO the easiest way is ./compile.sh KERNEL_CONFIGURE=yes make your changes when menuconfig pops up and you get your new config in output/config after compilation. It's even named the way it should be..
  14. Like
    piter75 got a reaction from aaditya in rk3399-bluetooth.service is still present in "systemctl list-jobs"   
    I didn't have time and enough interest in Bluetooth to pursue a solution but one thing I have noticed with 5.x kernels on all rk3399 boards I own is that Bluetooth's firmware is correctly patched after cold boot / power on but not after a reboot.
  15. Like
    piter75 got a reaction from Jack953 in Orange pi 4   
    @_ppiotr3k Did you by any chance use the same SD card for Armbian that was used for Xunlong image before?
     
    If so, try wiping either all of the SD card (it will take a long time) or the last 33 sectors of it before writing Armbian's image there.
    This will clear the recovery GPT partition table from the end of SD card.
    This partition table makes Rockchip's loader trying to use GPT layout for booting - which we don't use. 
    root@xyz:~# fdisk -l /dev/mmcblk1 | head -1 Disk /dev/mmcblk1: 29.7 GiB, 31914983424 bytes, 62333952 sectors # 62333952 - 33 = 62333919 root@xyz:~# dd if=/dev/zero of=/dev/mmcblk1 seek=62333919 I think a better solution is to switch u-boot's preloader to SPL/TPL from DDR/miniloader but I want to test how it behaves with Xunlong's original image in eMMC.
    The precompiled buster minimal image (kernel 5.4.16), which does not require above steps, is here: https://drive.google.com/open?id=1ScMJN0VLIkuPjgnqhudK0egH42_cP1w3
  16. Like
    piter75 got a reaction from manuti in Rock Pi S, RK3308 CPU, is it supported by anything?   
    Eventually I would like to end up with a tag from linux stable repo (even if it is -rcX) and a series of patches but it is more flexible to start with a custom repo now.
  17. Like
    piter75 got a reaction from ashthespy in Rock Pi S, RK3308 CPU, is it supported by anything?   
    Eventually I would like to end up with a tag from linux stable repo (even if it is -rcX) and a series of patches but it is more flexible to start with a custom repo now.
  18. Like
    piter75 reacted to ashthespy in Rock Pi S, RK3308 CPU, is it supported by anything?   
    @piter75 I have been playing around with mainline and the RockPiS (https://github.com/ashthespy/linux-rockchip/commits/rk3308-rockpis)
    Have a booting board with the wired networking and console. Rest of it is quite sketchy.
    Edit: opened up a PR so more people can play with it - https://github.com/armbian/build/pull/1773
    Suggestions are welcome, as my experience with kernel stuff is quite low and I am learning as I go..
  19. Like
    piter75 got a reaction from manuti in [RK3308] Rock Pi S 256   
    I never tested it with 256M as I only have 512M units.
     
    It should be fixed in this branch: https://github.com/armbian/build/tree/rockpis-fix-256m-boot.
    If you can build the image yourself then try it - otherwise it should make it into Armbian 20.02 release.
  20. Like
    piter75 got a reaction from manuti in Rock Pi S, RK3308 CPU, is it supported by anything?   
    Well, the overlays actually work in this kernel 😜
     
    It's just that they need to be Armbian style and not Radxa's so overlays for waveshare LCDs need to be named "rockchip-*.dtb, placed in /boot/dtb/rockchip/overlays folder and referenced in /boot/armbianEnv.txt's overlays stanza.
     
    Dynamic overlays are not supported.
  21. Like
    piter75 got a reaction from Jack953 in Orange pi 4   
    I did only test HDMI output in current (5.4.14) and it worked there. I must get myself a desktop monitor to test GUI more often ;p
     
    I am glad it boots for you to the point where you can log in. At least now it is not only me who can boot it.
  22. Like
    piter75 got a reaction from Jack953 in Orange pi 4   
    @Jack953 try beta images for OrangePi 4 instead . They are available in the download area: https://dl.armbian.com/orangepi4/archive/. 
     
    I used buster for my preliminary support testing.
    Keep in mind that the board support is in beta or even alpha state right now.
  23. Like
    piter75 got a reaction from gounthar in Orange pi 4   
    @Jack953 try beta images for OrangePi 4 instead . They are available in the download area: https://dl.armbian.com/orangepi4/archive/. 
     
    I used buster for my preliminary support testing.
    Keep in mind that the board support is in beta or even alpha state right now.
  24. Like
    piter75 got a reaction from manuti in Rock Pi S, RK3308 CPU, is it supported by anything?   
    I did not test it with LCD but... looking at the last post in the discussion you linked one cannot expect it to display cli on LCD without programming it themselves as it is using SPI and not the DSI interface.
  25. Like
    piter75 reacted to chwe in Armbian 20.02 (Chiru) Release Thread   
    well you've no chance I already set up the pinebook in rk3399 with u-boot 2020:
     
    U-Boot 2020.01-armbian (Jan 21 2020 - 23:08:47 +0100) Model: Pine64 Pinebook Pro DRAM: 3.9 GiB PMIC: RK808 MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Pine64 Pinebook Pro ## Error: Can't overwrite "serial#" ## Error inserting "serial#" variable, errno=1 rockchip_dnl_key_pressed: adc_channel_single_shot fail! Net: No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 2940 bytes read in 6 ms (478.5 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 143 bytes read in 6 ms (22.5 KiB/s) 7118384 bytes read in 752 ms (9 MiB/s) 20722176 bytes read in 2178 ms (9.1 MiB/s) 72693 bytes read in 17 ms (4.1 MiB/s) 2698 bytes read in 9 ms (292 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 7118320 Bytes = 6.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f5853000, end f5f1cdf0 ... OK Loading Device Tree to 00000000f57d8000, end 00000000f5852fff ... OK Starting kernel ... [ 2.647157] Internal error: Oops: 96000004 [#1] PREEMPT SMP  
    it seems it doesn't like my new DT.. but u-boot works fine and blobfree..