| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ipTIME NAS1dual is a 1-bay NAS, based on Marvell Armada 385 SoC.
Specifications:
* SoC: 88F6820
* RAM: 2 GiB
* Flash: SPI NOR 64 MiB
* SATA: 1x 3Gb/s
* Ethernet: 2x 1GbE
* USB: 1x 3.0
* Fan: 2 speed level
* UART: J11 (115200 8N1)
* Pinout: [3V3] (TXD) (RXD) (GND)
Installation via web interface:
1. Flash **initramfs** image through the stock web interface.
2. Boot into OpenWrt and perform sysupgrade with sysupgrade image.
Revert to stock firmware:
1. Perform sysupgrade with stock image.
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2-Bay NAS - maximum two 3.5" Harddisks
Hardware:
- SoC: Marvell 88F6707-A1 ARMv7 Processor 1,2GHz (ARMADA 370 SoC)
- Ram: 1GB (2x Nanya NT5CC512M8DN-D1)
- NAND Flash: 256MB (ESMT F59L2G81A-25T)
- Lan: 1x GBE (Marvell 88E1318-NNB2)
- Storage: 2x SATA HDD 3.5" Slot
- USB: 2x USB 3.0 port (Renesas uPD720202)
- Console: Internal J3 connector (1: Vcc, 2: Rx, 3: Tx, 4: GND)
- LEDs: 13x GPIO controlled
- Buttons: 2x GPIO controlled
Known issues:
- Buzzer is unused due lack of proper driver
- USB1/2 usbport ledtrigger won't work (through DT)
- Renesas uPD720202 requires firmware file. It's possible to find
non-free binary. Please look for 'UPDATE.mem' file and put in into
'/lib/firmware/renesas_usb_fw.mem' file.
Installation:
- Apply factory initramfs image via stock web-gui.
- Do sysupgrade to make installation complete.
Back to stock:
- OpenWrt rootfs partition use unused space after stock firmware.
- Full revert is possible.
- Login via ssh and run:
## ctera_c200-v2_back_to_factory start ##
. /lib/functions.sh
part=$(find_mtd_part "active_bank")
active_bank=$(strings "$part" | grep bank)
if [ "$active_bank" = "bank1" ]; then
echo "bank2" > /tmp/change_bank
else
echo "bank1" > /tmp/change_bank
fi
mtd write /tmp/change_bank active_bank
reboot
## ctera_c200-v2_back_to_factory end ##
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
(put back-to-stock script into commit message, removed dup. SUBPAGESIZE var,
added 01_leds for non-working dt-usb-port trigger)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While an image layout based on MBR and 'bootfs' partition may be easy
to understand for users who are very used to the IBM PC and always have
the option to access the SD card outside of the device (and hence don't
really depend on other recovery methods or dual-boot), in my opinion
it's a dead end for many desirable features on embedded systems,
especially when managed remotely (and hence without an easy option to
access the SD card using another device in case things go wrong, for
example).
Let me explain:
* using a MSDOS/VFAT filesystem to store kernel(s) is problematic, as a
single corruption of the bootfs can render the system into a state
that it no longer boots at all. This makes dual-boot useless, or at
least very tedious to setup with then 2 independent boot partitions
to avoid the single point of failure on a "hot" block (the FAT index
of the boot partition, written every time a file is changed in
bootfs). And well: most targets even store the bootloader environment
in a file in that very same FAT filesystem, hence it cannot be used
to script a reliable dual-boot method (as loading the environment
itself will already fail if the filesystem is corrupted).
* loading the kernel uImage from bootfs and using rootfs inside an
additional partition means the bootloader can only validate the
kernel -- if rootfs is broken or corrupted, this can lead to a reboot
loop, which is often a quite costly thing to happen in terms of
hardware lifetime.
* imitating MBR-boot behavior with a FAT-formatted bootfs partition
(like IBM PC in the 80s and 90s) is just one of many choices on
embedded targets. There are much better options with modern U-Boot
(which is what we use and build from source for all targets booting
off SD cards), see examples in mediatek/mt7622 and mediatek/mt7623.
Hence rename the 'sdcard' feature to 'legacy-sdcard', and prefix
functions with 'legacy_sdcard_' instead of 'sdcard_'.
Tested-by: Stijn Tintel <stijn@linux-ipv6.be>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
|
| |
|
|
|
|
|
| |
Now that we have a generic sdcard upgrade method, which was copied from
the mvebu platform method, we can switch mvebu to the generic method.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Helios 4 is a NAS from Kobol
that is powered by an Armada 38x
MicroSOM from Solidrun, similarly
to Clearfog.
This device has:
-Armada 38x CPU
(dual core ARMv7 1.6 Ghz)
-2 GB of ECC RAM
-Gigabit ethernet (Marvell)
-2x USB 3.0 ports
-4x Sata 3.0 ports
-i2c header (J9 |>GND|SDA|SCL|VCC)
-2x 3-pin fan headers with PWM
-micro-usb port is a TTL/UART to
USB converter connected to TTL
-MicroSD card slot
-System, 4xSata and 1xUSB LEDs
NOT WORKING: fan control
Fan Control requires a kernel patch
that is available in the Armbian
project (the "default firmware"
of this device) and named
mvebu-gpio-remove-hardcoded
-timer-assignment
This patch isn't acceptable
by OpenWrt, it should be upstreamed.
I also have that patch in my own
local OpenWrt builds,
in case you want a more
clean and less confusing patch
for upstreaming.
To install, write the disk image
on a micro SD card with dd or
win32 disk imager, insert the
card in the slot.
Check that the dip switch battery
for boot selection is as follows
Switch 1 and 2 down/off, switches
3, 4, 5 up/on.
Signed-off-by: Alberto Bursi <bobafetthotmail@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Linksys devices in mvebu target feature a mixed naming,
where parts are based on the official product name (device
node, image; e.g. WRT3200ACM) and parts are based on the
internal code name (DTS file name, compatible, LED labels;
e.g. rango). This inconsistent naming has been perceived
as quite confusing.
A recent attempt by Paul Spooren to harmonize this naming
in kernel has been declined there. However, for us it still
makes sense to apply at least a part of these changes
locally.
Primarily, this patch changes the compatible in DTS and thus
the board name used in various scripts to have them in line
with the device, model and image names. Due to the recent
switch from swconfig to DSA, this allows us to drop
SUPPORTED_DEVICES and thus prevent seamless upgrade between
these incompatible setups.
However, this does not include the LED label rename from
Paul's initial patch: I don't think it's worth keeping the
enormous diff locally for this case, as we can implement
this much easier in 01_leds if we have to live with the
inconsistency anyway.
Signed-off-by: Paul Spooren <mail@aparcar.org>
[rebase, extend to all devices, drop DT LED changes]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Buffalo LinkStation LS421DE is a dual bay NAS, based on Marvell Armada 370
Hardware:
SoC: Marvell Armada 88F6707-A1
CPU: Cortex-A9 1200 MHz, 1 core
Flash: SPI-NOR 1 MiB, NAND 512 MiB
RAM: DDR3 512 MiB
Ethernet: 1x 10/100/1000 Mbps
USB: 1x 2.0, 1x 3.0
SATA: 2x 3.0 Gbps
LEDs/Input : 5x / 2x (1x button, 1x slide-switch)
RTC: Ricoh RS5C372A, I2C, no battery
Flash instruction (UART+TFTP):
1. Downgrade the OEM firmware to 1.34 version (BUFFALO_BOOTVER=0.13)
2. Remove any hard drive from inside the bays.
3. Boot the Openwrt initramfs image using the U-Boot serial console:
tftpboot 0x1200000 buffalo_ls421de-initramfs-kernel.bin
bootm 0x1200000
4. Flash the sysupgrade image using the Openwrt console:
sysupgrade -n buffalo_ls421de-squashfs-sysupgrade.bin
5. Wait until it finish, the device will reboot with Openwrt installed
on the NAND flash.
Note:
- Device shuting down doesn't work, even if the power slide switch is
used. We must first, via MDIO, set the unused LED2 at the ethernet
phy0 to off state. Reboot works ok.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
|
|
|
For the mvebu target in particular, there is a lot of files in
base-files that are only relevant for one subtarget. Improve
overview and reduce size per subtarget by moving/splitting
base-files depending on the subtarget they belong to.
While at it, consolidate 01_leds by using the model part of
the board name as variable.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Acked-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
|
