Add initial support for Rock PI 4 board.
Specification
- Rockchip RK3399
- LPDDR4
- eMMC
- SD card slot
- RTL8211E 1Gbps
- HDMI In/Out, DP, MIPI DSI/CSI
- PCIe M.2
- USB 2.0, USB-3.0
- USB C Type
Commit details of rk3399-rock-pi-4.dts sync from Linux 5.1-rc2:
"arm64: dts: rockchip: add ROCK Pi 4
Add default SPL_FIT_GENERATOR py script for rockchip platforms if
specific target enabled SPL_LOAD_FIT.
So, this would help get rid of explicitly mentioning the default
SPL FIT generator in defconfigs. however some targets, like puma_rk3399
still require their own FIT generator so in those cases
On 5/8/19 3:08 AM, Takahiro Akashi wrote:
On Wed, May 08, 2019 at 02:59:08AM +0200, Heinrich Schuchardt wrote:
On 5/8/19 1:59 AM, Takahiro Akashi wrote:
On Tue, May 07, 2019 at 09:13:24PM +0200, Heinrich Schuchardt wrote:
Implement unloading of images in the Exit() boot services:
* unload
Add initial support for Nanopc T4 board.
Specification
- Rockchip RK3399
- Dual-Channel 4GB LPDDR3-1866
- SD card slot
- 16GB eMMC
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- DC 12V/2A
Commit details
Add initial support for Rockpro64 board.
Specification
- Rockchip RK3399
- 2/4GB Dual-Channel LPDDR3
- SD card slot
- eMMC socket
- 128Mb SPI Flash
- Gigabit ethernet
- PCIe 4X slot
- WiFI/BT module socket
- HDMI In/Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO
Add initial support for Nanopi NEO4 board.
Specification
- Rockchip RK3399
- 1GB DDR3-1866
- SD card slot
- eMMC Socket
- RTL8211E 1Gbps
- AP6212 WiFI/BT
- HDMI In/Out, DP, MIPI CSI
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- DC 5V/3A
Commit details of
Since rockchip have an individual doc/README.rockchip, it would
be better to update the same instead of maintaining it separately
in board files.
So, add the documentation for rk3399
- procedure to build for Rockchip miniloader and
U-Boot SPL options
- procedure to boot from SD for Rockchip
Few SPL and U-Boot proper configs are common to all rk3399 target
defconfigs, move them and select it from platform kconfig.
Moved configs:
- SPL_ATF
- SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
- SPL_LOAD_FIT
- SPL_CLK if SPL
- SPL_PINCTRL if SPL
- SPL_RAM if SPL
- SPL_REGMAP if SPL
-
sdmmc cd pin is configured as RK_FUNC_GPIO which is wrong and
indeed failed to detect the sdcard on the board with below error
Card did not respond to voltage select!
So, fix it by replacing RK_FUNC_GPIO with RK_FUNC_1 which
is already defined in rk3399.dts so make use of same like
other
Add initial support for Nanopi M4 board.
Specification
- Rockchip RK3399
- Dual-Channel 4GB LPDDR3-1866
- SD card slot
- eMMC socket
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI
- USB 3.0 x4
- USB Type C power and data
- GPIO1, GPIO2 expansion ports
- DC5V/3A
Commit details
Sync rk3399-nanopi4.dtsi from Linux 5.1-rc2 tag.
Linux commit details about the rk3399-nanopi4.dtsi sync:
"arm64: dts: rockchip: Add nanopi4 bluetooth"
(sha1: 3e2f0bb72be36aa6c14ee7f11ac4dd8014801030)
Signed-off-by: Jagan Teki
Reviewed-by: Paul Kocialkowski
Reviewed-by: Kever Yang
---
To make successful build with dts(i) files syncing from Linux 5.1-rc2
the rk3399.dtsi would require pwm2_pin_pull_down.
So, sync the pwm2_pin_pull_down node from Linux 5.1-rc2. Since this
node is strictly not part of any commit alone, I have mentioned
Linux 5.1-rc2 tag for future reference of
(Sorry for the noice, I have missed to send two patches from v7)
This is v7 resend patchset for New rk3399 boards support wrt previous
version[1]
Unfortunately initial version of creating rk3399-u-boot.dtsi and
orangepi rk3399 changes are merged, so this is rework on top of
Hi Kever,
> Subject: [PATCH] bouncebuf: add feature to support buffer only available in
> DRAM
>
> Some DMA which inside peripheral controller can only access space in DRAM
> area, the target address outside DRAM is not available.
> eg. Rockchip MMC contrller's internal DMA can only access DRAM
Hi Simon,
On Wed, May 8, 2019 at 11:41 AM Simon Glass wrote:
>
> Hi Bin,
>
> On Tue, 7 May 2019 at 21:33, Bin Meng wrote:
> >
> > Hi Simon,
> >
> > On Tue, May 7, 2019 at 6:07 PM Bin Meng wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, May 3, 2019 at 12:52 AM Simon Glass wrote:
> > > >
> > >
On Wed, May 8, 2019 at 11:41 AM Simon Glass wrote:
>
> Add a version of samus which supports booting from TPL to SPL and then
> to U-Boot. This allows TPL to select from an A or B SPL to support
> verified boot with field upgrade.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Bin Meng
> ---
>
>
On Wed, May 8, 2019 at 11:41 AM Simon Glass wrote:
>
> This reverts commit aec4298ccb337106fd0115b91d846a022fdf301d.
>
> Unfortunately this has a dramatic impact on the pre-relocation memory
> used on x86 platforms (increasing it by 2KB) since it increases the
> overhead for each PCI device from
On Wed, May 8, 2019 at 11:41 AM Simon Glass wrote:
>
> Add nvdata drivers for the TPM and RTC as used on samus. These are needed
> for Chromium OS verified boot on samus.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Bin Meng
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
On Wed, May 8, 2019 at 12:40 PM Bin Meng wrote:
>
> On Wed, May 8, 2019 at 11:41 AM Simon Glass wrote:
> >
> > Add tags to allow required nodes to be present in SPL / TPL.
> >
> > Signed-off-by: Simon Glass
> >
> > ---
> >
> > Changes in v4:
> > - Update commit message to not mention the
On Wed, May 8, 2019 at 11:41 AM Simon Glass wrote:
>
> Add tags to allow required nodes to be present in SPL / TPL.
>
> Signed-off-by: Simon Glass
>
> ---
>
> Changes in v4:
> - Update commit message to not mention the sysreset driver.
> - Drop change to SPI flash memory-map property
>
> Changes
On Tue, 2019-05-07 at 22:00 +0200, Simon Goldschmidt wrote:
>
> On 07.05.19 19:25, Andreas Dannenberg wrote:
> >
[...]
> >
> > While I also have a working solution based on the existing FS
> > loader
> > framework this has its own challenges, namely by its very nature
> > only
> > addressing a
On Tue, 2019-05-07 at 21:44 +0200, Marek Vasut wrote:
> On 5/7/19 9:43 PM, Simon Goldschmidt wrote:
> >
> >
> >
> > On 07.05.19 21:41, Marek Vasut wrote:
> > >
> > > On 5/7/19 9:36 PM, Simon Goldschmidt wrote:
> > > >
> > > >
> > > >
> > > > On 07.05.19 21:19, Marek Vasut wrote:
> > > > >
On 5/8/19 5:07 AM, Ley Foon Tan wrote:
> Fix SPI flash environment erase size error.
>
> CONFIG_ENV_SECT_SIZE is set to 4KB. Enable CONFIG_SPI_FLASH_USE_4K_SECTORS
> to allow erase one environment sector.
>
> Fix error below:
>
> SOCFPGA_STRATIX10 # saveenv
> Saving Environment to SPI Flash...
On 05/08/2019 02:36 AM, Jagan Teki wrote:
> Add initial support for Nanopi NEO4 board.
>
> Specification
> - Rockchip RK3399
> - 1GB DDR3-1866
> - SD card slot
> - eMMC Socket
> - RTL8211E 1Gbps
> - AP6212 WiFI/BT
> - HDMI In/Out, DP, MIPI CSI
> - USB 3.0, 2.0
> - USB Type C power and data
> -
On 05/08/2019 02:36 AM, Jagan Teki wrote:
> Add initial support for Rockpro64 board.
>
> Specification
> - Rockchip RK3399
> - 2/4GB Dual-Channel LPDDR3
> - SD card slot
> - eMMC socket
> - 128Mb SPI Flash
> - Gigabit ethernet
> - PCIe 4X slot
> - WiFI/BT module socket
> - HDMI In/Out, DP, MIPI
On 05/08/2019 02:36 AM, Jagan Teki wrote:
> Add initial support for Nanopc T4 board.
>
> Specification
> - Rockchip RK3399
> - Dual-Channel 4GB LPDDR3-1866
> - SD card slot
> - 16GB eMMC
> - RTL8211E 1Gbps
> - AP6356S WiFI/BT
> - HDMI In/Out, DP, MIPI DSI/CSI, eDP
> - USB 3.0, 2.0
> - USB Type C
On 05/08/2019 02:36 AM, Jagan Teki wrote:
> sdmmc cd pin is configured as RK_FUNC_GPIO which is wrong and
> indeed failed to detect the sdcard on the board with below error
>
> Card did not respond to voltage select!
>
> So, fix it by replacing RK_FUNC_GPIO with RK_FUNC_1 which
> is already
On 05/08/2019 02:36 AM, Jagan Teki wrote:
> Sync rk3399-nanopi4.dtsi from Linux 5.1-rc2 tag.
>
> Linux commit details about the rk3399-nanopi4.dtsi sync:
> "arm64: dts: rockchip: Add nanopi4 bluetooth"
> (sha1: 3e2f0bb72be36aa6c14ee7f11ac4dd8014801030)
>
> Signed-off-by: Jagan Teki
>
On 05/08/2019 02:36 AM, Jagan Teki wrote:
> Few SPL and U-Boot proper configs are common to all rk3399 target
> defconfigs, move them and select it from platform kconfig.
>
> Moved configs:
> - SPL_ATF
> - SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
> - SPL_LOAD_FIT
> - SPL_CLK if SPL
> -
On 05/08/2019 02:36 AM, Jagan Teki wrote:
> Add default SPL_FIT_GENERATOR py script for rockchip platforms if
> specific target enabled SPL_LOAD_FIT.
>
> So, this would help get rid of explicitly mentioning the default
> SPL FIT generator in defconfigs. however some targets, like puma_rk3399
>
On 05/08/2019 02:36 AM, Jagan Teki wrote:
> To make successful build with dts(i) files syncing from Linux 5.1-rc2
> the rk3399.dtsi would require pwm2_pin_pull_down.
>
> So, sync the pwm2_pin_pull_down node from Linux 5.1-rc2. Since this
> node is strictly not part of any commit alone, I have
On 05/08/2019 02:24 AM, Jagan Teki wrote:
> CONFIG_SPL_TEXT_BASE was available in configs/rk3399_common.h
> when the OrangePI rk3399 board supported during first
> version patch.
>
> But, later below change which move this config into Kconfig and
> same has been merged in mainline tree.
>
Add a version of samus which supports booting from TPL to SPL and then
to U-Boot. This allows TPL to select from an A or B SPL to support
verified boot with field upgrade.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Sort
Hi Bin,
On Tue, 7 May 2019 at 21:33, Bin Meng wrote:
>
> Hi Simon,
>
> On Tue, May 7, 2019 at 6:07 PM Bin Meng wrote:
> >
> > Hi Simon,
> >
> > On Fri, May 3, 2019 at 12:52 AM Simon Glass wrote:
> > >
> > > At present SPL is used on 64-bit platforms, to allow SPL to be built as
> > > a 32-bit
Add tags to allow required nodes to be present in SPL / TPL.
Signed-off-by: Simon Glass
---
Changes in v4:
- Update commit message to not mention the sysreset driver.
- Drop change to SPI flash memory-map property
Changes in v3:
- Remove unneeded pch-reset node
Changes in v2: None
This reverts commit aec4298ccb337106fd0115b91d846a022fdf301d.
Unfortunately this has a dramatic impact on the pre-relocation memory
used on x86 platforms (increasing it by 2KB) since it increases the
overhead for each PCI device from 220 bytes to 412 bytes.
The offending line is in
Add nvdata drivers for the TPM and RTC as used on samus. These are needed
for Chromium OS verified boot on samus.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/x86/dts/chromebook_samus.dts | 22 +-
1
On 05/08/2019 02:21 AM, Jagan Teki wrote:
> Now we have
> - board specific -u-boot.dtsi files for board specific u-boot
> dts changes.
> - soc specific rk3399-u-boot.dtsi for soc specific u-boot
> dts changes.
>
> So, include the rk3399-u-boot-dtsi on respective board -u-boot.dtsi
> and drop
At present SPL is used on 64-bit platforms, to allow SPL to be built as
a 32-bit program and U-Boot proper to be built as 64-bit.
However it is useful to be able to use SPL on any x86 platform, where
U-Boot needs to be updated in the field. Then SPL can select which U-Boot
to run (A or B) and
On 05/08/2019 02:21 AM, Jagan Teki wrote:
> Devicetree files in RK3399 platform is synced from Linux, like other
> platforms does. Apart from these u-boot in rk3399 would also require
> some u-boot specific node like dmc.
>
> dmc node has big chunk of DDR timing parameters which are specific
>
On 05/08/2019 02:21 AM, Jagan Teki wrote:
> Add u-boot,dm-pre-reloc property for spi1, so-that the
> subsequent rk3399 boards which boot from SPI.
>
> This help to separate the u-boot specific properties away
> from base dts files so-that the Linux sync become easy and
> meaningful.
>
>
On 05/08/2019 02:21 AM, Jagan Teki wrote:
> - Sometimes u-boot specific dtsi files are included
> automatically which would build for entire rockchip SoC,
> even-though the respective dtsi should used it for specific
> family of rockchip SoC.
> - Sometimes u-boot specific dts nodes or
Hi Simon,
On Tue, May 7, 2019 at 6:07 PM Bin Meng wrote:
>
> Hi Simon,
>
> On Fri, May 3, 2019 at 12:52 AM Simon Glass wrote:
> >
> > At present SPL is used on 64-bit platforms, to allow SPL to be built as
> > a 32-bit program and U-Boot proper to be built as 64-bit.
> >
> > However it is
Hi Simon,
On Wed, May 8, 2019 at 11:04 AM Simon Glass wrote:
>
> Hi Bin,
>
> On Tue, 7 May 2019 at 03:28, Bin Meng wrote:
> >
> > Hi Simon, Thierry,
> >
> > On Fri, May 3, 2019 at 12:22 AM Simon Glass wrote:
> > >
> > > Hi Thierry,
> > >
> > > On Thu, 2 May 2019 at 03:25, Thierry Reding
Fix SPI flash environment erase size error.
CONFIG_ENV_SECT_SIZE is set to 4KB. Enable CONFIG_SPI_FLASH_USE_4K_SECTORS
to allow erase one environment sector.
Fix error below:
SOCFPGA_STRATIX10 # saveenv
Saving Environment to SPI Flash...
SF: Detected mt25qu02g with page size 256 Bytes, erase
Hi Bin,
On Tue, 7 May 2019 at 03:28, Bin Meng wrote:
>
> Hi Simon, Thierry,
>
> On Fri, May 3, 2019 at 12:22 AM Simon Glass wrote:
> >
> > Hi Thierry,
> >
> > On Thu, 2 May 2019 at 03:25, Thierry Reding wrote:
> > >
> > > On Thu, May 02, 2019 at 12:09:49AM +0800, Bin Meng wrote:
> > > >
On 5/8/19 4:42 AM, Ley Foon Tan wrote:
> On Tue, May 7, 2019 at 9:04 PM Marek Vasut wrote:
>>
>> On 5/7/19 8:01 AM, Ley Foon Tan wrote:
>>> Fix SPI flash environment erase size error.
>>>
>>> Erase size of flash mt25qu02g on Stratix 10 should be 64KB.
>>>
>>> SOCFPGA_STRATIX10 # saveenv
>>>
On Tue, May 7, 2019 at 9:04 PM Marek Vasut wrote:
>
> On 5/7/19 8:01 AM, Ley Foon Tan wrote:
> > Fix SPI flash environment erase size error.
> >
> > Erase size of flash mt25qu02g on Stratix 10 should be 64KB.
> >
> > SOCFPGA_STRATIX10 # saveenv
> > Saving Environment to SPI Flash...
> > SF:
Hi Fabio,
> Subject: [PATCH] imx: mkimage_fit_atf: Fix DTC warnings
>
> When generating the flash.bin binary the following DTC warnings are seen:
>
> u-boot.itb.tmp: Warning (unit_address_vs_reg): Node /images/uboot@1 has
> a unit name, but no reg property
> u-boot.itb.tmp: Warning
Hi Lukasz,
> Subject: [PATCH] Revert "mmc: fsl_esdhc: fix sd/mmc ddr mode clock setting
> issue"
>
> This reverts commit 72a89e0da5ac6a4ab929b15a2b656f04f50767f6, which
> causes the imx53 HSC to hang as the eMMC is not working properly anymore.
>
> The exact error message:
> MMC write: dev # 0,
On Wed, May 08, 2019 at 02:59:08AM +0200, Heinrich Schuchardt wrote:
> On 5/8/19 1:59 AM, Takahiro Akashi wrote:
> >On Tue, May 07, 2019 at 09:13:24PM +0200, Heinrich Schuchardt wrote:
> >>Implement unloading of images in the Exit() boot services:
> >>
> >>* unload images that are not yet started,
On 5/8/19 1:59 AM, Takahiro Akashi wrote:
On Tue, May 07, 2019 at 09:13:24PM +0200, Heinrich Schuchardt wrote:
Implement unloading of images in the Exit() boot services:
* unload images that are not yet started,
* unload started applications,
* unload drivers returning an error.
On 5/8/19 1:56 AM, Takahiro Akashi wrote:
On Tue, May 07, 2019 at 06:54:45PM +0200, Heinrich Schuchardt wrote:
On 5/7/19 9:30 AM, Takahiro Akashi wrote:
On Tue, May 07, 2019 at 09:12:56AM +0200, Heinrich Schuchardt wrote:
On 5/7/19 8:16 AM, Takahiro Akashi wrote:
On Tue, May 07, 2019 at
On Tue, May 07, 2019 at 09:13:24PM +0200, Heinrich Schuchardt wrote:
> Implement unloading of images in the Exit() boot services:
>
> * unload images that are not yet started,
> * unload started applications,
> * unload drivers returning an error.
>
> Signed-off-by: Heinrich Schuchardt
> ---
>
On Tue, May 07, 2019 at 06:54:45PM +0200, Heinrich Schuchardt wrote:
> On 5/7/19 9:30 AM, Takahiro Akashi wrote:
> >On Tue, May 07, 2019 at 09:12:56AM +0200, Heinrich Schuchardt wrote:
> >>On 5/7/19 8:16 AM, Takahiro Akashi wrote:
> >>>On Tue, May 07, 2019 at 08:04:26AM +0200, Heinrich Schuchardt
Hi Tom,
The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980:
I rebased on your master and built for BB Black. DHCP seems to work fine.
MLO also now fits again.
Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00
-0400)
are available in the git
Hi Pierre-Jean,
On Tue, May 7, 2019 at 6:55 PM Pierre-Jean Texier wrote:
>
> Since the pico-pi uses the distroboot,
> this commit remove the 'script' variable (cf boot_scripts).
>
> Signed-off-by: Pierre-Jean Texier
Yes, we should better remove it:
Reviewed-by: Fabio Estevam
Since the pico-pi uses the distroboot,
this commit remove the 'script' variable (cf boot_scripts).
Signed-off-by: Pierre-Jean Texier
---
include/configs/pico-imx7d.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h
index
Hi Breno,
On Tue, May 7, 2019 at 5:19 PM Breno Matheus Lima wrote:
>
> According to hab.c code we have to notify the ROM code if the MMU is
> enabled or not. This is achieved by setting the "pu_irom_mmu_enabled"
> to 0x1.
>
> The current address in hab.c code is wrong for i.MX6SL, according to
According to hab.c code we have to notify the ROM code if the MMU is
enabled or not. This is achieved by setting the "pu_irom_mmu_enabled"
to 0x1.
The current address in hab.c code is wrong for i.MX6SL, according to ROM
map file the correct address is 0x00901c60.
As we are writing in the wrong
On 07.05.19 19:25, Andreas Dannenberg wrote:
TI K3 SoCs like the AM654x devices are fundamentally dependent on a
firmware called SYSFW (System Firmware) being loaded into the dedicated
DMSC (Device Management and Security Controller) processor to provide
various services via TISCI (Texas
On 5/7/19 9:43 PM, Simon Goldschmidt wrote:
>
>
> On 07.05.19 21:41, Marek Vasut wrote:
>> On 5/7/19 9:36 PM, Simon Goldschmidt wrote:
>>>
>>>
>>> On 07.05.19 21:19, Marek Vasut wrote:
According to SoCFPGA Cyclone V datasheet rev.2018.01.26 page 175
(Chapter 5, FPGA Manager, data
On 07.05.19 21:41, Marek Vasut wrote:
On 5/7/19 9:36 PM, Simon Goldschmidt wrote:
On 07.05.19 21:19, Marek Vasut wrote:
According to SoCFPGA Cyclone V datasheet rev.2018.01.26 page 175
(Chapter 5, FPGA Manager, data register) and Arria10 datasheet
rev.2017.07.22 page 211 (Chapter 5.4.1.2,
On 5/7/19 9:42 PM, Simon Goldschmidt wrote:
>
>
> On 07.05.19 21:20, Marek Vasut wrote:
>> On SoCFPGA Gen5 systems, it can rarely happen that a reboot from Linux
>> will result in stale data in PL310 L2 cache controller. Even if the L2
>> cache controller is disabled via the CTRL register
On 07.05.19 21:20, Marek Vasut wrote:
On SoCFPGA Gen5 systems, it can rarely happen that a reboot from Linux
will result in stale data in PL310 L2 cache controller. Even if the L2
cache controller is disabled via the CTRL register CTRL_EN bit, those
data can interfere with operation of devices
On 07.05.19 21:19, Marek Vasut wrote:
According to SoCFPGA Cyclone V datasheet rev.2018.01.26 page 175
(Chapter 5, FPGA Manager, data register) and Arria10 datasheet
rev.2017.07.22 page 211 (Chapter 5.4.1.2, FPGA Manager, img_data_w
register), the FPGA data register must be written with writes
On 07.05.19 21:20, Marek Vasut wrote:
Pull the PL310 clearing code into common code, so it can be reused
by Arria10.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dalon Westergreen
Cc: Dinh Nguyen
Cc: Simon Goldschmidt
Cc: Tien Fong Chee
Reviewed-by: Simon Goldschmidt
---
On 5/7/19 9:36 PM, Simon Goldschmidt wrote:
>
>
> On 07.05.19 21:19, Marek Vasut wrote:
>> According to SoCFPGA Cyclone V datasheet rev.2018.01.26 page 175
>> (Chapter 5, FPGA Manager, data register) and Arria10 datasheet
>> rev.2017.07.22 page 211 (Chapter 5.4.1.2, FPGA Manager, img_data_w
>>
On 5/7/19 9:28 PM, Simon Goldschmidt wrote:
>
>
> On 07.05.19 21:18, Marek Vasut wrote:
>> Pull out the u-boot,dm-pre-reloc from
>> socfpga_arria10_socdk_sdmmc_handoff.dtsi
>> into separate dtsi header file to make it easier to patch in custom
>> handoff
>> dtsi files, without having to manually
On 07.05.19 21:18, Marek Vasut wrote:
Pull out the u-boot,dm-pre-reloc from socfpga_arria10_socdk_sdmmc_handoff.dtsi
into separate dtsi header file to make it easier to patch in custom handoff
dtsi files, without having to manually add the U-Boot bits. Shuffle the include
clauses in the A10 DT
On 07.05.19 21:14, Wolfgang Grandegger wrote:
Am 07.05.19 um 13:37 schrieb Simon Goldschmidt:
On Tue, May 7, 2019 at 9:41 AM Wolfgang Grandegger
wrote:
Am 06.05.19 um 22:16 schrieb Simon Goldschmidt:
Am 06.05.2019 um 17:45 schrieb Wolfgang Grandegger:
Re-add support for Aries
On 07.05.19 21:17, Andreas Dannenberg wrote:
Hi Simon,
On Tue, May 07, 2019 at 08:16:07PM +0200, Simon Goldschmidt wrote:
On 07.05.19 19:25, Andreas Dannenberg wrote:
Introduce a framework that allows loading the System Firmware (SYSFW)
binary as well as the associated configuration data
On SoCFPGA Gen5 systems, it can rarely happen that a reboot from Linux
will result in stale data in PL310 L2 cache controller. Even if the L2
cache controller is disabled via the CTRL register CTRL_EN bit, those
data can interfere with operation of devices using DMA, like e.g. the
DWMMC
Pull the PL310 clearing code into common code, so it can be reused
by Arria10.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dalon Westergreen
Cc: Dinh Nguyen
Cc: Simon Goldschmidt
Cc: Tien Fong Chee
---
arch/arm/mach-socfpga/include/mach/misc.h | 1 +
arch/arm/mach-socfpga/misc.c
According to SoCFPGA Cyclone V datasheet rev.2018.01.26 page 175
(Chapter 5, FPGA Manager, data register) and Arria10 datasheet
rev.2017.07.22 page 211 (Chapter 5.4.1.2, FPGA Manager, img_data_w
register), the FPGA data register must be written with writes with
non-incrementing address.
The
Keep the FPGA bridge entries in SPL DT to let do_bridge_reset() toggle
the bridges on/off as needed according to the handoff file.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Simon Goldschmidt
Cc: Tien Fong Chee
---
.../dts/socfpga_arria10_handoff_u-boot.dtsi | 24
Pull out the u-boot,dm-pre-reloc from socfpga_arria10_socdk_sdmmc_handoff.dtsi
into separate dtsi header file to make it easier to patch in custom handoff
dtsi files, without having to manually add the U-Boot bits. Shuffle the include
clauses in the A10 DT files to make it obvious what gets
Set the spl_image->fdt_addr pointer both for simple fitImage configuration
as well as full fitImage configuration, to let spl_perform_fixups() access
the DT and perform modifications to it if necessary.
Signed-off-by: Marek Vasut
Cc: Tom Rini
---
common/spl/spl.c | 4 +++-
include/spl.h| 2
Hi Simon,
On Tue, May 07, 2019 at 08:16:07PM +0200, Simon Goldschmidt wrote:
>
>
> On 07.05.19 19:25, Andreas Dannenberg wrote:
> > Introduce a framework that allows loading the System Firmware (SYSFW)
> > binary as well as the associated configuration data from an image tree
> > blob named
Implement unloading of images in the Exit() boot services:
* unload images that are not yet started,
* unload started applications,
* unload drivers returning an error.
Signed-off-by: Heinrich Schuchardt
---
v2
Images that are no yet started can be unloaded by calling Exit().
In
Am 07.05.19 um 13:37 schrieb Simon Goldschmidt:
> On Tue, May 7, 2019 at 9:41 AM Wolfgang Grandegger
> wrote:
>>
>>
>>
>> Am 06.05.19 um 22:16 schrieb Simon Goldschmidt:
>>> Am 06.05.2019 um 17:45 schrieb Wolfgang Grandegger:
Re-add support for Aries Embedded MCV SoM, which is CycloneV
Right now rockchip platform need to copy bl31.elf into u-boot
source directory to make use of building u-boot.itb.
So, add environment variable BL31 like Allwinner SoC so-that the
bl31.elf would available via BL31.
If the builds are not exporting BL31 env, the make_fit_atf.py
explicitly create
Right now puma rk3399 board need to copy bl31-rk3399.bin and
rk3399m0.bin into u-boot source directory to make use of building
u-boot.itb.
So, add environment variable
- BL31 for bl31.bin (instead of bl31-rk3399.bin to compatible with other
platform BL31 env)
- PMUM0 for rk3399m0.bin
If the
Add u-boot.itb BUILD_TARGET for Rockchip platform when SPL_LOAD_FIT
is being used.
This can get rid of building itb explicitly with 'make u-boot.itb'
so, from now all required images will build just by make.
Signed-off-by: Jagan Teki
---
Kconfig | 2 +-
doc/README.rockchip | 2 --
Currently rockchip platform is using explicit 'make u-boot.itb' for
building u-boot.itb but if we enable CONFIG_BUILD_TARGET as 'u-boot.itb'
then the resulting u-boot.itb directly will create by make.
But, that indeed make travis build fail since it require python-pyelftools
host package.
So add
Rockchip platform has its python script that would generate various
bl31_*bin for creating u-boot.itb file by taking bl31.elf as input.
These bl31_*.bin files are generated in u-boot root directory and
have no rule to clean it up. so add support for it by adding in
command entry of clean target
binman tools for creating single image build will create image.map
at the end, which has information about binman image node details.
current u-boot, is unable to clean this image.map so add a command
entry in clean target in Makefile.
Signed-off-by: Jagan Teki
---
Makefile | 3 ++-
1 file
RK3399 TPL changes are merged recently which I was thinking
of waiting for next MW. so this series skip binman changes
from previous version[1] and have only BUILD_TARGET changes.
BINMAN changes would need another rework, where we need to consider
the TPL image as well and that would send
Add initial support for Nanopi NEO4 board.
Specification
- Rockchip RK3399
- 1GB DDR3-1866
- SD card slot
- eMMC Socket
- RTL8211E 1Gbps
- AP6212 WiFI/BT
- HDMI In/Out, DP, MIPI CSI
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- DC 5V/3A
Commit details of
Add initial support for Nanopc T4 board.
Specification
- Rockchip RK3399
- Dual-Channel 4GB LPDDR3-1866
- SD card slot
- 16GB eMMC
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- DC 12V/2A
Commit details
sdmmc cd pin is configured as RK_FUNC_GPIO which is wrong and
indeed failed to detect the sdcard on the board with below error
Card did not respond to voltage select!
So, fix it by replacing RK_FUNC_GPIO with RK_FUNC_1 which
is already defined in rk3399.dts so make use of same like
other
Add initial support for Nanopi M4 board.
Specification
- Rockchip RK3399
- Dual-Channel 4GB LPDDR3-1866
- SD card slot
- eMMC socket
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI
- USB 3.0 x4
- USB Type C power and data
- GPIO1, GPIO2 expansion ports
- DC5V/3A
Commit details
Few SPL and U-Boot proper configs are common to all rk3399 target
defconfigs, move them and select it from platform kconfig.
Moved configs:
- SPL_ATF
- SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
- SPL_LOAD_FIT
- SPL_CLK if SPL
- SPL_PINCTRL if SPL
- SPL_RAM if SPL
- SPL_REGMAP if SPL
-
Add default SPL_FIT_GENERATOR py script for rockchip platforms if
specific target enabled SPL_LOAD_FIT.
So, this would help get rid of explicitly mentioning the default
SPL FIT generator in defconfigs. however some targets, like puma_rk3399
still require their own FIT generator so in those cases
To make successful build with dts(i) files syncing from Linux 5.1-rc2
the rk3399.dtsi would require pwm2_pin_pull_down.
So, sync the pwm2_pin_pull_down node from Linux 5.1-rc2. Since this
node is strictly not part of any commit alone, I have mentioned
Linux 5.1-rc2 tag for future reference of
Sync rk3399-nanopi4.dtsi from Linux 5.1-rc2 tag.
Linux commit details about the rk3399-nanopi4.dtsi sync:
"arm64: dts: rockchip: Add nanopi4 bluetooth"
(sha1: 3e2f0bb72be36aa6c14ee7f11ac4dd8014801030)
Signed-off-by: Jagan Teki
Reviewed-by: Paul Kocialkowski
---
Add initial support for Rockpro64 board.
Specification
- Rockchip RK3399
- 2/4GB Dual-Channel LPDDR3
- SD card slot
- eMMC socket
- 128Mb SPI Flash
- Gigabit ethernet
- PCIe 4X slot
- WiFI/BT module socket
- HDMI In/Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO
This is v7 patchset for New rk3399 boards support wrt previous
version[1]
Unfortunately initial version of creating rk3399-u-boot.dtsi and
orangepi rk3399 changes are merged, so this is rework on top of
u-boot-rockchip/master.
Overall this series add support below rk3399 boards
- NanoPI M4
-
CONFIG_SPL_TEXT_BASE was available in configs/rk3399_common.h
when the OrangePI rk3399 board supported during first
version patch.
But, later below change which move this config into Kconfig and
same has been merged in mainline tree.
"configs: move CONFIG_SPL_TEXT_BASE to Kconfig"
(sha1:
Unfortunately initial version of creating rk3399-u-boot.dtsi
has been merged, so this series is rework of previous v6 set[1]
on top of u-boot-rockchip/master
All these changes are updating rk3399-u-boot.dtsi and rk3399
board -u-boot.dtsi files and u-boot specific dts changes like
- sdram dtsi
-
1 - 100 of 318 matches
Mail list logo
