All Activity

This stream auto-updates     

  1. Past hour
  2. I would check the schematics of the BPi W2 (assuming that those boards are more or less reference design at this part).. Maybe check CS pin during boot? or soldering a logic analyzer to sniff?
  3. My box also comes without SPI. Can you try minicom? Is it available on mac? You should first press and hold both keys (you should see your USB-serial TX LED blinking quicky) and while holding, connevt power to your box.
  4. Yes, I see. I tried „screen“ and „miniterm“ on macos and „hypertrm“ (the recommended one from bananapi) on win10. I think @jeanrhum also tried it without success, but I do not know, which terminal he used. I think that this d/g/r-thingie os part of the soc-firmware too, but it might be possible, that a compatible SPI-chip is needed or (additional) a resistor or something has to be added or removed, before the SOC decides to launch this prompt. Keep in mind, that the Lake1 (and some other boxes) do not have a SPI-chip when they leave the factory. They only have the unpopulated connector and maybe there is a missing secret sauce. Anyway, I already have my bricked box prepared and it will get the x-ray-treatment tomorrow (if I do not forget it ). BTW, I wonder what the box expects to find on the usb device at the stage of „uu3-1“?
  5. next, default -> 4.14.127 dev -> 5.1.15 apt update & apt upgrade
  6. Today
  7. I see now that I gave you wrong instructions, sorry. Uploads for packages that are common to all go to "debs" and script redistribute / link across all different variants. Only distribution specific packages goes into sub dirs ... tree is the same as in build script, which is also behind handling this. I also forgot to mention that it would be best to compile from "cosmetics" branch where a few bugs has been fixed. I'll fix this in next hour. Any input here to help merging or closing is valuable: https://github.com/armbian/build/pulls https://github.com/armbian/build/issues
  8. @Staars, just because of you I did a test. I removed SPI flash and wiped first 4megs by writing zeroes: $ sudo dd if=/dev/zero of=/dev/sdc bs=1M count=4 4+0 records in 4+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.686883 s, 6.1 MB/s result: C1:80000000 C2 ? C3hswitch frequency to 0x00000046 frequency divider is 0x00000080 switch frequency to 0x00000046 frequency divider is 0x00000004 switch to SDR 8 bit switch bus width to 0x00000008 bits success 0000001� C1:80000000 C2 ?uu3-1 but when I hold Ctrl+q while booting: C1:80000000 C2 ? d/g/r> d/g/r> d/g/r> d/g/r> d/g/r> d/g/r> d/g/r> So I am 99% sure d/g/r works regardless on what you have on you emmc, if you have SPI or whatever. I believe this is firmware inside of the SoC. What terminal are you using?
  9. Yes I can flash, no I can‘t boot. No, I can‘t reach d/g/r using ctrl+q.
  10. I'm trying to get a smaller LCD working on my Win Plus (again, I had it before but was on Jessie I think, old at least). You need to use the BCM numbers from gpio readall and map to the physical pins the seller usually gives. For example my screen use pin 18 and 22 for DC and reset, so they map to 68 and 230 for Win Plus (but now I get SPI timing out, at least the pins do "mount" now, when I was trying BCM values for the Lite it's running on - 71 and 2 - I got an error on pins). (These pinouts used in /etc/modprobe.d/fbtft.conf). Sorry for bit confused reply, hope it helps. -- Edit: I was following the same guide you sent also (and all others I could find, plus the older ones I used before) so I guess you took the same steps - After raising max frequency - /boot/armbianEnv.txt -> param_spidev_max_freq=16000000 - (I dont think I changed anything else at least) I got rid of errors from dmesg but the screen is still blank (white) on Win. Edit2: Tried on another sd card (strectch, earlier was on a bionic build), now I again get the same error, SPI timing out and max_freq didnt help this time. Checking what other settings I could have messed with but I'm pretty sure only other thing I changed was the framebuffer used from 8 to 0 or back.
  11. Thanks again! I have created a PR: https://github.com/armbian/upload/pull/3 The kernel sources can be downloaded from dropbox: https://www.dropbox.com/s/znd7lnqxf937qtj/linux-source-default-odroidxu4_5.89_all.deb?dl=0 https://www.dropbox.com/s/7oh7idf6rvexjum/linux-source-next-odroidxu4_5.89_all.deb?dl=0 Let me know if this is how you expected to get the update. Also, if there are any other packages which would benefit from a simple version sync, please feel free to let me know.
  12. So you can flash from the windows utility but the box still doesn't boot, right? Can you reach d/g/r from terminal using Ctrl+q?
  13. I really hope you are right and will gladly change my opinion. In this post: ... you see the bootlog of the bricked box after flashing an Android image (OTP verification) including my incorrect assumption about ‚uu3‘. On the bricked box I can not reach any prompt. It is just the flashing procedure with the windows tools, that works without an error message.
  14. I'm having exactly the same problem as MartyPG13. Mine arrived yesterday and I'm using an image meant for La Potato which is meant to work.
  15. Hi, yes, you can see the boot process from serial. you can follow the instruction in our wiki. After the serial terminal ready, you can press the reset button to see the boot process since very beginning. You should see something like: U-Boot SPL 2018.11-armbian (Jan 20 2019 - 20:02:45 -0800) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 6 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 6 | SATA1 | | 3 | 6 | SATA3 | | 4 | 6 | SATA2 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: mv_ddr-armada-17.10.4 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR3 Training Sequence - End scrubbing mv_ddr: completed successfully Trying to boot from MMC1 U-Boot 2018.11-armbian (Jan 20 2019 - 20:02:45 -0800) SoC: MV88F6828-A0 at 1600 MHz DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled) MMC: mv_sdh: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment Model: Helios4 Board: Helios4 SCSI: MVEBU SATA INIT Target spinup took 0 ms. SATA link 1 timeout. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Net: Warning: ethernet@70000 (eth1) using random MAC address - 52:fc:90:b3:be:70 eth1: ethernet@70000 Hit any key to stop autoboot: 3 2 1 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 1979 bytes read in 104 ms (18.6 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 220 bytes read in 86 ms (2 KiB/s) 19717 bytes read in 353 ms (53.7 KiB/s) 4714605 bytes read in 852 ms (5.3 MiB/s) 5460016 bytes read in 1037 ms (5 MiB/s) ## Loading init Ramdisk from Legacy Image at 02880000 ... Image Name: uInitrd Created: 2019-02-07 11:42:01 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4714541 Bytes = 4.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Using Device Tree in place at 02040000, end 02047d04 Starting kernel ... But i think you won't see that screen. LED8 near power inlet indicate the input voltage, if it's blink (nothing fancy here, just LED connected to 12V) then it's a hardware problem. most probably the power adapter.
  16. Does grepping your kernel log for "NIC Link is" reveal an unusual number of entries? I experienced odd behaviour when connecting to/through a FritzBox (using multiple devices over Ethernet) a while back. When devices connected to any port set to "Green Mode" the link would seem to drop frequently when idle. The link would come up again when traffic arrived at either end, but a bunch of security protocols timed-out in the process and some applications failed in strange ways. Saturating the link would result in a transfer stall followed by the link going down and then coming back up in 100Mbps mode. Continued saturation would even cause it to go down and come back up at 10Mbps... but at that point data transfer stopped. Software resetting of the link failed to restore it to 1Gbps — it required the power cycling of either the FritzBox or the device. For some utterly unfathomable reason, the link was least stable on Port 4. Port 3 was half as unstable. Port 2 was about 1/10th as unstable. Port 1 was completely stable. However, since all local traffic had to use at least two LAN ports I ended up with instability regardless of whether I was on the sending or receiving end. Forcing all four LAN ports into "Power Mode" — regardless of whether they needed to be there or not — solved the problem.
  17. @imikei Youve not mentioned which box you have.... However I think you may end up needing to reset it back to factory (if its not even booting to the internal Android OS anymore), so Booting Problems section of this post. Once thats done, if youre sure your using the correct DTB for your box, Id suggest trying an earlier build of Armbian or one with a different kernel version to see if that gets you working. Im guessing you mean username/password at the initial text screen where you log in as root and change the passwords etc.
  18. @balbes150 Is there any existing scripting to make u-boot/kernel/image or it has to be make?
  19. looks promising. Surprised that they included dual display output. I wonder what the Performence of the videocore VI will be like.
  20. Armbian does that for you. Don't worry about
  21. Thanks for the answer. I am quite new to this. Forgive one more clarification, with this disconnection will the recording go straight to my hdd or will the recording go through the SD card and then to hdd? I ask this because I wanted to extend the life of the SD card.
  22. I'm convinced this is not true and I can prove it later. I think this is also not true. What do you mean by this? Does the box boot? My idea how to save your box: 1. extract hwconfig and uboot from the dump I asked for and a bootlog (it shows blob locations) 2. boot these using d/g/r into u-boot 3. reflash full emmc dump from working box to not working one within u-boot or recovery linux
  23. If I convert DTB to DTS (and back) and add this: /* There's the BT part of the AP6256 connected to that UART */ &uart1 { pinctrl-names = "default"; pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; uart-has-rtscts; status = "okay"; bluetooth { compatible = "brcm,bcm4345c5"; clocks = <&rtc 1>; clock-names = "lpo"; device-wakeup-gpios = <&r_pio 1 2 GPIO_ACTIVE_HIGH>; /* PM2 */ host-wakeup-gpios = <&r_pio 1 1 GPIO_ACTIVE_HIGH>; /* PM1 */ shutdown-gpios = <&r_pio 1 4 GPIO_ACTIVE_HIGH>; /* PM4 */ max-speed = <1500000>; }; }; And copy https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256 to: /lib/firmware/brcm/(BCM4345C5.hcd) Am I correct that it will it work then? (I'm using a OPi3)
  24. Yes, I have two now. Some posts ago I shortly described, how I bricked the first one. d/g/r needs SPI-flash, which is not populated on the Lake1. The first try, to solder a chip went wrong (probably incompatible chip, maybe a defective one or bad soldering). Now I wait for some weeks for the arrival of new chips (the one I got told from chwe), but somehow it takes a very long time. I think, that your soldering trick will not work with my box. I can flash all sorts of firmware without a problem, but the box complains about an encyption error early in the boot process. That’s why I believe, that a pure emmc-boot is impossible forever on that box. I could send you the data, but I would not recommend it. As long as we are not totally shure, what happens with cross flashing and the SPI-path is not working, it might lead to a bricked box. AFAIK the zidoo boxes are exceptions with their firmware with more unencrypted parts, means I would especially not cross flash a zidoo box (unless you find a believable report, that this works). BTW, technically you can simply flash the (easy to find) lake-firmware on your box with the realtek utility, but again: I DO NOT RECOMMEND THIS BASED ON MY CURRENT KNOWLEDGE.
  25. To all user space variants: Stretch, Buster, Bionic, Disco, ... Yes, that is optional - its updated upon manual intervention only. Not needed. Memory is used optimally by default if you have it enough ... FORCE_USE_RAMDISK="yes" switch might help.
  1. Load more activity