Re: [U-Boot] [U-Boot,6/6] Pine64: rename defconfig

[Alexander Graf]

On 15.05.16 14:49, André Przywara wrote:
> On 15/05/16 11:30, Hans de Goede wrote:
>> Hi,
>>
>> On 04-05-16 23:15, Andre Przywara wrote:
>>> Rename the defconfig file for the Pine64 from pine64_plus_defconfig to
>>> pine64_defconfig.
>>> The differences between the two versions (more RAM and a different
>>> Ethernet PHY) don't justify two board versions, so lets stick with the
>>> generic name and try to differentiate between the versions at runtime
>>> if this is needed later.
>>>
>>> Signed-off-by: Andre Przywara 
>>
>> So further down the thread there is some good discussion on
>> autodetection.
>>
>> I would prefer to keep the name as is (and matching the dts name)
>> for now until this is sorted out.
>>
>> As for the auto-detect discussion I'm all in favor of doing
>> auto-detect and having only one pine64 target in u-boot.
> 
> I fully agree. Hence I was proposing a more generic name (Pine64), as
> this is what people usually say, implying the plus variants of it as well.
> I found this several times when I was typing "make pine64_defconfig" and
> wondering why it didn't work. Typing pine64_plus_defconfig when everyone
> talks about those "Pine64" boards is just a bit counterintuitive - an
> also this pine64_plus config would cover the none-plus boards as well -
> which is just confusing.
> So my proposal was really about just a name change.
> But then again it's just a configuration name, so I don't have a strong
> opinion on this.
> 
>> But I'm against the idea to pass the u-boot dtb into the kernel.
>>
>> People will typically only install u-boot once and then get
>> kernel upgrades, including major version updates (Fedora does
>> this within a release, Debian on dist-upgrade) from their
>> distro, so we really want to stick with using the
>> dtb from the fdtdir entry in extlinux.conf
>>
>> The way this sofar works for sunxi boards is that the chosen
>> entry in extlinux.conf sets the fdtdir and then u-boot determines
>> the dtb name to use, since it knows which board it is booting
>> from.
>>
>> So when we do autodetection, the thing todo would be for the
>> autodetect code to update the fdtfile environment variable
>> to be one of: "sun50i-a64-pine64-plus", "sun50i-a64-pine64",
>> "sun50i-a64-pine64-other-variant" (*).
>>
>> And then upon booting u-boot will load $fdtdir/$fdtfile.
>>
>> Let me give one example where this will be beneficial over
>> using a u-boot supplied dtb:
>>
>> 1) User installs u-boot today, using boot0 and other closed
>> bits + say Fedora 24.
>> 2) In the future we add support for the csi camera
>> 3) User gets newer kernel from Fedora, this comes with
>> an updated "sun50i-a64-pine64-plus.dtb" which includes the
>> necessary changes to enable the csi interface, csi interface
>> just works.
>>
>> If u-boot where to supply the dtb, then the user would also
>> need to update u-boot, which is not part of the standard
>> yum / dnf / apt-get update process. Same for later enabling
>> hdmi output support, audio in/out, etc.
> 
> I understand and support all of these arguments (and hope you didn't
> spend too much time in writing this down ;-)
> 
> My idea was to have some kind of fallback DT in case there is none
> provided by the distribution. For many cases it would be good enough to
> just use U-Boot's DT, so I am looking for an easy way to set U-Boot's
> "externally-facing" DT addr to the internal one - something like "fdt
> internal" or having the internal DT address in a variable or just making

It's already in a variable today, so you can access (and copy) it if you
want :).

> it the default unless the user or boot script loads a custom one.

In the EFI case, we fall back to the internal fdt if we can't find a
matching file name on the boot media. That way users / distros can
provide newer dtb files while we still maintain compatibility with
distros / OSs that choose not to.

Other than those 2 points, I fully agree with you :). We should try to
provide a "known good" device tree on all systems we care about, so that
an OS can just consume it. Whether it's the internal dt or an
additionally bundled dt is an implementation detail imho.


Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,6/6] Pine64: rename defconfig

[Hans de Goede]

Hi,

On 15-05-16 14:49, André Przywara wrote:

On 15/05/16 11:30, Hans de Goede wrote:

Hi,

On 04-05-16 23:15, Andre Przywara wrote:

Rename the defconfig file for the Pine64 from pine64_plus_defconfig to
pine64_defconfig.
The differences between the two versions (more RAM and a different
Ethernet PHY) don't justify two board versions, so lets stick with the
generic name and try to differentiate between the versions at runtime
if this is needed later.

Signed-off-by: Andre Przywara 


So further down the thread there is some good discussion on
autodetection.

I would prefer to keep the name as is (and matching the dts name)
for now until this is sorted out.

As for the auto-detect discussion I'm all in favor of doing
auto-detect and having only one pine64 target in u-boot.


I fully agree. Hence I was proposing a more generic name (Pine64), as
this is what people usually say, implying the plus variants of it as well.
I found this several times when I was typing "make pine64_defconfig" and
wondering why it didn't work. Typing pine64_plus_defconfig when everyone
talks about those "Pine64" boards is just a bit counterintuitive - an
also this pine64_plus config would cover the none-plus boards as well -
which is just confusing.
So my proposal was really about just a name change.
But then again it's just a configuration name, so I don't have a strong
opinion on this.


I understand, but I would like to keep the dts/dtb and defconfig names
matched (the dts has plus in it too) until we've autoconfig.


But I'm against the idea to pass the u-boot dtb into the kernel.

People will typically only install u-boot once and then get
kernel upgrades, including major version updates (Fedora does
this within a release, Debian on dist-upgrade) from their
distro, so we really want to stick with using the
dtb from the fdtdir entry in extlinux.conf

The way this sofar works for sunxi boards is that the chosen
entry in extlinux.conf sets the fdtdir and then u-boot determines
the dtb name to use, since it knows which board it is booting
from.

So when we do autodetection, the thing todo would be for the
autodetect code to update the fdtfile environment variable
to be one of: "sun50i-a64-pine64-plus", "sun50i-a64-pine64",
"sun50i-a64-pine64-other-variant" (*).

And then upon booting u-boot will load $fdtdir/$fdtfile.

Let me give one example where this will be beneficial over
using a u-boot supplied dtb:

1) User installs u-boot today, using boot0 and other closed
bits + say Fedora 24.
2) In the future we add support for the csi camera
3) User gets newer kernel from Fedora, this comes with
an updated "sun50i-a64-pine64-plus.dtb" which includes the
necessary changes to enable the csi interface, csi interface
just works.

If u-boot where to supply the dtb, then the user would also
need to update u-boot, which is not part of the standard
yum / dnf / apt-get update process. Same for later enabling
hdmi output support, audio in/out, etc.


I understand and support all of these arguments (and hope you didn't
spend too much time in writing this down ;-)


No not too much time :)


My idea was to have some kind of fallback DT in case there is none
provided by the distribution. For many cases it would be good enough to
just use U-Boot's DT, so I am looking for an easy way to set U-Boot's
"externally-facing" DT addr to the internal one - something like "fdt
internal" or having the internal DT address in a variable or just making
it the default unless the user or boot script loads a custom one.
So from a technical side this is probably not a challenging request and
orthogonal to the rest of the DT discussion.
I see that one of the beauties of the DT is to be easily "hackable", so
I fully support the option of loading a new DT and passing that on to
the kernel.

But: on ARM64 most boards I am aware of provide a DT as part of the
firmware and it sits in some kind of onboard storage - so distributions
don't need to care about shipping DTs.
I see that those SBCs are different here, but frankly - in contrast to
ARM(32) boards - there are not the majority. It may even be that DT
boards (in contrast to ones using ACPI only) become a niche in the
mid-term future (not that I am happy about that).
I am not sure those SBCs have a strong enough audience to push
distributions to deviate from that single-kernel-file-only approach for
arm64. Also all those boards - and their firmware - are in their early
infancy, so why not rather push for a unified approach here, possibly
deviating from the (legacy) ARM one (explicitly supporting certain
boards and shipping DTs for it)?

So: the DT becomes part of the firmware. In the beginning of the support
era (and I calculate with something like a year here) I expect firmware
to improve significantly - even U-Boot, for that matter (USB, Ethernet,
EFI support, you name it ...). So there is a strong incentive to upgrade
your firmware anyway.
But also I see that the kernel support evolves 

Re: [U-Boot] [U-Boot,6/6] Pine64: rename defconfig

[André Przywara]

