[linux-sunxi] Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[André Przywara]

On 02/04/18 13:47, Mark Kettenis wrote:

Hi,

>> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= 
>> Date: Mon, 2 Apr 2018 12:51:50 +0100
>>
>> On 02/04/18 12:20, Mark Kettenis wrote:
>>
>> 
>>
 This feature make U-Boot to have full Linux dts inside, Can't we
 implement automatic-boot-of-os distro to grab Linux dtb during
 commands stage like other distro does? Because this make few
 development struggles for U-Boot project like (few of the comments are
 repeated from previous mail, but I'm trying to group them all)
 - Unnecessary to maintain nodes which are not required for bootloader
 and which doesn't have proper dt drivers.
 - It becomes more patches for each-and-every sync.
 - We can compare the sync with Linux dt and simply apply on U-Boot
 which look not good to project growing.
 - Increase size(though it 10KB increase) it becomes unnecessary size
 from U-Boot point-of-view
>>>
>>> This is not just about booting Linux.  And even if it was, it means
>>> that you can only boot on hardware for which a full device tree is
>>> included in your distro.  So a new board that comes with a usable
>>> U-Boot in SPI flash still won't work since the right device tree isn't
>>> there.
>>
>> Ah right, I didn't even mention SPI flash in that thread. Thanks!
>>
>> Out of curiosity: what OS are you thinking about? Collecting trophies
>> here ;-) I tried the FreeBSD-current installer the other day, and it
>> worked pretty well.
> 
> OpenBSD.  ARMv8-wise, our support for Allwinner A64/H5 and Rockchip
> RK3399 is pretty decent these days and Rockchip RK3328 is coming along
> as well.

Ah, great! I didn't know that OpenBSD was that far.
Do you know of anything missing in the DT or UEFI support from mainline
U-Boot? I put firmware images on my Pine64 github repo[1] for A64 and H5
boards, which are based on 2018.03 plus this series, if you want to give
it a try.
Trying to wrap my around INSTALL.arm64, but you might be faster ;-)
Does 6.2 provide enough to work? Or shall I wait till the 15th?

>  And I'm working on Marvell 8040 support.  There is support
> for ARMv7 as well which includes many of the older Allwinner SoCs.
> We don't have the resources to build images for all the different
> boards that are out there though, which probably is the biggest
> stumbling block for getting OpenBSD to run.  Our bootloader is UEFI,

That sounds good!

> so with a recent enough U-Boot in flash the default install.fs image

Is that the FFS filesystem in the OpenBSD partition of miniroot.fs?
Which just contains the bsd.rd kernel + RAM fs?
The 6.2 directory didn't have an explicit install.fs image.

Cheers,
Andre

[1] https://github.com/apritzel/pine64/tree/master/images

> should just work.  It does on Rock64!  Otherwise you have to know the
> magic to write the U-Boot image at the right location into that image
> to make it boot.
> 
> Cheers,
> 
> Mark
> 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[André Przywara]

On 02/04/18 12:20, Mark Kettenis wrote:



>> This feature make U-Boot to have full Linux dts inside, Can't we
>> implement automatic-boot-of-os distro to grab Linux dtb during
>> commands stage like other distro does? Because this make few
>> development struggles for U-Boot project like (few of the comments are
>> repeated from previous mail, but I'm trying to group them all)
>> - Unnecessary to maintain nodes which are not required for bootloader
>> and which doesn't have proper dt drivers.
>> - It becomes more patches for each-and-every sync.
>> - We can compare the sync with Linux dt and simply apply on U-Boot
>> which look not good to project growing.
>> - Increase size(though it 10KB increase) it becomes unnecessary size
>> from U-Boot point-of-view
> 
> This is not just about booting Linux.  And even if it was, it means
> that you can only boot on hardware for which a full device tree is
> included in your distro.  So a new board that comes with a usable
> U-Boot in SPI flash still won't work since the right device tree isn't
> there.

Ah right, I didn't even mention SPI flash in that thread. Thanks!

Out of curiosity: what OS are you thinking about? Collecting trophies
here ;-) I tried the FreeBSD-current installer the other day, and it
worked pretty well.

> So I Agree with Andre, U-Boot should provide the full device tree if
> possible.  That doesn't mean it shouldn't try to load a device tree
> from the boot media if there is one.  That way users can easily
> update/tweak their device tree without re-flashing the complete
> firmware.

Yes, users should still be able to provide their own DT, if needed.
Actually that's what I often do for Linux development myself.

Thanks!
Andre.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[André Przywara]

On 02/04/18 08:40, Jagan Teki wrote:

Hi Jagan,

> On Thu, Mar 29, 2018 at 2:49 PM, Andre Przywara  
> wrote:
>> Hi,
>>
>> On 29/03/18 09:51, Jagan Teki wrote:
>>> Hi Andre,
>>>
>>> On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara  
>>> wrote:
 A minor update to the v3 version sent earlier this month.
 I reworked patch 09 to drop the direct MMC environment for 32-bit Allwinner
 boards as well and keep the current MMC offset.
 For now I also dropped the two patches changing (back) the MMC regulator.
 I still believe they are good to have and keep them as U-Boot specific
 .dtsi files in my tree, possibly posting them later again.

 As the previous version, this combines the EMAC DT support update with
 an update of the full Linux kernel DTs for all H3, H5 and A64 boards.

 Patch 01 leaves some hint in the README how to avoid the situation
 when overrunning U-Boot's image size on 64-bit boards.
 The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
 EMAC driver for using the new DT binding used in Linux, also updates
 the DTs to the new EMAC DT node already.

 Changes to sync the whole of U-Boot's DT files for the H3, H5 and A64 SoCs
 to those from Linux are in the following patches. However this first 
 requires
 lifting the space limit we currently have due to the raw MMC environment.
 Patch 09 disables that for all sunxi boards, to give us finally some
 space. Patches 10 and 11 consequently revert the disabling of features we
 saw a few weeks ago to migitate the size problem.

 Patches 12-19 then bring in the Linux DTs, split by SoCs, with the .dtsi
 files first, then the board files.

 Merging the H3 and H5 device tree files brings in significant changes,
 also to the structure of the .dtsi files. However U-Boot's own DT usage
 is pretty limited, so it doesn't matter.

 The huge benefit of syncing the DTs is that we can use U-Boot's DT copy
 to directly pass it to the kernel, avoiding to actually load a .dtb file
 from somewhere. To allows seamless and automatic UEFI booting, so
 distribution installer images should just work (TM).

 As a goodie the final patch brings in the actual SoPine + baseboard DT
 files, which we were completely missing so far.

 This is based on sunxi/master (2d53018a0ef2).

 Cheers,
 Andre.

 Changelog v3 .. v4:
 - remove MMC environment for all Allwinner boards (including 32 bit ones)
 - keep MMC environment offset to the old values
 - drop DT adjustments to use fixed MMC regulator

 Changelog v2 .. v3:
 01: added, was on the list before
 02: drop redundant H5 line
 03-08: unchanged
 09-20: added

 Changelog v1 .. v2:
 01, 02, 03: unchanged
 04, 05, 06, 07: added

 Andre Przywara (19):
   sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted
 Firmware
   sunxi: gpio: add missing compatible strings
   net: sun8i-emac: support new pinctrl DT bindings
   net: sun8i-emac: add support for new EMAC DT binding
   arm: dts: sunxi: update A64 to new EMAC binding
   arm: dts: sunxi: update H3 to new EMAC binding
   arm: dts: sunxi: update H5 to new EMAC binding
   net: sun8i-emac: remove support for old binding
   sunxi: disable direct MMC environment
   sunxi: revert disabling of features
   Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT"
   sunxi: DT: A64: update device tree file for Allwinner A64 SoC
   sunxi: DT: A64: update board .dts files from Linux
   sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs
   sunxi: DT: H5: update board .dts files from Linux
   sunxi: DT: H3: update board .dts files from Linux
   sunxi: DT: H3: update libre-cc board .dts file
   sunxi: DT: H2+: update Opi-zero .dts
   sunxi: DT: A64: add proper SoPine baseboard device tree
>>>
>>> I agree that we have space for now with U-Boot proper since we removed
>>> MMC raw, but why we need to Sync all the dts nodes from Linux?
>>
>> The main reason for me is to allow passing U-Boot's DT to Linux - or any
>> other OS, for that matter. This happens already automatically with the
>> distro defaults UEFI boot: just put in an UEFI enabled USB pen drive
>> (distro installers) and U-Boot will boot from there - without any user
>> interaction or special boot script, without the OS providing any DTs.
>>
>> Conceptually there is only one DT for each board. The fact that U-Boot
>> has deviated has no technical reason, it's just not being updated.
>>
>>> it is costing some space right?
>>
>> We don't care about this so much anymore. For practical reasons it would
>> be good to stay below 984KB (from after the SPL till 1MB, where the
>> first partition normally starts). Adding like 10 KB to the 

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[André Przywara]

Hi,

On 02/04/18 03:30, Simon Glass wrote:
> 
> Hi Andre,
> 
> On 2 April 2018 at 09:43, André Przywara  wrote:
>> Hi,
>>
>> On 01/04/18 14:19, Tom Rini wrote:
>>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
 On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
> Hi Tom,
>
> On 7 August 2017 at 09:39, Tom Rini  wrote:
>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>>
>>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
>>> code, with #ifdefs and different code paths. We should try to move over 
>>> to
>>> this soon so we can drop the old code.

 I hope this will applicable to SPL too?

 If so, we are having SPL size issues with few Allwinner families, if
 enable SPL_DM any suggestions?
