| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
NVRAM packages for the same wireless chip are consolidated into one as
they contain only small text files and symlinks.
Signed-off-by: Kuan-Yi Li <kyli@abysm.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since all NVRAM files in external repo are now upstreamed and to lower
future maintenance cost, disassociate the package from external source
repo.
All upstream pending NVRAM files shall be stored locally from now on.
Signed-off-by: Kuan-Yi Li <kyli@abysm.org>
[Remove outdated URL, add SPDX-License-Identifier]
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to commit 6f6c2fb321, AP6335 module used in PICO-PI-IMX7D works
only with firmware from `linux-firmware`. However, firmware from
`cypress-firmware` suite is directly from the chip company (Infineon) and
is actually newer.
Instead of dropping the firmware from Infineon, create a package named
`brcmfmac-firmware-4339-sdio`, and keep the Infineon version of
`cypress-firmware-4339-sdio` around.
This gives us devs the option to choose. Also, it means that
- packages `brcmfmac-firmware-*` uniformly come from `linux-firmware`
- packages `cypress-firmware-*` uniformly come from `cypress-firmware`
so hopefully brings more clarity.
Tested-by: Lech Perczak <lech.perczak@gmail.com>
Signed-off-by: Kuan-Yi Li <kyli@abysm.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TechNexion PICO-PI-IMX7D is a NXP i.MX 7Dual based development board in
the well-known "Raspberry Pi" form factor, comprising of PICO-IMX7 SoM
and the PICO-PI-IMX7D carrier board.
Usually bundled with a 5" 800x480 LVDS display with I2C touchscreen and
an Omnivision OV5645 camera on a MIPI CSI bus, on a daughterboard. The
board was previously used primarily with "Android Things" ecosystem, but
the project was killed by Google.
This would not be possible, if not for the great tutorial of setting up
Debian on this board, by Robert C. Nelson [1].
Hardware highlights:
CPU: NXP i.MX 7Dual SoC, dual-core Cortex-A7 at 1000 MHz
RAM: 512 MiB DDR3 SDRAM
Storage: 4 GB eMMC
Networking:
- built-in Gigabit Ethernet with Atheros AR8035 PHY,
- Broadcom BCM4339 1x1 802.11ac Wi-Fi (over SDIO) + Bluetooth 4.1
(over SDIO + UART + IS2) combo, with Hirose u.FL connector on the
board,
- dual CAN interfaces on the 40-pin connector,
Interfaces:
- USB-C power input plus USB 2.0 OTG host/device port,
- single USB-A host port,
- serial console over built-in FT232BL USB-UART converter with
micro-USB connector (configuration: 115200-8-N-1),
- analog audio interface with TRRS connector in CTIA standard,
- SPI, I2C and UART interfaces available on the 40-pin,
- mikroBUS connector,
- I2C connector for the optional touch panel,
- parallel LCD output for the optional display,
- MIPI CSI connector for the optional camera
Installation:
1. Connect the serial console to debug USB connector and the terminal of
choice in another window, at 115200-8-N-1. Ensure you can switch to
it quickly after next step.
2. Power-on the board from your PC. Ensure your PC can supply required
current, the board can take more than 1 A in the peak load during
booting and brownout will result in power-on reset loop. Preferably,
use charging-capable USB port or connect through self-powered USB
hub. If U-Boot is present already on the eMMC, interrupt the booting
sequence by pressing any key and skip to point 7.
3. Ensure the boot mode jumpers J1 and J2 are in correct position for
USB recovery:
2 6 2 6
--------------
|o o-o||o-o o|
|o o-o||o-o o|
J1 -------------- J2
1 5 1 5
The jumpers are located just underneath the 40-pin expansion header
and are of the smaller 2 mm pitch.
4. Download and build 'imx_usb_loader' from:
https://github.com/boundarydevices/imx_usb_loader.
5. Power-on the board again from your PC through USB OTG connector.
6. Use 'imx_usb_loader' to load 'SPL' and 'u-boot-dtb.img' to the board:
$ sudo imx_usb u-boot-pico-pi-imx7d/SPL
$ sudo imx_usb u-boot-pico-pi-imx7d/u-boot-dtb.img
7. Switch to the terminal from step 2 and interrupt boot sequence by
pressing any key within 2 seconds.
8. Configure mmc 0 to boot from the data partition and disable access to
boot partitions:
=> mmc partconf 0 0 7 0
This only needs to be set once. If you were running Debian previously,
this is probably already set.
9. Enable USB mass storage passthrough for eMMC from U-boot
=> ums 0 mmc 0
10. Optionally, backup previous eMMC contents by reading out its image.
11. Copy over the factory image to the USB device, for example:
$ sudo dd if=openwrt-imx-cortexa7-pico-pi-imx7d-squashfs.combined.bin \
of=/dev/disk/by-id/usb-Linux_UMS_disk_0-0:0 \
bs=8M status=progress oflag=direct
12. Detach USB MSC interface from your PC and U-Boot by pressing Ctrl+C.
13. Ensure that boot mode jumpers are at the default settings for eMMC
boot:
2 6 2 6
--------------
|o-o o||o o-o|
|o-o o||o-o o|
J1 -------------- J2
1 5 1 5
If they are not, power-off the board, restore them and power-on the
board again. Otherwise, if jumpers are set, just reset the board from
U-Boot CLI:
=> reset
14. The installation is now complete and board should boot successfully.
Upgrading: just use sysupgrade image, as usual in OpenWrt.
Known issues/current limitations:
- OV5645 camera - not described in upstream device tree as of kernel
5.15. There are staging drivers present in upstream Linux tree for
i.MX 7 CSI, MIPI-CSI and video mux, and the configuration is there in
imx7s.dtsi - so this is expected to get supported eventually,
- on-chip ADCs are disabled in upstream device tree, so the kernel
driver remains disabled as well.
[1] https://forum.digikey.com/t/debian-getting-started-with-the-pico-pi-imx7/12429
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
[pepe2k@gmail.com: commit description reworded]
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
|
| |
|
|
|
|
|
|
| |
Most i.MX boards booting off eMMC or SD cards use raw U-Boot located at
69 kB offset from beginning of the device - create a recipe for such
image.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
|
| |
|
|
|
|
|
| |
The same combined image format can be used to boot both i.MX 6 and
i.MX 7 platforms - extract the common part.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For targets in U-Boot which were migrated to DM, the correct binary
image filename will be 'u-boot-dtb.img'. For backward compatibility,
keep support for both files and use the one which was generated with
our 'uboot-imx' package.
See also 'CONFIG_SPL_FS_LOAD_PAYLOAD_NAME' and 'CONFIG_OF_CONTROL' in
mainline U-Boot sources.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Upstream in commit 8b9c0cb46471 ("apalis_imx6: boot env configuration
updates") removed emmc legacy wrappers, but so far didn't included any
replacements. Fix it by simply defining the missing variables and UUID
gathering directly into the boot script.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
[pepe2k@gmail.com: updated commit title for 2022.01]
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds some essential files required by new 'cortexa7' subtarget,
dedicated for Cortex-A7 based NXP i.MX series. For now, the kernel
config-default focuses only on the i.MX 6UL family, as the following
changeset will introduce support for i.MX 6ULL based device. Support
for more platforms (e.g. i.MX 7) might be enabled later, while adding
more devices.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
Modern NXP i.MX series includes several different families, based on
single- or multi-core Arm Cortex-A CPUs. To be able to support more
families within a single target, we split the 'imx' in arch-specific
subtargets, starting with 'cortexa9' for the Cortex-A9 based i.MX 6,
already supported by the original 'imx6' target.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
|
|
|
This is first step in migrating to a generic i.MX target which in the
next steps will also get divided into arch-specific subtargets.
In the result, this will make it possible to support, within a single
target, also other modern NXP i.MX families, like the i.MX 7, i.MX 8
or recently introduced i.MX 9.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
|