On 15/05/16 11:30, Hans de Goede wrote:
> Hi,
> 
> On 04-05-16 23:15, Andre Przywara wrote:
>> Rename the defconfig file for the Pine64 from pine64_plus_defconfig to
>> pine64_defconfig.
>> The differences between the two versions (more RAM and a different
>> Ethernet PHY) don't justify two board versions, so lets stick with the
>> generic name and try to differentiate between the versions at runtime
>> if this is needed later.
>>
>> Signed-off-by: Andre Przywara 
> 
> So further down the thread there is some good discussion on
> autodetection.
> 
> I would prefer to keep the name as is (and matching the dts name)
> for now until this is sorted out.
> 
> As for the auto-detect discussion I'm all in favor of doing
> auto-detect and having only one pine64 target in u-boot.

I fully agree. Hence I was proposing a more generic name (Pine64), as
this is what people usually say, implying the plus variants of it as well.
I found this several times when I was typing "make pine64_defconfig" and
wondering why it didn't work. Typing pine64_plus_defconfig when everyone
talks about those "Pine64" boards is just a bit counterintuitive - an
also this pine64_plus config would cover the none-plus boards as well -
which is just confusing.
So my proposal was really about just a name change.
But then again it's just a configuration name, so I don't have a strong
opinion on this.

> But I'm against the idea to pass the u-boot dtb into the kernel.
> 
> People will typically only install u-boot once and then get
> kernel upgrades, including major version updates (Fedora does
> this within a release, Debian on dist-upgrade) from their
> distro, so we really want to stick with using the
> dtb from the fdtdir entry in extlinux.conf
> 
> The way this sofar works for sunxi boards is that the chosen
> entry in extlinux.conf sets the fdtdir and then u-boot determines
> the dtb name to use, since it knows which board it is booting
> from.
> 
> So when we do autodetection, the thing todo would be for the
> autodetect code to update the fdtfile environment variable
> to be one of: "sun50i-a64-pine64-plus", "sun50i-a64-pine64",
> "sun50i-a64-pine64-other-variant" (*).
> 
> And then upon booting u-boot will load $fdtdir/$fdtfile.
> 
> Let me give one example where this will be beneficial over
> using a u-boot supplied dtb:
> 
> 1) User installs u-boot today, using boot0 and other closed
> bits + say Fedora 24.
> 2) In the future we add support for the csi camera
> 3) User gets newer kernel from Fedora, this comes with
> an updated "sun50i-a64-pine64-plus.dtb" which includes the
> necessary changes to enable the csi interface, csi interface
> just works.
> 
> If u-boot where to supply the dtb, then the user would also
> need to update u-boot, which is not part of the standard
> yum / dnf / apt-get update process. Same for later enabling
> hdmi output support, audio in/out, etc.

I understand and support all of these arguments (and hope you didn't
spend too much time in writing this down ;-)

My idea was to have some kind of fallback DT in case there is none
provided by the distribution. For many cases it would be good enough to
just use U-Boot's DT, so I am looking for an easy way to set U-Boot's
"externally-facing" DT addr to the internal one - something like "fdt
internal" or having the internal DT address in a variable or just making
it the default unless the user or boot script loads a custom one.
So from a technical side this is probably not a challenging request and
orthogonal to the rest of the DT discussion.
I see that one of the beauties of the DT is to be easily "hackable", so
I fully support the option of loading a new DT and passing that on to
the kernel.

But: on ARM64 most boards I am aware of provide a DT as part of the
firmware and it sits in some kind of onboard storage - so distributions
don't need to care about shipping DTs.
I see that those SBCs are different here, but frankly - in contrast to
ARM(32) boards - there are not the majority. It may even be that DT
boards (in contrast to ones using ACPI only) become a niche in the
mid-term future (not that I am happy about that).
I am not sure those SBCs have a strong enough audience to push
distributions to deviate from that single-kernel-file-only approach for
arm64. Also all those boards - and their firmware - are in their early
infancy, so why not rather push for a unified approach here, possibly
deviating from the (legacy) ARM one (explicitly supporting certain
boards and shipping DTs for it)?

So: the DT becomes part of the firmware. In the beginning of the support
era (and I calculate with something like a year here) I expect firmware
to improve significantly - even U-Boot, for that matter (USB, Ethernet,
EFI support, you name it ...). So there is a strong incentive to upgrade
your firmware anyway.
But also I see that the kernel support evolves quickly, so putting a new
DT in your /boot directory is probably a good idea - at least for a start.

