OpenWrt 21.0.1 does not boot after flashing on D-Link DIR-320 B1

Installing and Using OpenWrt
1

Hi,

For developers: the latest supported version for D-Link DIR-320 B1 (https://downloads.openwrt.org/releases/21.02.1/targets/ramips/rt305x/openwrt-21.02.1-ramips-rt305x-dlink_dir-320-b1-squashfs-sysupgrade.bin) does not work after flashing:

U-Boot 1.1.3 (Mar 31 2011 - 13:19:43)

Board: Ralink APSoC DRAM:  32 MB
rt2880 uboot v0.00e04 05/25/2006
SERIAL_CLOCK_DIVISOR =16 
kaiker,,CONFIG_BAUDRATE =57600 
SDRAM SIZE:02000000
Top of RAM usable for U-Boot at: 82000000
Reserving 319k for U-Boot at: 81fb0000
Reserving 260k for malloc() at: 81f6f000
Reserving 44 Bytes for Board Info at: 81f6efd4
Reserving 36 Bytes for Global Data at: 81f6efb0
Reserving 128k for boot params() at: 81f4efb0
Stack Pointer at: 81f4ef98
relocate_code Pointer at: 81fb0000
Now running in RAM - U-Boot at: 81fb0000

 monitor_flash_len =124244 
Command "rf": 0x80202578 => 0x81fb2578
Command "mdio": 0x8020a794 => 0x81fba794
Command "erase": 0x8020bf78 => 0x81fbbf78
Command "cp": 0x8020be4c => 0x81fbbe4c
Command "reset": 0x802181b0 => 0x81fc81b0
Command "go": 0x8020ceb0 => 0x81fbceb0
Command "bootm": 0x8020d68c => 0x81fbd68c
Command "loadb": 0x8020e4e4 => 0x81fbe4e4
Command "tftpboot": 0x8020eb48 => 0x81fbeb48
Command "httpd": 0x8020eb30 => 0x81fbeb30
Command "saveenv": 0x8020fb5c => 0x81fbfb5c
Command "setenv": 0x8020fa10 => 0x81fbfa10
Command "printenv": 0x8020f024 => 0x81fbf024
Command "?": 0x8020fd10 => 0x81fbfd10
Command "help": 0x8020fd10 => 0x81fbfd10
Command "version": 0x8020fbb0 => 0x81fbfbb0
Command "mw": 0x80212c88 => 0x81fc2c88
Command "nm": 0x80212e9c => 0x81fc2e9c
Command "mm": 0x80212ee4 => 0x81fc2ee4
Command "md": 0x802129b8 => 0x81fc29b8
spi_wait_nsec: 42 
spi device id: ef 40 17 0 0 (40170000)
find flash: W25Q64BV
raspi_read: from:30000 len:1000 
.raspi_read: from:30000 len:1000 
.Before: 3000
reg 2000
After: 3000
============================================ 
Ralink UBoot Version: 3.5.2.0
-------------------------------------------- 
ASIC 5350_MP (Port5<->None)
DRAM_CONF_FROM: Boot-Strapping 
DRAM_TYPE: SDRAM 
DRAM_SIZE: 256 Mbits
DRAM_WIDTH: 16 bits
DRAM_TOTAL_WIDTH: 16 bits
TOTAL_MEMORY_SIZE: 32 MBytes
Flash component: SPI Flash
Date:Mar 31 2011  Time:13:19:43
============================================ 
icache: sets:256, ways:4, linesz:32 ,total:32768
dcache: sets:128, ways:4, linesz:32 ,total:16384 

 ##### The CPU freq = 360 MHZ #### 
 estimate memory size =32 Mbytes
raspi_read: from:40004 len:6 
.

Please choose the operation: 
   1: Load system code to SDRAM via TFTP. 
   2: Load system code then write to Flash via TFTP. 
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial. 
   9: Load Boot Loader code then write to Flash via TFTP. 
 0 
   
3: System Boot system code via Flash.
## Booting image at bc050000 ...
raspi_read: from:50000 len:40 
.   Image Name:   MIPS OpenWrt Linux-5.4.154
   Created:      2021-10-24   9:01:35 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1497193 Bytes =  1.4 MB
   Load Address: 80000000
   Entry Point:  80000000
raspi_read: from:50040 len:16d869 
.......................   Verifying Checksum ... OK
   Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover


U-Boot 1.1.3 (Mar 31 2011 - 13:19:43)

We tested that the earlier version (https://downloads.openwrt.org/releases/19.07.8/targets/ramips/rt305x/openwrt-19.07.8-ramips-rt305x-dir-320-b1-squashfs-sysupgrade.bin) still works.

2

The kernel image might have gotten too big for what the bootloader was hardcoded to handle.

1 Like
3

I think V19 should be it's last

I would imagine even on V19 it's only usage should be dump access point
or USB print server
maybe a wifi client
but not routing

4

It's an 8MB flash device so 21.0 firmware fits on flash. Could you shed more details on this bootloader limitation? I don't have much experience with u-boot but I have poked it a bit, yet have not encountered that limitation before.

One more detail: 21.0.0 and 21.0.1 loads via TFTP and boots normally. As I understand the same u-boot is responsible for flash loading and TFTP loading.

5

Yes, but part of that 8 MB chip is used for calibration data, the bootloader, etc., all in their own 'partitions', within a fixed size. So the space that is actually usable for OpenWrt is way less.

See e.g. this bug report on how adding lzma loader support fixed small flash boot problems on other RAMIPS devices.

1 Like
6

As I understand from the comments it's not a firmware bug, it's a:

  • documentation bug. The device page should be pointing to v19 as the latest supported version nor declare 20.1 support
  • build system bug. there should not be a build for unsupported device

how should one proceed to help fix this situation?

7

?

If 21.02.1 boots normally, why should the latest supported version be 19.07?

8

v21 boots via TFTP, but does not boot from flash.

As I understood v19 is the latest version to support 32MB RAM devices and neither v21.0.0 nor v21.0.1 boots on this device. So I assume there is no intention to fix it and to protect other users from bricking their devices while upgrading we could remove misleading information from the device page.

on second thought, in case this is the same problem as @Borromini linked - the fix does not look very complicated

9

It won't hurt to try if using the LZMA loader fixes things.