On Sat, Sep 18, 2021 at 9:56 PM Mark Kettenis wrote:
>
> Provide preliminary instructions on how to get U-Boot to run on
> Apple Silicon Macs.
>
> Signed-off-by: Mark Kettenis
> ---
> doc/board/apple/index.rst | 9 +++
> doc/board/apple/m1.rst| 56
Hi Mark,
On Sun, Sep 19, 2021 at 9:04 AM Bin Meng wrote:
>
> Hi Mark,
>
> On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis wrote:
> >
> > Add support for Apple's M1 SoC that is used in "Apple Silicon"
> > Macs. This builds a basic U-Boot that can be used as a payload
> > for the m1n1 boot loader
Hi Mark,
On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis wrote:
>
> Apple M1 SoCs include an S5L UART which is a variant of the S5P
> UART. Add support for this variant and enable it by default
> on Apple SoCs.
>
> Signed-off-by: Mark Kettenis
> ---
> arch/arm/include/asm/arch-m1/clk.h | 11
Hi Mark,
On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis wrote:
>
> Add support for Apple's M1 SoC that is used in "Apple Silicon"
> Macs. This builds a basic U-Boot that can be used as a payload
> for the m1n1 boot loader being developed by the Asahi Linux
> project.
>
> Signed-off-by: Mark
Am 18. September 2021 18:04:13 MESZ schrieb Alec Brown
:
>Hi everyone,
>
>I've been working on improving the specification for the firmware and
>bootloader
>log that Daniel Kiper has proposed and take into account most of the
>suggestions
>that were made in these threads [1], [2].
>
>The
The Kconfig feature was added in 2014. Some 7 years later there are still
quite a few CONFIG options that have not been migrated. It is time to
close this out.
Add a deadline and a warning for boards to migrate to Kconfig.
Signed-off-by: Simon Glass
---
Makefile | 10 ++
1 file
Hi everyone,
I've been working on improving the specification for the firmware and bootloader
log that Daniel Kiper has proposed and take into account most of the suggestions
that were made in these threads [1], [2].
The goal is to allow various boot components to pass logs to the running OS and
Hi,
Is there something screwy with this? It seems that denx-vulcan does
two builds at once?
https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/323540
Regards,
SImon
Hi Tom,
On Sat, 18 Sept 2021 at 07:16, Tom Rini wrote:
>
> On Sat, Sep 18, 2021 at 03:34:54AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 16 Sept 2021 at 12:40, Tom Rini wrote:
> > >
> > > On Wed, Aug 18, 2021 at 09:40:32PM -0600, Simon Glass wrote:
> > >
> > > > Provide a way for
Hi François,
On Sat, 18 Sept 2021 at 06:44, François Ozog
wrote:
>
>
> On Sat, 18 Sept 2021 at 14:23, Ilias Apalodimas <
> ilias.apalodi...@linaro.org> wrote:
>
>> Hi Simon
>>
>> Top posting again apologies.
>> I am fine with whatever really. I've spent more time arguing about it
>> than coding
Hi Mark,
On Sat, 18 Sept 2021 at 05:15, Mark Kettenis wrote:
>
> > From: Simon Glass
> > Date: Sat, 18 Sep 2021 03:27:48 -0600
> >
> > Hi Tom,
> >
> > On Fri, 17 Sept 2021 at 11:26, Tom Rini wrote:
> > >
> > > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > > Hi Mark,
> > >
Provide preliminary instructions on how to get U-Boot to run on
Apple Silicon Macs.
Signed-off-by: Mark Kettenis
---
doc/board/apple/index.rst | 9 +++
doc/board/apple/m1.rst| 56 +++
doc/board/index.rst | 1 +
3 files changed, 66
Add preliminary device trees for the Apple M1 mini (2020) and
Apple M1 Macbook Pro 13" (2020). Device tree bindings for
the Apple M1 SoC are still being formalized and these device
trees will be synchronized with the Linux kernel as needed.
These device trees are provided as a reference only as
The DART is an IOMMU that is used on Apple's M1 SoC. This driver
supports the DART in bypass mode as well as in a mode where it
creates a 1:1 mapping of a subset of RAM as not all DARTs support
bypass mode. The USB3 ports integrated on the SoC use a DART
that supports bypass mode. The 1:1
Apple M1 SoCs include an S5L UART which is a variant of the S5P
UART. Add support for this variant and enable it by default
on Apple SoCs.
Signed-off-by: Mark Kettenis
---
arch/arm/include/asm/arch-m1/clk.h | 11
arch/arm/include/asm/arch-m1/uart.h | 41 +
Add support for Apple's M1 SoC that is used in "Apple Silicon"
Macs. This builds a basic U-Boot that can be used as a payload
for the m1n1 boot loader being developed by the Asahi Linux
project.
Signed-off-by: Mark Kettenis
---
arch/arm/Kconfig| 22
arch/arm/Makefile
This series adds basic support for Apple's M1 SoC to U-Boot.
This builds a basic U-Boot that can be used as a payload
for the m1n1 boot loader being developed by the Asahi Linux
project.
The goal here is to privide an UEFI interface on these machines that
allows booting various open source OSes.
I will try to learn how to create a dtbo, and do a PR to documentation. I
ain't an embedded or kernel guru like you guys.
I have a complete security background with primarily appsec :)
But I agree that we should have some documentation because
1. It's a common reference platform
2. At the moment
Tbh, the reason why I didn't do overlay is that I am not comfortable with
it. I still have to learn how to do dtbo, and that is why I didn't add a PR
to the documentation. I understand adding a dtbo is more robust and better
way.
What I replaced with was a copy of the original device tree that
On Sat, Sep 18, 2021 at 03:27:40AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 17 Sept 2021 at 11:42, Tom Rini wrote:
> >
> > On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 15 Sept 2021 at 07:35, Tom Rini wrote:
> > > >
> > > > On Wed, Sep 15,
On Sat, Sep 18, 2021 at 03:38:45AM -0600, Simon Glass wrote:
> Hi,
>
> On Fri, 10 Sept 2021 at 16:44, Tom Rini wrote:
> >
> > On Sat, Sep 11, 2021 at 12:09:40AM +0200, Mark Kettenis wrote:
> > > > Date: Fri, 10 Sep 2021 17:17:37 -0400
> > > > From: Tom Rini
> > > >
> > > > On Fri, Sep 10, 2021
On Sat, Sep 18, 2021 at 03:34:54AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 16 Sept 2021 at 12:40, Tom Rini wrote:
> >
> > On Wed, Aug 18, 2021 at 09:40:32PM -0600, Simon Glass wrote:
> >
> > > Provide a way for sandbox MMC to present data from a backing file. This
> > > allows a
Make the Freescale/NXP TSEC driver listen to the phy-mode or
phy-connection-type OF property.
Currently there is an attempt to auto-determine the PHY mode, only do
that if the phy-mode string is not specified.
Also, be compatible with phy-mode, right now the driver only parses
The two should be equivalent, but at the moment some platforms
(ls1021a-tsn.dts) use phy-mode only, which is not parsed.
Signed-off-by: Vladimir Oltean
---
drivers/net/tsec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index
Currently the init_phy function may overwrite the priv->interface
property, since it calls tsec_get_interface which tries to determine it
dynamically based on default register values in ECNTRL.
Let's do that only if phy-connection-type happens to not be defined in
the device tree.
Signed-off-by:
On Sat, 18 Sept 2021 at 14:23, Ilias Apalodimas
wrote:
> Hi Simon
>
> Top posting again apologies.
> I am fine with whatever really. I've spent more time arguing about it than
> coding it :)
>
> Regardless of revert or no, we must dedicate enough energy ASAP to
conceptualize what we are
After the discussion here:
https://lore.kernel.org/netdev/20210603143453.if7hgifupx5k433b@pali/
which resulted in this patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20210704134325.24842-1-p...@kernel.org/
and many other discussions before it, notably:
The enetc driver runs only on NXP LS1028A, which most definitely does
not support the parallel 10G interface, just USXGMII, and that only up
to 2.5Gbps (toned down from 10 Gbps via symbol replication).
Signed-off-by: Vladimir Oltean
---
drivers/net/fsl_enetc.c | 2 --
1 file changed, 2
The felix driver runs only on NXP LS1028A, which most definitely does
not support the parallel 10G interface, just USXGMII, and that only up
to 2.5Gbps (toned down from 10 Gbps via symbol replication).
Signed-off-by: Vladimir Oltean
---
drivers/net/mscc_eswitch/felix_switch.c | 1 -
1 file
As part of the effort of making U-Boot work with the same device tree as
Linux, there is an issue with the "xfi" phy-mode. To be precise, in
Linux there was a discussion (for those who have time to read:
https://lore.kernel.org/netdev/1576768881-24971-2-git-send-email-madalin.bu...@oss.nxp.com/)
Michael Walle did an excellent job in starting the process of bringing
U-Boot and Linux device tree bindings in sync for the NXP LS1028A:
https://patchwork.ozlabs.org/project/uboot/cover/20210902164558.1920849-1-mich...@walle.cc/
but there still are some hairy issues which need to be addressed
Hi Simon
Top posting again apologies.
I am fine with whatever really. I've spent more time arguing about it than
coding it :)
I have worked planned for this and the DM/EFI integration, so I'll update
you on the details once we start
Cheers
Ilias
On Sat, 18 Sep 2021, 15:13 Simon Glass, wrote:
Hi Tom
Yes the internal ABI and the whole functionality remains identical.
What changes is how the user includes the key in the final binary.
It's a Kconfig with the patch applied, while if we move it to the dtb the
user must add it and concat the dtb with uboot. So apart from how we build
the
On Sat, Sep 18, 2021 at 02:59:42PM +0300, Ilias Apalodimas wrote:
> +cc a few people that had some input on that discussion.
> Apologies from top posting, but I am sending this from a mobile.
>
> I think I've spent enough time trying to explain why I think we don't need
> to revert this and why
Hi Ilias,
On Sat, 18 Sept 2021 at 05:59, Ilias Apalodimas
wrote:
>
> +cc a few people that had some input on that discussion.
> Apologies from top posting, but I am sending this from a mobile.
>
> I think I've spent enough time trying to explain why I think we don't need to
> revert this and
On Sat, Sep 18, 2021 at 7:55 PM Vladimir Oltean wrote:
>
> To avoid a warning with W=1 about this function not having a previous
> prototype, declare it as static, because it is not used outside of this
> translation module.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/net/phy/phy.c | 2
+cc a few people that had some input on that discussion.
Apologies from top posting, but I am sending this from a mobile.
I think I've spent enough time trying to explain why I think we don't need
to revert this and why moving the signature to the dtb once we fix it has
minimal effect on the
To avoid a warning with W=1 about this function not having a previous
prototype, declare it as static, because it is not used outside of this
translation module.
Signed-off-by: Vladimir Oltean
---
drivers/net/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Sat, Sep 18, 2021 at 05:37:23PM +0800, Bin Meng wrote:
> There are two duplicated declarations for ft_cpu_setup() and
> ft_pci_setup().
>
> Signed-off-by: Bin Meng
> ---
Reviewed-by: Vladimir Oltean
"dev" and "dsa_pdata" are unused inside dsa_port_of_to_pdata.
"dsa_priv" is unused inside dsa_port_probe.
Signed-off-by: Vladimir Oltean
---
net/dsa-uclass.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index
This series contains a bug fix and a cleanup for W=1 builds.
Vladimir Oltean (2):
net: dsa: pass CPU port fixed PHY to .port_disable
net: dsa: remove unused variables
net/dsa-uclass.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
--
2.25.1
While adding the logic for DSA to register a fixed-link PHY for the CPU
port, I forgot to pass it to the .port_disable method too, just
.port_enable.
Bug had no impact for felix_switch.c, due to the phy argument not being
used, but ksz9477.c does use it => NULL pointer dereference.
Fixes:
Hi Tom,
This is a revert of the EFI patches as mentioned on the mailing list.
I believe this is the best way forward and avoids the current, flawed
approach from getting into an official release and making it difficult
to back out.
Hi Heinrich,
On Sat, 18 Sept 2021 at 03:54, Heinrich Schuchardt wrote:
>
>
>
> Am 18. September 2021 11:29:27 MESZ schrieb Simon Glass :
> >Hi Tom,
> >
> >On Tue, 14 Sept 2021 at 17:01, Tom Rini wrote:
> >>
> >> Hey all,
> >>
> >> Alright, I'm a day late, but, here's v2021.10-rc4. We've had a
> From: Simon Glass
> Date: Sat, 18 Sep 2021 03:27:48 -0600
>
> Hi Tom,
>
> On Fri, 17 Sept 2021 at 11:26, Tom Rini wrote:
> >
> > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > Hi Mark,
> > >
> > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis
> > > wrote:
> > > >
> > > >
Le sam. 18 sept. 2021 à 12:10, Mark Kettenis a
écrit :
> > From: Moiz Imtiaz
> > Date: Sat, 18 Sep 2021 14:47:51 +0500
> >
> > >Nice! If you want to write something up extending the >documentation on
> > >how you made this work for Pi it would be much appreciated.
> >
> > Sure, would love to
> From: Moiz Imtiaz
> Date: Sat, 18 Sep 2021 14:47:51 +0500
>
> >Nice! If you want to write something up extending the >documentation on
> >how you made this work for Pi it would be much appreciated.
>
> Sure, would love to do a PR.
>
> I basically replaced the dtb that pi loads with
Hi Tom,
On Fri, 17 Sept 2021 at 15:08, Tom Rini wrote:
>
> On Fri, Sep 17, 2021 at 11:49:51AM +, T Karthik Reddy wrote:
> > Hi Tom,
> >
> > > -Original Message-
> > > From: Tom Rini
> > > Sent: Thursday, August 5, 2021 6:53 PM
> > > To: T Karthik Reddy
> > > Cc: Ashok Reddy Soma ;
Am 18. September 2021 11:29:27 MESZ schrieb Simon Glass :
>Hi Tom,
>
>On Tue, 14 Sept 2021 at 17:01, Tom Rini wrote:
>>
>> Hey all,
>>
>> Alright, I'm a day late, but, here's v2021.10-rc4. We've had a few
>> regressions pop up of late, unfortunately. I've pushed the fix for
>> (what I
>Nice! If you want to write something up extending the >documentation on
>how you made this work for Pi it would be much appreciated.
Sure, would love to do a PR.
I basically replaced the dtb that pi loads with control Dtb of uboot, but
will do a PR of documentation addition in respect to pi_4,
Hi,
On Fri, 10 Sept 2021 at 16:44, Tom Rini wrote:
>
> On Sat, Sep 11, 2021 at 12:09:40AM +0200, Mark Kettenis wrote:
> > > Date: Fri, 10 Sep 2021 17:17:37 -0400
> > > From: Tom Rini
> > >
> > > On Fri, Sep 10, 2021 at 11:12:20PM +0200, Mark Kettenis wrote:
> > > > > Date: Fri, 10 Sep 2021
There are two duplicated declarations for ft_cpu_setup() and
ft_pci_setup().
Signed-off-by: Bin Meng
---
include/fdt_support.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/fdt_support.h b/include/fdt_support.h
index f6f46bb8e9..72a5b90c97 100644
--- a/include/fdt_support.h
+++
Hi Tom,
On Thu, 16 Sept 2021 at 12:40, Tom Rini wrote:
>
> On Wed, Aug 18, 2021 at 09:40:32PM -0600, Simon Glass wrote:
>
> > Provide a way for sandbox MMC to present data from a backing file. This
> > allows a filesystem to be created on the host and easily served via an
> > emulated mmc
Hi Sean,
On Sat, 28 Aug 2021 at 00:39, Sean Anderson wrote:
>
> On 8/18/21 11:40 PM, Simon Glass wrote:
> > Provide a way for sandbox MMC to present data from a backing file. This
> > allows a filesystem to be created on the host and easily served via an
> > emulated mmc device.
> >
> >
On Mon, 13 Sept 2021 at 21:19, Marek Vasut wrote:
>
> Allow usage of the bootstage facilities in SPL.
>
> Signed-off-by: Marek Vasut
> Cc: Simon Glass
> ---
> common/Kconfig.boot | 9 +
> include/bootstage.h | 2 +-
> 2 files changed, 10 insertions(+), 1 deletion(-)
Reviewed-by: Simon
Hi Tom,
On Tue, 14 Sept 2021 at 17:01, Tom Rini wrote:
>
> Hey all,
>
> Alright, I'm a day late, but, here's v2021.10-rc4. We've had a few
> regressions pop up of late, unfortunately. I've pushed the fix for
> (what I believe are) existing FIT images showing a problem where we
> calculated the
Hi Tom,
On Fri, 17 Sept 2021 at 11:26, Tom Rini wrote:
>
> On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > Hi Mark,
> >
> > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis
> > wrote:
> > >
> > > > From: Simon Glass
> > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > >
> > > Hi
Hi Tom,
On Fri, 17 Sept 2021 at 11:42, Tom Rini wrote:
>
> On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 15 Sept 2021 at 07:35, Tom Rini wrote:
> > >
> > > On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > > > > From: Simon Glass
> >
Tested-by: Vyacheslav Bocharov
17.09.2021 10:37, Neil Armstrong пишет:
Upstream Linux uses the "amlogic,meson-axg-usb-ctrl" for AXG SoCs.
This adds it to the compatible list for this driver.
Reported-by: Vyacheslav Bocharov
Signed-off-by: Neil Armstrong
---
On 9/18/21 8:54 AM, François Ozog wrote:
Le sam. 18 sept. 2021 à 08:49, François Ozog a
écrit :
Hi Paul
Too posting because I think we also need to address this at a higher level.
i think we discussed this topic quite a while back. I may be wrong but it
may be Bill Mills who proposed to
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/pci/pcie_layerscape_fixup_common.c | 2 +-
> 1 file changed, 1
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> The function prototype for ft_pci_setup is inside fdt_support.h, we need
> to include that header.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/pci/pcie_layerscape_fixup_common.c | 1 +
> 1 file changed, 1 insertion(+)
>
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/pci/pcie_layerscape_rc.c | 4 ++--
> 1 file changed, 2
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/pci/pci-uclass.c | 6 +++---
> 1 file changed, 3 insertions(+),
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/pci/pci-uclass.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/pci/pci-uclass.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean
> ---
> cmd/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean
> ---
> cmd/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean
> ---
> cmd/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> To avoid a build warning with W=1, provide a function prototype for
> dm_pciauto_prescan_setup_bridge, which is a non-static function whose
> definition is inside pci_auto.c.
>
> Signed-off-by: Vladimir Oltean
> ---
>
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean wrote:
>
> The weak definition of pci_skip_dev from drivers/pci/pci_common.c is not
> under CONFIG_DM_PCI_COMPAT, and that definition needs a previous
> function prototype declaration to avoid W=1 build warnings.
>
> That prototype is not available
Le sam. 18 sept. 2021 à 08:49, François Ozog a
écrit :
> Hi Paul
>
> Too posting because I think we also need to address this at a higher level.
>
> i think we discussed this topic quite a while back. I may be wrong but it
> may be Bill Mills who proposed to have an eeprom on the extensions that
Hi Paul
Too posting because I think we also need to address this at a higher level.
i think we discussed this topic quite a while back. I may be wrong but it
may be Bill Mills who proposed to have an eeprom on the extensions that the
carrier board can use to detect and fetch proper overlay.
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. In case the R5F cluster is
in lock-step mode, also initialize the second core. The firmware
From: Jan Kiszka
This allows to use the watchdog in custom scripts but does not enforce
that the OS has to support it as well.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 25
configs/iot2050_defconfig| 6 +
From: Jan Kiszka
Add the DT entry for a watchdog based on RTI1. It requires additional
firmware on the MCU R5F cores to handle the expiry, e.g.
https://github.com/siemens/k3-rti-wdt. As this firmware will also lock
the power domain to protect it against premature shutdown, mark it
shared.
From: Jan Kiszka
Prepares for the addition of the IOT2050 board which is based on the TI
AM65x. The board comes in four variants, Basic and Advanced, each as
product generation 1 (SR1.0) and 2 (SR2.x), so there are separate dts
files needed. Furthermore, the SPL has its own device tree.
Based
From: Jan Kiszka
This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.
Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is
This is the baseline support for the SIMATIC IOT2050 devices.
Changes in v8:
- rebased
- added support for product generation 2 board
- align device trees with upstream [pending] kernel version
- only warn on missing watchdog firmware binary
- removed bits only needed for incomplete prueth
79 matches
Mail list logo
