• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map





Everything posted by belfastraven

  1. I'm running a 5.2 build (self-built using Armbian build system) on a RockPro64. I installed and used armbian-config to enable booting from SD with root on NVME. Other than adding the pcie_rockchip_host and phy_rockchip_pcie modules to the initifamfs-tool/modules file and updating initramfs, I made no major changes. Currently I'm running a disco desktop build just to play with it. The one thing I find curious (and which I also have seen before on Ayufan's images) is that it takes more that 30 seconds from getting the kernel starting message until the login prompt comes up I get no other messages on the serial interface during that time. Does anyone know why that is happening? Has anyone tried mainline u-boot for this recently? It seems that it now includes support for this board--I haven't tried it yet, myself.
  2. Hi, I'm in Maine, (Spectrum ISP) and could reach through Chrome and also built (I don't have on of these, I was just doing this a a current builds/patches are too messy) BOARD=nanopct3 BRANCH=next RELEASE=stretch BUILD_DESKTOP=yes KERNEL_ONLY=no KERNEL_CONFIGURE=no sucessfully with a Vagrant on Virtualbox build. That sure is a weird looking IP number on the " Network is unreachable message" ;-) Could this be a glitch from your ISP, or has it been happen consistently over hours or days? You'd think more poeple would run into it if it were on the end of things..
  3. I am using the dev kernel, booting from SD and having linux root on the pcie nvme , and can confirm that rockpro64 2.1 boots fine. ( I had a problem before, though, with a rock64 v2.0 not booting which I found was fixed by reverting a couple of dts changes back to the previous kernel versions (in my case 4.19). Can you tell if the system is seeing the nvme disk.? If you boot and run linux-root from an SD card , will it boot? Can you then you mount the pcie nmve? Can you see if it boots if you use the DTB from the previous version? In which case you could try comparing the dts and dtsi files to see what might have changed... I notice ** File not found /boot/dtb/rockchip/overlay/rockchip-fixup.scr ** in your log. For me, the fixup script is getting applied. I've not run any of the earlier kernels, though, so I don't know what should happen for them. I, too, am booting from the SD card, with root on the pcie nvme. FWIW
  4. If it helps anyone, I've been running succesfully with gigabit ethernet on eth0 using the dts and h6 dtsi from Icenowy's aosc-sunxi64-4.19-malimidgard-hack-2 branch and the armbian dev kernel . I force a stable mac_address by adding allow-hotplug eth0 iface eth0 inet dhcp hwaddress ether xx:xx:xx:xx:xx:xx (replace the xx's of course with a good address) in the /etc/network/interfaces file. I haven't yet been able to get spi-jedec-nor flashed to enable sdi boot, I get an error indicating that there is a mismatch between what is specified in the DTS vs the overlay, but I am booting off of an sd card with the file system on a usb connected ssd. I'm going to try to build with the mainline 5 kernel soon, to see If I can pick up the new graphics drivers... I believe version B of the device is supposed to be out soon...
  5. As I noted earlier, I had problems with usb storage not being recognzed on a rock64 after update to the 4.20 kernel. In my case on a Rock64 v2.0 , I seemed to have fixed the problem by making the following changes which are reversions to the previous 4.19 dts values. vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {############################# from 4.20, changed A2 back to D3 to make things work compatible = "regulator-fixed"; enable-active-high; gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>; usb2 { usb20_host_drv: usb20-host-drv { rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;################# from 4.20, changed A2 back to D3 to make things work My board is version 2.0 This problem did not affect other usb devices, btw, just storage... I tried to check the specs but didn't see find anything for vcc_host1_5v , vcc_otg_5v or usb20_host_drv. I did find usb_otg_drv at A2..... I noted the aobe in the pine64rock64 forum, but have had no response their yet. I am now back to booting off of a ssd on USB3 and having a usb stick and mouse/mouse keyboard on the usb2 ports-- once again, this is on a Rock64 v2.0
  6. Thanks everyone for checking on this. In my case, I have narrowed the problematic devices down to USB storage devices (all are USB3--don't have any 2's). I've tested with the samsung T1, a WD Passport HD, a Sandisk USB stick--in no cases are they recognized by the rock64 on 4.20 On a RockPro64 (3399) with the 4.20 kernel. they are all powered on and recognized when I plug them in. I notice that the uas module is not loaded on the rock64 I boot the device with one of those plugged in. I tried force loading it using initramfs, and it loads, but the device(s) is still not available. As I mentioned before, I was actually booting from the Samsung t1 on the 4.19 kernel. If any one want to see logs--I have a great number of them :-). If noone else is seeing this, though, I just keep trying to figure out what is broken. thanks again.
  7. thanks. I did try device in the bottom usb2 port and it still got no power. I'm going to try it on a powered hub to see if it is somehow a powersupply issue. I didn't notice any change in the device tree that would cause this.... .
  8. Is any one else having problems with USB3 devices on rock64 with the 4.20 kernel? U-boot seems to recognize that the device (a Samsung T1 ssd) is there but once I get the kernel starting message there is no power to the device. I can boot the that device on the 4.19-rc4 kernel.
  9. FWIW, with my working hardware module, this is where the device enumerates. /sys/bus/sdio/devices/mmc1:0001:1 wlan0 show up in that directory tree. and there is this entry in the device tree: &mmc1 { pinctrl-names = "default"; pinctrl-0 = <&mmc1_pins>; vmmc-supply = <&reg_dldo4>; vqmmc-supply = <&reg_eldo1>; mmc-pwrseq = <&wifi_pwrseq>; non-removable; bus-width = <4>; status = "okay"; }; I just compiled a dtb with the bluetooth node, and will see what else it takes to make bluetooth work. vlad59 gave a lot of helpful information in his last post, also. I know that the wifi driver and firmware were loaded automatically at boot, once the hardware module was recognized. I notice that Bluetooth enabling can be done in armbian-config, but am not sure what has to be in place for that to work.
  10. Yes, I just tried another pine64 sdio adapter and device is now working. I don't know how I managed to kill the first one.. 5.433718] r8723bs: module is from the staging directory, the quality is unknown, you have been warned. [ 5.481983] RTL8723BS: module init start [ 5.481994] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40 [ 5.481997] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40 [ 5.522202] RTL8723BS: rtw_ndev_init(wlan0) [ 5.524817] RTL8723BS: module init ret =0 [ 10.488627] rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin [ 14.397509] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = 0x00000008 [ 14.535050] RTL8723BS: start auth [ 14.537783] RTL8723BS: auth success, start assoc [ 14.548427] RTL8723BS: rtw_cfg80211_indicate_connect(wlan0) BSS not found !! [ 14.548446] RTL8723BS: assoc success [ 14.558911] RTL8723BS: send eapol packet [ 14.580272] RTL8723BS: send eapol packet [ 14.618036] RTL8723BS: set pairwise key camid:4, addr:92:3b:ad:ad:a7:34, kid:0, type:AES [ 14.618588] RTL8723BS: set group key camid:5, addr:92:3b:ad:ad:a7:34, kid:1, type:AES I haven't checked bluetooth yet. It isn't defined in the megous linux DTS, but from Anarsouls-- Defined here in Anarsouls DTS /* On Wifi/BT connector, with RTS/CTS */ &uart1 { pinctrl-names = "default"; pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; status = "okay"; bluetooth { compatible = "realtek,rtl8723bs-bt"; reset-gpios = <&r_pio 0 4 GPIO_ACTIVE_LOW>; /* PL4 */ device-wake-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */ host-wake-gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */ firmware-postfix = "pine64"; }; };
  11. Yes--and there isn't an overlay for it either. I'm looking around to see if I can find a dt somewhere which has a node for it... I'm very new to dt's :-)
  12. Re Pine64 WiFi. Using a USB Wifi adapter, WiFi is fine. The Wifi/bluetooth module told by Piine64 is not working. I can load the driver, but the SDIO device is not being enumerated. Still looking into the issue...
  13. Pine64+ is booting fine, Ethernet (wired isfine), still working investigating getting wireless (r8723bs) to work. Not sure about HDMI yet.
  14. Have been testing on a pineh64. kernel and uboot seem to be fine, but something is wrong with the device tree-- The original armbian build (the 4.18 rc7-(-from icenowy, I believe--booted), but no updates after that worked. I recompiled her tree from her 86-integrate-2-ugly branch and am booting fine (both from sd and eemc) I originally noticed a complaint about the simplefb node not being found, but after adding that node, I still got the same kernel oops. Before that oops, the boot logs look the same.... I'm hoping someone can see what is wrong. I'm afraid I'm really out of my element here. console_pine64h6.txt
  15. I have not tried this with an armbiasn build, but am successfull using Ayufan's from a Samsung portable SSD attached via USB3 port, I had to use SPI flash for u-boot and enable a rootdelay (I am using 90 right now which is much longer than it needs to be) That would be one of the bootargs in the boot.cmd file, I would think. Not sure if can be added from armbianEnv.txt I know that rootwait is already one of the boot args, but I think that perhaps that rootdelay is perhaps called at a different point in startup. FWIW
  16. OK--I found a post in another thread from zador.blood.stained. which explains that the ftdname will now have allwinner/prepended to it .. So probably the best fix is to edit the boot.cmd file to remove the allwinner/ from the load command, and then recompile boot.cmd. This works for me. It seems that boot.cmd hasn't been getting updated since that change was made.
  17. Sorry--I didn't see this before I posted. I believe there is a bad definition somewhere of ftdfile (see my post on this same subject see this line File not found /boot/dtb/allwinner/allwinner/sun50i-a64-pine64-plus.dtb * with duplicate of Allwinner? look at the load line from the boot.cmd. I could not find where ftdfile was defined I got the system to boot by copying the allwinner directory into itself-- that way load will find the files (and overlays if they are being used)
  18. I have a feeling this was caused by a p[roblem with the definition of ftdfile variable: line from boot.cmd: load ${devtype} 0 ${fdt_addr_r} ${prefix}dtb/allwinner/${fdtfile} from the serial output: File not found /boot/dtb/allwinner/allwinner/sun50i-a64-pine64-plus.dtb ** note the duplication of Allwinner. Since I couldn't find where it was defined , I just copied the allwinner directory into itself.....:-) which fixed the problem. Perhaps someone could look into this? thanks.
  19. Newby question: should I put an apt-mark hold on u-boot after flashing over it? Main Line kernel is booting fine now but apt-get upgrade shows an upgrade for u-boot. I wasn't sure whether or not that was a fix or still the broken one. IS there a repository I should be monitoring for the fix? thanks.