The sandbox should closely mimic other architectures.
Place each function or data in a separate section and let the linker
eliminate unused ones. This will reduce the binary size.
Signed-off-by: Heinrich Schuchardt
---
arch/sandbox/config.mk | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
When compiling the sandbox with CONFIG_LTO=n, CONFIG_NET=n an error is
reported:
/usr/bin/ld: lib/efi_loader/efi_device_path.o:
in function `efi_dp_from_eth':
lib/efi_loader/efi_device_path.c:985:(.text+0xcf4):
undefined reference to `eth_get_dev'
Add a missing configuration check
On 10/21/23 20:26, Tom Rini wrote:
On Sat, Oct 21, 2023 at 08:43:08AM -0700, Simon Glass wrote:
Hi,
On Thu, 19 Oct 2023 at 17:30, AKASHI Takahiro
wrote:
On Thu, Oct 19, 2023 at 08:01:11AM -0600, Simon Glass wrote:
Hi Heinrich,
On Wed, 18 Oct 2023 at 06:55, Heinrich Schuchardt wrote:
On
On 10/21/23 17:42, Simon Glass wrote:
Hi Tom,
On Fri, 20 Oct 2023 at 09:24, Tom Rini wrote:
On Fri, Oct 20, 2023 at 05:40:03PM +0200, Heinrich Schuchardt wrote:
On 20.10.23 15:21, Simon Glass wrote:
+Doug Anderson
Hi Heinrich,
On Thu, 19 Oct 2023 at 09:09, Heinrich Schuchardt
wrote:
On
Hi Andre,
On 9/28/23 16:54, Andre Przywara wrote:
> The Allwinner R528/T113-s/D1/D1s SoCs all share the same die, so use the
> same DRAM initialisation code.
> Make use of prior art here and lift some code from awboot[1], which
> carried init code based on earlier decompilation efforts, but with a
Hi Andre,
On 9/28/23 16:54, Andre Przywara wrote:
> At the moment all Allwinner DRAM initialisation routines are stored in
> arch/arm/mach-sunxi, even though those "drivers" are just a giant
> collection of writel's, without any architectural dependency.
>
> The R528/T113-s SoC (with ARM cores) a
Hi Andre,
On 9/28/23 16:54, Andre Przywara wrote:
> Allwinner seems to typically stick to a common MMIO memory map for
> several SoCs, but from time to time does some breaking changes, which
> also introduce new generations of some peripherals. The last time this
> happened with the H6, which apar
On 10/21/23 18:27, Andre Przywara wrote:
> On Thu, 19 Oct 2023 18:51:30 -0500
> Samuel Holland wrote:
>
> Hi Samuel,
>
> thanks for having a look!
>
>> On 9/28/23 16:54, Andre Przywara wrote:
>>> The CONFIG_SATAPWR Kconfig symbol was used to point to a GPIO that
>>> enables the power for a SATA
Hi Andre,
On 9/28/23 16:54, Andre Przywara wrote:
> For the first time since at least the Allwinner A10 SoCs, the D1 (and
> related cores) use a new pincontroller MMIO register layout, so we
> cannot use our hardcoded, fixed offsets anymore.
> Ideally this would all be handled by devicetree and DM
On Wed, 11 Oct 2023 19:47:52 -0600
Sam Edwards wrote:
Hi Sam,
> Hi list,
>
> This is the third, and hopefully final, version of my patchset for PSCI
> support
> on R528/T113-s3. This one, as always, depends on Andre Przywara's T113s
> support
> series (v2), available on the list and also loca
On Wed, 11 Oct 2023 19:47:56 -0600
Sam Edwards wrote:
> This patch adds the necessary code to make nonsec booting and PSCI
> secondary core management functional on the R528/T113.
>
> Signed-off-by: Sam Edwards
> Tested-by: Maksim Kiselev
> Tested-by: Kevin Amadiva
Thanks, that looks good no
On Wed, 11 Oct 2023 19:47:55 -0600
Sam Edwards wrote:
> Since the sunxi support nowadays generally prefers #defined register
> offsets instead of modeling register layouts using C structs, now is a
> good time to do this for PSCI as well. This patch moves away from using
> the structs `sunxi_cpuc
On Sat, 21 Oct 2023 03:30:48 -0500
Samuel Holland wrote:
> Hi Andre,
>
> On 9/28/23 16:54, Andre Przywara wrote:
> > So far we were open-coding the pincontroller's GPIO output/input access
> > in each function using that.
> >
> > Provide functions that wrap that nicely, and follow the existing
On Thu, 19 Oct 2023 19:01:30 -0500
Samuel Holland wrote:
Hi,
> Hi Andre,
>
> On 9/28/23 16:54, Andre Przywara wrote:
> > At the moment the sun4i EMAC driver relies on hardcoded CONFIG_MACPWR
> > Kconfig symbols to enable potential PHY regulators. As we want to get rid
> > of those, we need to f
On Thu, 19 Oct 2023 18:51:30 -0500
Samuel Holland wrote:
Hi Samuel,
thanks for having a look!
> On 9/28/23 16:54, Andre Przywara wrote:
> > The CONFIG_SATAPWR Kconfig symbol was used to point to a GPIO that
> > enables the power for a SATA harddisk.
> > In the DT this is described with the targ
On Sat, 21 Oct 2023 08:51:09 +0200
Jernej Škrabec wrote:
> On Wednesday, October 18, 2023 5:50:14 PM CEST Andre Przywara wrote:
> > The X-Powers AXP313a is a small PMIC with just three buck converters and
> > three LDOs, one of which is actually fixed (so not modelled here).
> >
> > Add the comp
On Sat, 21 Oct 2023 08:34:06 +0200
Jernej Škrabec wrote:
> On Wednesday, October 18, 2023 5:50:12 PM CEST Andre Przywara wrote:
> > So far we have a convoluted #ifdef mesh that guards the early AXP PMIC
> > setup in board.c. That combination of &&, || and negations is very hard
> > to read, maint
On Wed, Oct 18, 2023 at 8:28 AM Qi Feng wrote:
> From: Wei Chen >
> Add MMC disk to FVP's BOOT_TARGET_DEVICES. This allows the user to boot
> from MMC devices.
>
> Signed-off-by: Wei Chen
> Signed-off-by: Qi Feng
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Wed, Oct 18, 2023 at 8:28 AM Qi Feng wrote:
> From: Wei Chen
>
> In current vexpress_config_probe code, it sets the uclass private data
> directly. This will cause one compilation error:
> drivers/misc/vexpress_config.c:114:27: error: lvalue required as left operand
> of assignment
> 114 |
On Sat, Oct 21, 2023 at 08:43:00AM -0700, Simon Glass wrote:
> On Fri, 20 Oct 2023 at 14:53, Tom Rini wrote:
> >
> > The primary motivation for having a sandbox without LTO build in CI is
> > to ensure that we don't have that option break. We now have the ability
> > to run tests of specific optio
On Sat, Oct 21, 2023 at 08:43:08AM -0700, Simon Glass wrote:
> Hi,
>
> On Thu, 19 Oct 2023 at 17:30, AKASHI Takahiro
> wrote:
> >
> > On Thu, Oct 19, 2023 at 08:01:11AM -0600, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Wed, 18 Oct 2023 at 06:55, Heinrich Schuchardt
> > > wrote:
> > >
Hi Tom,
On Thu, 19 Oct 2023 at 07:57, Tom Rini wrote:
>
> On Thu, Oct 19, 2023 at 08:00:00AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 18 Oct 2023 at 20:32, Tom Rini wrote:
> > >
> > > On Mon, Oct 16, 2023 at 04:28:23PM -0600, Simon Glass wrote:
> > >
> > > > Now that everything is w
Hi Raymond,
On Fri, 20 Oct 2023 at 15:15, Raymond Mao wrote:
>
> Hi Simon,
>
> On Thu, 21 Sept 2023 at 04:58, Simon Glass wrote:
> >
> > Standard passage provides for a bloblist to be passed from one firmware
> > phase to the next. That can be used to pass the devicetree along as well.
> > Add a
Hi,
On Thu, 19 Oct 2023 at 17:30, AKASHI Takahiro
wrote:
>
> On Thu, Oct 19, 2023 at 08:01:11AM -0600, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Wed, 18 Oct 2023 at 06:55, Heinrich Schuchardt
> > wrote:
> > >
> > > On 10/17/23 16:09, Tom Rini wrote:
> > > > On Mon, Oct 16, 2023 at 04:28:13
On Fri, 20 Oct 2023 at 14:53, Tom Rini wrote:
>
> The primary motivation for having a sandbox without LTO build in CI is
> to ensure that we don't have that option break. We now have the ability
> to run tests of specific options being enabled/disabled, so drop the
> parts of CI that build and tes
Hi Tom,
On Fri, 20 Oct 2023 at 09:24, Tom Rini wrote:
>
> On Fri, Oct 20, 2023 at 05:40:03PM +0200, Heinrich Schuchardt wrote:
> > On 20.10.23 15:21, Simon Glass wrote:
> > > +Doug Anderson
> > >
> > > Hi Heinrich,
> > >
> > > On Thu, 19 Oct 2023 at 09:09, Heinrich Schuchardt
> > > wrote:
> > >
From: Benjamin Szőke
Technexion PICO-IMX7 SoM is supporting USDHC3 (eMMC or micro SD on SoM)
and USDHC1 (SD on carrier board) to use on any carrier board like
PICO-NYMPH. This pacth is intend to take over codes from Technexion
to support mmc autodetect boot for pico-imx7d to able to boot from
sel
> I'm fine with the current approach if Gunjan confirms that initialization
> works reliably.
I will test it out over the coming week. Too sick to even pick up the
laptop right now.
Regards
Gunjan
Hi Simon,
On Thu, 21 Sept 2023 at 04:58, Simon Glass wrote:
>
> Standard passage provides for a bloblist to be passed from one firmware
> phase to the next. That can be used to pass the devicetree along as well.
> Add an option to support this.
>
> Tests for this will be added as part of the Univ
On 9/28/23 16:54, Andre Przywara wrote:
> U-Boot's generic GPIO_EXTRA_HEADER is a convenience symbol to allow code
> to more easily include platform specific GPIO headers. This should not
> be needed in a DM world anymore, since the generic GPIO framework
> handles that nicely.
> For Allwinner boar
Hi Simon,
On 21/10/2023 01:45, Simon Glass wrote:
U-Boot typically sets up its malloc() pool near the top of memory. On
ARM64 systems this can result in an SMBIOS table above 4GB which is
not supported by SMBIOSv2.
Work around this problem by providing a new option to choose an address
just bel
Hi Andre,
On 9/28/23 16:54, Andre Przywara wrote:
> So far every Allwinner SoC used the same basic pincontroller/GPIO
> register frame, and just differed by the number of implemented banks and
> pins, plus some special functionality from time to time. However the D1
> and successors use a slightly
Hi Andre,
On 9/28/23 16:54, Andre Przywara wrote:
> So far we were open-coding the pincontroller's GPIO output/input access
> in each function using that.
>
> Provide functions that wrap that nicely, and follow the existing pattern
> (set/get_{bank,}), so users don't need to know about the intern
Hi Andre,
On 9/28/23 16:54, Andre Przywara wrote:
> Move the existing sunxi-specific low level pinctrl routines from
> arch/arm/mach-sunxi into the existing GPIO code under drivers/gpio, so
> that the common code can be shared outside of arch/arm.
>
> This also takes the opportunity to move some
On Friday, October 20, 2023 2:26:05 AM CEST Andre Przywara wrote:
> This updates the devicetree files to match the Linux kernel repository
> as of v6.6-rc6.
> Mostly cosmetic changes, but we gain some new board files and the T113s
> board .dtsi files, which are needed for the pending U-Boot patches
35 matches
Mail list logo