Re: [U-Boot] [U-Boot,6/6] Pine64: rename defconfig

[Hans de Goede]

Hi,

On 04-05-16 23:15, Andre Przywara wrote:

Rename the defconfig file for the Pine64 from pine64_plus_defconfig to
pine64_defconfig.
The differences between the two versions (more RAM and a different
Ethernet PHY) don't justify two board versions, so lets stick with the
generic name and try to differentiate between the versions at runtime
if this is needed later.

Signed-off-by: Andre Przywara 


So further down the thread there is some good discussion on
autodetection.

I would prefer to keep the name as is (and matching the dts name)
for now until this is sorted out.

As for the auto-detect discussion I'm all in favor of doing
auto-detect and having only one pine64 target in u-boot.

But I'm against the idea to pass the u-boot dtb into the kernel.

People will typically only install u-boot once and then get
kernel upgrades, including major version updates (Fedora does
this within a release, Debian on dist-upgrade) from their
distro, so we really want to stick with using the
dtb from the fdtdir entry in extlinux.conf

The way this sofar works for sunxi boards is that the chosen
entry in extlinux.conf sets the fdtdir and then u-boot determines
the dtb name to use, since it knows which board it is booting
from.

So when we do autodetection, the thing todo would be for the
autodetect code to update the fdtfile environment variable
to be one of: "sun50i-a64-pine64-plus", "sun50i-a64-pine64",
"sun50i-a64-pine64-other-variant" (*).

And then upon booting u-boot will load $fdtdir/$fdtfile.

Let me give one example where this will be beneficial over
using a u-boot supplied dtb:

1) User installs u-boot today, using boot0 and other closed
bits + say Fedora 24.
2) In the future we add support for the csi camera
3) User gets newer kernel from Fedora, this comes with
an updated "sun50i-a64-pine64-plus.dtb" which includes the
necessary changes to enable the csi interface, csi interface
just works.

If u-boot where to supply the dtb, then the user would also
need to update u-boot, which is not part of the standard
yum / dnf / apt-get update process. Same for later enabling
hdmi output support, audio in/out, etc.

Note I'm not advocating to have different dtb-s, all sunxi
boards use the same dts files in u-boot and the kernel,
but the _kernel_ is considered the canonical source, and
for u-boot we simply sync the included dts files with the
kernel every now and then.

As an added advantage this keeps the ABI part of the dtb
between u-boot and the kernel really small, it basically
is just the $fdtfile name. Which means that if we mess up
some bindings we can chose to change them, we try to avoid
this but always using the dtb file bundled with the kernel
allows this.

The main argument for always using the dtb file bundled with
the kernel is to always get the latest new features (think
extended hw support) and bugfixes, without the user needing
to update the bootlader (which is something which is not
done automatically by the distro, unlike the kernel).

Regards,

Hans


*) Note we will likely need something more then just that, since
e.g. some variants have an emmc and others do not and this is
relevant for u-boot itself


---
 configs/pine64_defconfig  | 20 
 configs/pine64_plus_defconfig | 20 
 2 files changed, 20 insertions(+), 20 deletions(-)
 create mode 100644 configs/pine64_defconfig
 delete mode 100644 configs/pine64_plus_defconfig

diff --git a/configs/pine64_defconfig b/configs/pine64_defconfig
new file mode 100644
index 000..0977334
--- /dev/null
+++ b/configs/pine64_defconfig
@@ -0,0 +1,20 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN50I=y
+CONFIG_DRAM_CLK=672
+CONFIG_DRAM_ZQ=3881915
+# CONFIG_VIDEO is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
deleted file mode 100644
index 0977334..000
--- a/configs/pine64_plus_defconfig
+++ /dev/null
@@ -1,20 +0,0 @@
-CONFIG_ARM=y
-CONFIG_ARCH_SUNXI=y
-CONFIG_MACH_SUN50I=y
-CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ZQ=3881915
-# CONFIG_VIDEO is not set
-CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
-# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_HUSH_PARSER=y
-# CONFIG_CMD_IMLS is not set
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_MMC=y
-# CONFIG_CMD_FPGA is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot