Jump to content

skandalfo

Members
  • Posts

    16
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I bought a V5 (IIRC) EspressoBIN with exactly this purpose in mind, but eventually I gave up. The board specs look good on paper, but the hardware ends up being marginal: USB works sometimes in one port but not the other (e.g. the Bluetooth USB part of a miniPCIE WiFi card not working). The miniPCIE support seems to have restricted compatibility (needs some patches to restrict the advertised/used PCI gen IIRC). The power circuitry seems to be a joke (seriously why didn't they remove the non functional attempt at powering the board via microUSB in later revisions?), including the reverse gender Molex connector for SATA power (apparently fixed in V7). They changed the SPI flash at random with no notice a number of times (leading to half bricked boards once their unreleased bootloader was overwritten) just for the lulz. Then add apparent stability issues when the kernel was fixed to actually run the board at the advertised speeds. My verdict is that the hardware design is probably too complicated to work reliably. What actually made me give up was finally the IO weirdness. Given that the SoC is a 1.8V part, adding any peripheral would require level shifting to more usual 3.3V levels. But then... The SPI HW can't run at speeds below 80 MHz, so no interfacing to cheap SPI LCD screens for the status display, even if I somehow managed to find level shifters working at that speed. And no PWM for fan control either: while the SoC seems to have some PWM channels, the kernel support doesn't export them. All in all, I put a significant amount of time on this one, but sadly I eventually decided it wasn't worth it. I don't like sounding so negative, but the truth is I can't recommend this product at all based on my experience. At this point I would probably bet on the Helios64 promise instead, if I hadn't already gotten an X86-64 based mini itx NAS.
  2. Modern kernels have likely switched the driver of the topaz switch to a switchdev based driver. The idea is that you set up a bridge interface (br0) over the individual port interfaces and the kernel infrastructure takes care of setting up the offloading of the switching to the hardware. My EspressoBIN is not on right now, but IIRC the default setup was for br0 to be automatically set up on boot (not really sure about that).
  3. This looks like you are using (recovery) images that haven't been patched for supporting the Macronix flash chips. Did you check this thread?
  4. Yeah, I also got versions/dates like the ones here after I successfully flashed via UART download + bubt: TIM-1.0 WTMI-devel-18.07.0-6050fd5 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.155V NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):711ecd3 (Marvell-armada-18.09.4) NOTICE: BL1: Built : 15:13:47, Sep 7 2018 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):711ecd3 (Marvell-armada-18.09.4) NOTICE: BL2: Built : 15:13:50, Sep 7 2018 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.5(release):711ecd3 (Marvell-armada-18.09.4) NOTICE: BL31: Built : 15:1 U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 1000 [MHz] L2 1000 [MHz] NB AXI 250 [MHz] SB AXI 250 [MHz] DDR 800 [MHz] DRAM: 2 GiB U-Boot DT blob at : 000000007f7142d8 Comphy chip #0: Comphy-0: USB3 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link up MMC: sdhci@d0000: 0 SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 Marvell>>
  5. That's what I tested, but to be completely sure I'll check the test logs I published in the other thread to make sure the printed build date got updated. If the flashed file turns out to be Armbian's, my only theory is that the factory bootloader recognises the Macronix chip but somehow fails to update its contents (so that the factory bootloader remains unchanged). That could be fixed by reflashing from an UART-downloaded image.
  6. So, I just checked that I could use the images in this folder to flash the current ones in its grand-parent one, and that I still was able to boot from the Armbian already installed in my SD card with a Macronix chip. Thanks a lot for these fixed images! Steps: Had to use miniterm: miniterm --eol CR /dev/ttyUSB0 115200 rather than minicom. Minicom would interfere with the transfer from WtpDownload by trying to reopen the serial port once it had lost it; and then WtpDownload_linux would get interrupted. Set the jumpers for UART recovery and powered the board. In miniterm I hit enter until I got the E prompt, then entered "wtp". Then I ran the upload: <path>/<to>/WtpDownload_linux -P UART -C 0 -R 115200 -B TIM_ATF.bin -I wtmi_h.bin -I boot-image_h.bin -E As my bootable SD card was in, the just-downloaded bootloader in RAM would quickly go and start Linux from the SD card. If your EspressoBIN is borked, you probably should just remove any boot device. In my case I didn't bother; I just restarted miniterm quickly after WtpDownload had finished and pressed enter a number of times to interrupt the boot sequence. I plugged in a USB stick with flash-image-2g-2cs-1000_800.bin in it. I flashed it to SPI: Marvell>> bubt flash-image-2g-2cs-1000_800.bin spi usb Burning U-BOOT image "flash-image-2g-2cs-1000_800.bin" from "usb" to "spi" USB0: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found reading flash-image-2g-2cs-1000_800.bin Image checksum...OK! SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB Updating, 8% 126859 B/s Updating, 16% 127704 B/s Updating, 31% 167458 B/s Updating, 39% 155994 B/s 262144 bytes written, 593344 bytes skipped in 2.249s, speed 389342 B/s Done! I then powered the board off, switched the boot jumpers back to their default position, and powered it on again. The board booted Armbian from SD card as usual.
  7. Not enough. The recovery image is loaded to RAM only, so when you reset it goes away and you boot again from a borked image once jumpers are back to normal. What you need to do is use the image in RAM you just booted from to flash a good one to SPI. After WtpDownload finishes, going back to the serial terminal and pressing enter a couple of times should give you a working uboot prompt (with your UART image that now can write to your flash). From there you should be able to use the bubt command like explained here, or some other of the commands in that page to make your changes permanent.
  8. Here are my patches (which also depend on CONFIG_LEDS_GPIO=y being set in the kernel config). I finally set the compatible string for the SPI flash to a generic type to allow the chip type to be probed. espressobin_gpio_led_and_spi_flash_fixes.patch
  9. Realized that. I managed to build a patched kernel/DT combination including: Patched spi-nor.c to recognize the new Macronix chip. Patched DT to set the SPI flash partitions to the locations I found 18.09 uboot is using (environment is in the final 64kB of the 4MB chip), and set state to okay. Added support for GPIO LEDs to the kernel config. Added a GPIO LED entry to DT so that the onboard red LED is accessible through sysfs. Now the LED, /proc/mtd and fw_printenv are working as expected. I only get a complaint at boot time when the SPI flash is probed that a Macronix chip has been found rather than a Winbond one. Maybe adding more "compatible" entries there will be enough to fix that. If anyone's interested in these changes, let me know.
  10. Uhm... it looks like the Linux kernel doesn't support c2, 25, 36 for mx25u3235f either: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/spi-nor/spi-nor.c#n1088 and because of that /proc/mtd shows empty after boot...
  11. Yay! I can confirm at least the new 18.09 flash-image-2g-2cs-1000_800_boot_sd_and_usb.bin works in my board.
  12. What do you mean with "doesn't work"? Ihad issues with the upload via minicom (it seemed to do something with the serial port that would make the serial transfer) and had to switch to miniterm.py and set line breaks to just LF before I got wtp activation and serial download to be stable. Is that what's failing for you?
  13. And, yes, I used the toolchain from here, as suggested by the build instructions, on Ubuntu 18.04.
  14. @FoodGenius I was trying to explain that I ended up in the same situation as you (couldn't get anything flashed because everything I loaded didn't support the Macronix mx25u3235f flash chip). I bricked my board by flashing the "wrong speed one" from Armbian. I could not boot to uboot because it wouldn't pass calibration (wrong CPU/DRAM speed). So I tried to recover via UART using these instructions, and the binary bootloader images here. I managed to upload the binary bootloader to RAM, but it would not be able to flash SPI from USB with anything else because, as you realized, only the version that came pre-flashed knew about the new flash chip. So I got to these other instructions to compile the bootloader from source. Notice the section that explains that the build also includes the UART recovery images. I managed to build them and upload via UART, and I got the flashable image in USB, but the newly compiled uboot wouldn't know about the flash chip yet. So I added the entry from my first post to the list of flash chips IDs and recompiled everything (both UART and flashable images). Then the in-RAM uboot received via UART was able to flash the flashable image in USB (both with support for the new flash chip compiled in), and my board came back to life. It's a pity the manufacturer didn't bother to update their relatively good instructions in the wiki before replacing hardware with a basically incompatible part with no notice. BTW. You can leave the SECT_4K flag out; it'll just mean that block erases will be at least 64kiB in size rather than 4kiB when possible. The thing is the new chip does support 4kIB erases; I saw just 8k had to be cleared when switching between bootloaders. Also I saw the armada uboot repo has a version newer than boot-2017.03-armada-17.10. There's a u-boot-2013.01-armada-18.06 branch. I didn't try anything with it as the build instructions that worked required a pair of patches that I didn't want to look into. Also, it looks like that branch is different (w.r.t. flash drivers at least) and it still doesn't support the mx25u3235f anyway. Hope this helps.
  15. Update: I had to go back to 1000-800; otherwise I'd get the same as in this report, which is what I got the first time. BTW what I get during boot is slightly different SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB from what was reported here in the stock bootloader SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB I think that's because I added the SECT_4K keyword. The datasheet for mx25u3235f says that 4K sector erases are supported anyway, and everything seems to be working fine.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines