After the dividers of PLL-CPUX disabled, there's no need for PLL-CPUX to
be gated when tweaking the clock of CPUX, thus reparenting CPUX to
osc24M is also now not needed.
Remove these notifiers.
Preventing reparenting CPUX is said to be able to help solving the issue
that the timer jumps
According to Ondrej Jirman, switching of the mux of CPUX clock is one of
the sources of timer jumps on A64 (and maybe this will also lead to
timer jump on H3).
This patchset tries to remove this mux by disabling the dividers in
PLL-CPUX. Both the lack of reparent when relocking and the prevention
According to the user manual, PLL-CPUX have two dividers, in which P is
only allowed when the desired rate is less than 240MHz. As the CCU
framework have no such feature yet and the clock rate that allows P is
much lower than where we normally operate, disallow the usage of P
factor now.
M is not
For this board, there is another issue regarding regulators.
The fix is still being discussed. See
https://lore.kernel.org/lkml/20201021183149.GA8436@Red/t/
On Tue, Oct 20, 2020 at 5:22 AM JuanEsf wrote:
>
> Hi!
> In BananaPi-M2 Ultra also the problem occurred when updating to the kernel.
>
On 08/11/2020 14:59, Peter Robinson wrote:
Hi,
> On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara wrote:
>>
>> The eMMC standard describes the concept of boot partitions, consisting
>> of two storage areas separate from the main user data partition.
>> The Allwinner BootROM supports loading
On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara wrote:
>
> The eMMC standard describes the concept of boot partitions, consisting
> of two storage areas separate from the main user data partition.
> The Allwinner BootROM supports loading SPL/Boot0 from such a boot
> partition, if that is configured
Dne nedelja, 08. november 2020 ob 15:44:54 CET je Marc Haber napisal(a):
> On Mon, Oct 19, 2020 at 12:14:29PM +0800, Chen-Yu Tsai wrote:
> > The proper fix now is to check the schematics, and change the phy-mode
> > property to the correct type. It used to be that we used "rgmii" for all
> > RGMII
On Mon, Oct 19, 2020 at 12:14:29PM +0800, Chen-Yu Tsai wrote:
> The proper fix now is to check the schematics, and change the phy-mode
> property
> to the correct type. It used to be that we used "rgmii" for all RGMII PHYs.
>
> Turns out there are four modes of RGMII, depending on whether the
Now that the SPL can detect whether it was loaded from an eMMC boot
partition or the normal user data partition, let's enable this feature
on some boards that feature eMMC storage.
That covers the boards where I could test this on.
Signed-off-by: Andre Przywara
---
Platforms can overwrite the weak definition of spl_mmc_boot_mode() to
determine where to load U-Boot proper from.
For most of them this is a trivial decision based on Kconfig variables,
but it might be desirable the probe the actual device to answer this
question.
Pass the pointer to the mmc
When the Allwinner BROM loads the SPL from an eMMC boot partition, it
sets the boot source byte to the same value as when booting from the
user data partition. This prevents us from easily determining the boot
source to load U-Boot proper from the proper partition.
To learn about the boot source
The Allwinner BROM also supports loading the SPL from the eMMC boot
partition, for this we have to set the CONFIG_SUPPORT_EMMC_BOOT Kconfig
symbol. But on top of that a user has to manually adjust the raw sector
to load U-Boot proper from: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR.
To simplify
The is_boot0_magic macro is missing parentheses around the macro
argument, breaking any usage with a more complex argument.
Signed-off-by: Andre Przywara
---
arch/arm/include/asm/arch-sunxi/spl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The eMMC standard describes the concept of boot partitions, consisting
of two storage areas separate from the main user data partition.
The Allwinner BootROM supports loading SPL/Boot0 from such a boot
partition, if that is configured in the eMMC device [1].
To load U-Boot proper along with the
14 matches
Mail list logo
