belfastraven

Members
  • Content Count

    23
  • Joined

  • Last visited

About belfastraven

  • Rank
    Member

Recent Profile Visitors

577 profile views
  1. I'm not sure exactly how you got to the point of this failure, which I think is some kind of "key" problem, but to test, I just deleted my armbian-builder box, and the build directory, recloned the build directory .i.e. git clone --depth 1 https://github.com/armbian/build cd 'd into build i.e. cd build and ran ./compile.sh vagrant This worked; it created the box and downloaded all the compilers properly... It seems that the "new" compile.sh from about three weeks ago actually does a lot more for one than the old methodolgy. (I believe it will even install vagrant and virtualbox if they are not there) You will be given the option to halt the box when your particular compile is finished. I think you can then get back into it by issuing the vagrant up vagrant ssh command s from the /build/userpatches directory. I'd be happy to change the doc to match what is actually going on if I understood whether I have a correct understanding of things, myself. :-)
  2. On further investigation, it looks like changes to ./compile.sh from a couple of weeks ago will look for a vagrant installation if vagrant is specified as the first parameters to compile.sh in the build directory and try to install it (and virtualbox) if it is not installed. Since it IS already installed on my machine, vagrant was brought up and the compilation proceded successfully (I build PineH64 with Dev kernel, desktop, buster) and then end by telling one to hit enter to halt the vagrant box, but would allow no further communication with the vagrant box. (I.e., I didn't want to halt it, I wanted to use it again) The way the build worked before, once the virtual box was up and one ssh'ed into it, one could do multiple compilations, logout and ssh back in, etc. I cannot figure out how to do that now. I would be happy to submit documentation changes if I could understand how this is all supposed to work, now. I know I ran into other changes on the parameters for building a few weeks earlier too. Id also be happy to test proposed build changes and match them to the documentation if that would help...
  3. @Igor, @mother, I normally build with Vagrant, and things were working fine three weeks ago. I realize that the changes that were made two weeks ago moved some files that used to be in the "build" directory to have been moved to the "build/config/templates" directory. That is , for example, where the Vagrantfile is now. I just tried going to that directory and entering Vagrant up Vagrant ssh cd armbian ./compile.sh and the build has definitely started I am not sure whether this was the intent, that is, to have people build from the build/config/templates directory. Butdoing this right now this might solve Mother's initial issues. It looks to me like a lot of the changes made were actually for Docker, and I haven't yet had time to figure out whether the whole userpatches move has anything to do with Vagrant.
  4. 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.
  5. Hi, I'm in Maine, (Spectrum ISP) and could reach http://apt.armbian.com/dists/stretch/stretch-desktop/binary-armhf/Packages through Chrome and also built (I don't have on of these, I was just doing this a a test...my 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 apt.armbian.com end of things..
  6. 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
  7. 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...
  8. 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
  9. 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.
  10. 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.... .
  11. 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.
  12. 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.
  13. 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"; }; };
  14. 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 :-)
  15. 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...