4 Mb Speicher
Megabit is a unit of measurement of digital information transmission or storage. It is one of the basic units in telecommunication and computer science. Megabit has the symbol of Mb, and it equals to 1000 kilobits or 10 6 bits. Supports AMD AM4 Socket Ryzen™ 2000, 3000 and 5000 Series Desktop Processors; Supports DDR4 3200+ (OC); 1 PCIe 3.0 x16, 1 PCIe 2.0 x16, 1 PCIe 2.0 x1; AMD Quad CrossFireX™; Graphics Output: HDMI, DVI-D, D-Sub; 7.1 CH HD Audio (Realtek ALC892 Audio Codec), ELNA Audio Caps; 4 SATA3, 1 Ultra M.2 (PCIe Gen3 x4), 1 M.2 (SATA3); 2 USB 3.1 Gen2 (Rear Type-A+C); 6 USB 3.1 Gen1 (2 Front, 4 Rear. (4) 4 product ratings - A-Tech 4GB PC3-12800 Laptop SODIMM DDR3 1600 MHz 204-Pin Notebook Memory RAM 4G. Supports AMD AM4 Socket Ryzen™ 3000, 4000 G-Series and 5000 Series Desktop Processors; 8 Power Phase Design, Digi Power; Supports DDR4 4733+ (OC); 1 PCIe 4.0 x16, 1 PCIe 3.0 x16, 2 PCIe 3.0 x1, 1 M.2 Key E for WiFi; Graphics Output Options: HDMI, D-Sub; AMD CrossFireX™; 7.1 CH HD Audio (Realtek ALC1200 Audio Codec), Nahimic Audio; 6 SATA3, 1 Hyper M.2 (PCIe Gen4 x4), 1 M.2 (PCIe Gen3 x2.
- ASRock Super Alloy
- Premium 42A Power Choke
- Sapphire Black PCB
- High Density Glass Fabric PCB
- 2oz Copper PCB
ASRock Ultra M.2 (PCIe Gen3 x4)
ASRock Full Spike Protection (for all USB, Audio, LAN Ports)
ASRock Live Update & APP Shop - - Supports AMD Socket AM4 A-Series APUs (Bristol Ridge) and Ryzen Series CPUs (Matisse, Picasso, Summit Ridge, Raven Ridge and Pinnacle Ridge)
- Digi Power design
- 9 Power Phase design - - AMD Promontory A320
- - Dual Channel DDR4 Memory Technology
- 4 x DDR4 DIMM Slots
- AMD Ryzen series CPUs (Matisse) support DDR4 3200 / 2933 / 2667 / 2400 / 2133 ECC & non-ECC, un-buffered memory*
- AMD Ryzen series CPUs (Matisse) support DDR4 3200 / 2933 / 2667 / 2400 / 2133 ECC & non-ECC, un-buffered memory*
- AMD Ryzen series CPUs (Picasso) support DDR4 2933 / 2667 / 2400 / 2133 non-ECC, un-buffered memory*
- AMD Ryzen series CPUs (Pinnacle Ridge) support DDR4 3200+(OC) / 2933(OC) / 2667 / 2400 / 2133 ECC & non-ECC, un-buffered memory*
- AMD Ryzen series CPUs (Summit Ridge) support DDR4 3200+(OC) / 2933(OC) / 2667 / 2400 / 2133 ECC & non-ECC, un-buffered memory*
- AMD Ryzen series CPUs (Raven Ridge) support DDR4 3200+(OC) / 2933 / 2667 / 2400 / 2133 non-ECC, un-buffered memory*
- AMD 7th Gen A-Series APUs support DDR4 2400 / 2133 non-ECC, un-buffered memory*
- Max. capacity of system memory: 64GB**
- 15μ Gold Contact in DIMM Slots*For Ryzen Series CPUs (Picasso and Raven Ridge), ECC is only supported with PRO CPUs.
Please refer to below table for AMD non-XMP memory frequency support.
A-Series APUs:
Ryzen Series CPUs (Matisse):
Ryzen Series CPUs (Pinnacle Ridge):
Ryzen Series CPUs (Picasso):
Ryzen Series CPUs (Summit Ridge):
Ryzen Series CPUs (Raven Ridge):
SR: Single rank DIMM, 1Rx4 or 1Rx8 on DIMM module label
DR: Dual rank DIMM, 2Rx4 or 2Rx8 on DIMM module label
**Due to the operating system limitation, the actual memory size may be less than 4GB for the reservation for system usage under Windows® 32-bit OS. For Windows® 64-bit OS with 64-bit CPU, there is no such limitation. - - 128Mb AMI UEFI Legal BIOS with multilingual GUI support
- Supports 'Plug and Play'
- ACPI 5.1 compliance wake up events
- Supports jumperfree
- SMBIOS 2.3 support
- DRAM Voltage multi-adjustment - - Integrated AMD Radeon™ Vega Series Graphics in Ryzen Series APU*
- Integrated AMD Radeon™ R-Series Graphics in A-series APU*
- DirectX 12, Pixel Shader 5.0
- Shared memory default 2GB. Max Shared memory supports up to 16GB.**
- Three graphics output options: D-Sub, DVI-D and HDMI
- Supports Triple Monitor
- Supports HDMI with max. resolution up to 4K x 2K (4096x2160) @ 24Hz / (3840x2160) @ 30Hz
- Supports DVI-D with max. resolution up to 1920x1200 @ 60Hz
- Supports D-Sub with max. resolution up to 1920x1200 @ 60Hz
- Supports Auto Lip Sync, Deep Color (12bpc), xvYCC and HBR (High Bit Rate Audio) with HDMI Port (Compliant HDMI monitor is required)
- Supports HDCP 1.4 with DVI-D and HDMI Ports
- Supports Full HD 1080p Blu-ray (BD) playback with DVI-D and HDMI Ports*Actual support may vary by CPU
**The Max shared memory 16GB requires 32GB system memory installed. - - 7.1 CH HD Audio with Content Protection (Realtek ALC892 Audio Codec)
- Premium Blu-ray Audio support
- Supports Surge Protection
- ELNA Audio Caps - - PCIE x1 Gigabit LAN 10/100/1000 Mb/s
- Realtek RTL8111GR
- Supports Wake-On-LAN
- Supports Lightning/ESD Protection
- Supports LAN Cable Detection
- Supports Energy Efficient Ethernet 802.3az
- Supports PXE - AMD Ryzen series CPUs (Matisse, Summit Ridge and Pinnacle Ridge)
- 1 x PCI Express 3.0 x16 Slot (PCIE2: x16 mode)*
- 1 x PCI Express 2.0 x16 Slot (PCIE3: x2 mode)
AMD 7th A-Series APUs
- 1 x PCI Express 3.0 x16 Slot (PCIE2: x8 mode)*
- 1 x PCI Express 2.0 x16 Slot (PCIE3: x2 mode)
AMD Ryzen series CPUs (Picasso, Raven Ridge)
- 1 x PCI Express 3.0 x16 Slot (PCIE2: x8 mode)*
- 1 x PCI Express 2.0 x16 Slot (PCIE3: x2 mode)
AMD Athlon series CPUs
- 1 x PCI Express 3.0 x16 Slot (PCIE2: x4 mode)*
- 1 x PCI Express 2.0 x16 Slot (PCIE3: x2 mode)
- 1 x PCI Express 2.0 x1 Slot - Storage- 4 x SATA3 6.0 Gb/s Connectors, support RAID (RAID 0, RAID 1 and RAID 10), NCQ, AHCI and Hot Plug*
- 1 x Ultra M.2 Socket (M2_1), supports M Key type 2242/2260/2280 M.2 PCI Express module up to Gen3 x4 (32 Gb/s) (with Matisse, Summit Ridge, Raven Ridge and Pinnacle Ridge) or Gen3 x2 (16 Gb/s) (with A-Series APU and Athlon series APU)**
- 1 x M.2 Socket (M2_2), supports M Key type 2230/2242/2260/2280 M.2 SATA3 6.0 Gb/s module*M2_2 and SATA3_3 share lanes. If either one of them is in use, the other one will be disabled.
**Supports NVMe SSD as boot disks
Supports ASRock U.2 Kit - - 1 x COM Port Header
- 1 x TPM Header
- 1 x Power LED and Speaker Header
- 1 x RGB LED Header*
- 1 x AMD Fan LED Header*
- 1 x CPU Fan Connector (4-pin)**
- 2 x Chassis Fan Connectors (1 x 3-pin, 1 x 4-pin - Smart Fan Speed Control)***
- 1 x 24 pin ATX Power Connector
- 1 x 8 pin 12V Power Connector
- 1 x Front Panel Audio Connector
- 2 x USB 2.0 Headers (Support 4 USB 2.0 ports) (Supports ESD Protection)
- 1 x USB 3.1 Gen1 Header (Supports 2 USB 3.1 Gen1 ports) (Supports ESD Protection)*Supports in total up to 12V/3A, 36W LED Strip
The AMD Fan LED Header supports LED strips of maximum load of 3A (36W) and length up to 2.5M.
**The CPU Fan Connector supports the CPU fan of maximum 1A (12W) fan power.
***CHA_FAN1 can auto detect if 3-pin or 4-pin fan is in use. - - 1 x PS/2 Mouse Port
- 1 x PS/2 Keyboard Port
- 1 x D-Sub Port
- 1 x DVI-D Port
- 1 x HDMI Port
- 2 x USB 2.0 Ports (Supports ESD Protection)
- 1 x USB 3.1 Gen1 Type-C Port (Supports ESD Protection)
- 4 x USB 3.1 Gen1 Ports (Supports ESD Protection)
- 1 x RJ-45 LAN Port with LED (ACT/LINK LED and SPEED LED)
- HD Audio Jacks: Line in / Front Speaker / Microphone - Software
- ASRock RGB LED
- ASRock APP Charger
- ASRock XFast LAN
UEFI
- ASRock Full HD UEFI
- ASRock Instant Flash
- ASRock Easy RAID Installer*These utilities can be downloaded from ASRock Live Update & APP Shop. - - Drivers, Utilities, AntiVirus Software (Trial Version), Google Chrome Browser and Toolbar
- - Quick Installation Guide, Support CD, I/O Shield
- 2 x SATA Data Cables
- 2 x Screws for M.2 Sockets - - CPU, Chassis temperature sensing
- CPU, Chassis Fan Tachometer
- CPU, Chassis Quiet Fan
- CPU, Chassis Fan multi-speed control
- Voltage monitoring: +12V, +5V, +3.3V, Vcore - - Micro ATX Form Factor: 9.6-in x 9.6-in, 24.4 cm x 24.4 cm
- Solid Capacitor design - - Microsoft® Windows® 10 64-bit
- - FCC, CE
- ErP/EuP ready (ErP/EuP ready power supply is required)
Devices that have only 4 MBytes of Flash memory or only 32 MBytes of RAM are unlikely to work with modern versions of OpenWrt (19.07, 20.0x, and newer). Here's why:
Every operating system requires
- Sufficient Flash to accommodate the firmware image
Devices with ≤4MB flash and/or ≤32MB RAM may still work but they will be very limited (usually they can't install or run additional packages) because they have low RAM and Flash space. Consider this when choosing a device to buy, or when deciding to flash OpenWrt on your device because it is listed as supported.
Usability issues
Insufficient RAM for stable operation
- 32 MB can barely work for minimal router/AP functions, but may repeatedly “crash”, depending on your hardware and use case
- 64 MB may still have issues with stability, depending on your hardware and use cases
- 128 MB or more is recommended if software past basic router/AP functionality is to be used
Extensibility issues
Barely enough Flash to accommodate OpenWrt firmware image
- 4MB is absolute minimum (but you won't be able to install LuCI web interface) / 8MB is barely enough (will fit LuCI and some other applications) / 16MB offers more flexibility
- 4MB devices can't fit anything noteworthy unless you use the Image Generator (Image Builder) (that requires a Linux system and some mild experience) or use Extroot. Experienced users creating custom builds may be able to Saving firmware space, but many packages won't ever fit no matter what you do.
- If you want to be sure you can install at least a few additional software packages, 8MB (or more) of flash and 64MB (or more) of RAM are the only choice.
Most probably, you will not be able to install the following popular packages (and others) on a device with only 4MB flash:
- Samba (shared folders)
- filesystem drivers/tools for formatting and checking a filesystem for Extroot
As the current master (and the forthcoming 20.x release) uses kernel 5.4 that is roughly 0.5 MB larger than the kernel 4.14 used in the old 19.07.x releases, the free space available on 8MB flash systems will be rather small in the next OpenWrt releases.
Supportability issues
It is getting harder or even impossible over time to support devices with low Flash + RAM.
The 32 MB RAM is harder limitation than the flash size. The current Linux 5.4 barely works with a 32 MB RAM system and spikes in memory consumption can easily crash the router with OOM (Out-of-Memory) errors.
OpenWrt support for those devices will end with the 19.07 release, ie. 19.07 will be the last release with support for 4/32 MB devices. There will be no future releases and no images ready for download after 19.07.
4 Mb Speicher 3
Advice
Users that are not expert users of OpenWrt (those that can build their own images) should consider
16/64 as an absolute minimum for any device, with at least 128 MB of RAM being preferred.
Users should expect that devices with less than 16 MB of flash and/or 64 MB of RAM may be unstable in basic operation under current versions of OpenWrt (17.X, 18.X). They should further expect that support for the device may be dropped at any time and that security patches/updates to the kernel, drivers, and/or application software will not be available. While there is no warranty of ongoing support for any device under OpenWrt, those with insufficient resources are at great risk for “end of support”.
Previous versions of OpenWrt (such as earlier versions of 17.01.x, 15.05.x “Chaos Calmer” and prior) contain now-known security vulnerabilities in the kernel, wireless implementation, and/or application code. The OpenWrt community cannot support running known-vulnerable code under any situation. “It's just my router” is not justification as your router becoming compromised can impact others as a jump-point, command-and-control, or other participant in an attack. In many cases, these known vulnerabilities are being actively targeted, potentially including by advanced, likely state-sponsored or state-affiliated actor or actors.
Analysis of firmware size growth
As example, the size of the sysupgrade release image for WNDR3700v1, an ar71xx/ath79 device that has been supported by Openwrt for ten years:
Main reason is growth in size of the Linux kernel itself, but all included core packages (wifi, LuCI, etc.) also tend to grow as their features get expanded.
Longer analysis of the issue done by forum user slh
As written in this forum post by forum user slh.
First of all, I'm not pretending to speak for the LEDE team, however looking at the plain numbers presents a quite obvious situation.
Taking “ Why no images generated for default D-Link DIR-600A1?” as an example (yes, some other 4 MB flash devices are a bit better than this particular specimen, the trend remains to be the same though).
(all of these figures are for release images, including luci and a more or less identical feature set).
The erase block size for this (and most other) devices is 64 KB, so you now end up with 256 KB ( 4 erase blocks) free space, compared to 320 KB ( 5 erase blocks before). While this may look comfortable at a first glance, you have to consider that free space can only be assigned in (full) block size chunks, so once you touch the overlay partition at all, you already have one erase block in use (64 KB). Therefore the firmware creation tools used by LEDE enforce at least 3 erase blocks reserve for the overlay filesystem (that's where the maximum usable firmware size comes from, compared to the total size of the firmware partition). In other words, with 17.01 you'll only have 1 erase block (64 KB) before the hard limit, while 15.05.1 still gave you 2 spare erase blocks (128 KB) for your own use. On top of this there is the file system overhead needed for formatting to jffs2 as well (jffs2 does some light compression, but its fs header and log (more or less directory entries) need some space, then there is the hard requirement to keep some free space (in erase block 64 KB chunks) for the garbage collection to work) at all times, reducing the usable free space even further. Around 25 KB are used by the configuration overlay immediately after firstboot, before you actually get a chance to configure anything.
Assuming pure statistics, what will the situation be in 12 or 24 months[1]?
No one has yet raised the suggestion to actually remove the hardware support for affected devices from LEDE's source repository. If you look deeper, you can still find full support for the Linksys WRT-54GL (4 MB flash, 16 MB RAM) in the repo, although support for devices with just 16 MB RAM had already been discontinued with Attitude Adjustment 12.09 and despite the fact that actually building a working up-to-date firmware for this device today is quite challenging[2].
This thread merely serves as a reminder for 'normal users', who expect to download and flash LEDE under the expectation to use it as a full featured replacement for the vendor firmware (including a webinterface, luci). Also keep in mind that luci is enabled for release builds, which means that it either fits into the firmware image (with the mandatory safety margin of at least 3 erase blocks) or no release images can be created for the affected devices[3], [4]. In my very personal opinion, this needs to be documented quite obviously, avoiding to raise false hope and expectations for (especially new) users.
Advanced users will obviously be able to delay the inevitable by quite some margin - depending on their use-cases and abilities to reduce LEDE's footprint below normal system requirements.
4 Mb Speicher -
Despite the title, the RAM size is actually a much harder limit, affecting much more than just 4 MB flash devices. If you look through the commit log, you will notice quite some efforts to get opkg to use less RAM, but it's still a problem with just 32 MB RAM (even for normal operations, before touching opkg). Likewise you already are in trouble with sysupgrade and trying to flash a (larger) 6-8 MB firmware on a device with just 32 MB RAM, unless you really clean up services and loaded kernel modules manually beforehand, there is a high risk that you'll oom during the sysupgrade and brick your device for good (requiring bootloader/ tftp assistance to recover in the best case).
[1] switching from mach files to device tree (post 17.01) offers a potential to free up a little space in the kernel, but this isn't a whole lot and will probably be eaten more or less completely by upgrading to kernel 4.9+ (also keep in mind that the FDT file needs to be appended to the kernel image, which might or might not compress as well as the mach files before), so don't expect a significant positive effect from this switch.
[2] no webinterface, better no pppd, quite some custom configurations to get the kernel's runtime memory requirements as small as possible, disabling whatever is humanly possible (definately no IPv6, better no wireless either).
[3] with LEDE's pretty new feature of device specific rootfs images, it would technically be possible to decide between installing luci or omitting it on a per device basis, e.g. based on flash sizes, but support for something like this hasn't been implemented yet and would require quite some attention (both as in source patches and tagging of device classes) from interested parties. As implemented right now, the decision is binary - either the default (release) config (including luci) fits XOR building a firmware image for the affected device fails and no firmware will be available.
[4] I would expect that there already are a couple of 4 MB flash devices in the target list for which no release firmware can be built for 17.01, because of less ideal flash partitioning schemes chosen by the vendor (dropping free space below 3 erase blocks). Those are probably a minority, but given the close numbers, I'd be very suprised if there wouldn't be any affected.
More explanations on this subject by forum user slh.
The opinion of a Core LEDE developer
As originally written in this forum post by jow.
Just providing my rather pragmatic opinion on the topic here:
I do not believe in arbitrarily dropping device support
We usually support devices as long as it is feasible
A device should be considered supported as long as
- small enough images can be produced to still allow configuration persistence
- no patches or other modifications to the source and buildroot are required
Eventually we might need to think about support tiers like:
4 Mb Speicher 2
- Full ⇒ allows for running gui, has working opkg and plenty of space to allow packages
- Medium ⇒ allows for running gui, has working opkg and at least enough space for setting up extroot
- Small ⇒ bootable images can be built when either sacrificing gui or opkg while still having configuration persistence
- Micro ⇒ only choice are heavily tailored custom images that require special measures like pre-shipped configuration, NFS mounts, preconfigured extroot etc.