>>>
>>> How close, and have you looked at the u-boot-spl.map to see what you can
>>> maybe trim?  Or areas to look at reducing in code complexity?
>>
>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
>> and picked most low hanging fruits already.
>> So far we discussed several mitigations, but mostly to cover the
>> "natural" SPL code size grow over time:
>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
>> padding (for a 2KB architectural alignment). Given that the vectors are
>> used only for debugging purposes, we could scrap them entirely or
>> construct them on the fly in some other SRAM. So would free about 2.5KB,
>> ideally. Lowest hanging fruit so far.
>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
>> encoding. This reduces the size significantly, to about 20KB. The
>> disadvantage is using a second cross-compiler or even a additional
>> cross-compiler for native builds, complicating the build process.
>> I maintain a branch for enabling FEL booting here [1], which provides
>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
>> There are no technical disadvantages in running the SPL in 32-bit, so
>> this is mostly a build issue.
> 
> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
> ARMv7. It should be fairly easy to do,

Yes, but this is merely different compiler *flags*, to the same (cross)
compiler binary. ARM32 and ARM64 are different architectures to GCC, so
require different compiler binaries with different prefixes.
Last time I checked this wasn't easy to integrate into the U-Boot build
system.
One hack could be a "switching script", which filters for, say -m32",
and calls the respective binary. But still we need to somehow set *two*
CROSS_COMPILE prefixes. CROSS_COMPILE_SPL, maybe?
But still it would require to install *two* cross compilers, and would
spoil a completely native build by still requiring a cross compiler.

>> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
>> size and sizeof(long) to be 32-bit and should help, though I haven't
>> been able to successfully compile it yet (relocation types problems).
>> Despite lacking mainline support for AArch64 ILP32 in Linux and
>> glibc(?), GCC supports it for quite a while already. Unknown saving effect.
>> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
>> the 32KB, so we could leverage this. Siarhei knows more about this.
>> 5) Use a TPL. Haven't looked at this in detail yet.
>>
>> So 1) would be the easiest to pursue, but 2.5KB are not enough to offset
>> the >10 KB toll the DM_SPL support actually takes.
> 
> Is this the cost on 64-bit?

Yes, this is AArch64, just enabling DM_SPL_MMC and DM_SPL.

> I wonder if CONFIG_OF_PLATDATA might be an option?

Well, this would be a requirement, I guess, since adding any kind of DT
to the mix makes it even worse.

Cheers,
Andre

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Jagan Teki]

On Mon, Apr 2, 2018 at 7:13 AM, André Przywara  wrote:
> Hi,
>
> On 01/04/18 14:19, Tom Rini wrote:
>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
>>> On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
 Hi Tom,

 On 7 August 2017 at 09:39, Tom Rini  wrote:
> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>
>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
>> code, with #ifdefs and different code paths. We should try to move over 
>> to
>> this soon so we can drop the old code.
>>>
>>> I hope this will applicable to SPL too?
>>>
>>> If so, we are having SPL size issues with few Allwinner families, if
>>> enable SPL_DM any suggestions?
>>
>> How close, and have you looked at the u-boot-spl.map to see what you can
>> maybe trim?  Or areas to look at reducing in code complexity?
>
> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
> and picked most low hanging fruits already.
> So far we discussed several mitigations, but mostly to cover the
> "natural" SPL code size grow over time:
> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
> padding (for a 2KB architectural alignment). Given that the vectors are
> used only for debugging purposes, we could scrap them entirely or
> construct them on the fly in some other SRAM. So would free about 2.5KB,
> ideally. Lowest hanging fruit so far.
> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
> encoding. This reduces the size significantly, to about 20KB. The
> disadvantage is using a second cross-compiler or even a additional
> cross-compiler for native builds, complicating the build process.
> I maintain a branch for enabling FEL booting here [1], which provides
> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
> There are no technical disadvantages in running the SPL in 32-bit, so
> this is mostly a build issue.

May be this can be a good option and it has verified with board. As
Simon pointed tegra for this matter about building two arch's I think
we can try this out. I made some know change in arm/Makefile but
unable to export armv7 and armv8 compilers so-that build can pick
based on SPL and U-Boot?

--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -24,6 +24,8 @@ arch-$(CONFIG_ARM64)  =-march=armv8-a
 # but otherwise we can use the value in CONFIG_SYS_ARM_ARCH
 ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TEGRA),yy)
 arch-y += -D__LINUX_ARM_ARCH__=4
+else ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_MACH_SUN50I),yy)
+arch-y += -D__LINUX_ARM_ARCH__=7
 else
 arch-y += -D__LINUX_ARM_ARCH__=$(CONFIG_SYS_ARM_ARCH)
 endif

> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
> size and sizeof(long) to be 32-bit and should help, though I haven't
> been able to successfully compile it yet (relocation types problems).
> Despite lacking mainline support for AArch64 ILP32 in Linux and
> glibc(?), GCC supports it for quite a while already. Unknown saving effect.
> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
> the 32KB, so we could leverage this. Siarhei knows more about this.
> 5) Use a TPL. Haven't looked at this in detail yet.

I think it's difficult to implement TPL here because, we should
require same SPL code for TPL like cpu, clock, DRAM and MMC(for boot
mode) butif we have a way to return from BootROM once TPL loaded(like
rockchip does) so-that we can skip MMC code from TPL.

Jagan.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.