Hi Folks,
I propose the following triplet for Fedora on AArch64:
aarch64-redhat-linux-gnu
Skipping the vendor part, that means generally:
aarch64-linux-gnu
There should be no reason to deviate from this. I'm putting it out there
now because I don't want another ARMv7 experience later :)
Jon.
Rob, in git commit 49a3fb455890dd9d53a18573d0998edb8332fc4a (from
git://git.linaro.org/boot/u-boot-linaro-stable.git), there is:
+fdt_addr=0x1000
+pxefile_addr_r=0x700000
+kernel_addr_r=0x800000
+ramdisk_addr_r=0x01000000
Why is that first line fdt_addr not fdt_addr_r; the latter appears more
often in mainline U-Boot and is what's mentioned in README too.
(as background, I'm working on a change to switch Tegra to using the
standard env. var. names in mainline U-Boot and was snooping on what
you'd done for Highbank!)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey all,
So as distros we are soon going to be forced to support DTB files.
Fedora likely sooner than the rest as we closely follow the mainline
kernel throughout the life of a fedora release. Ideally the device
manufacturers will provide dtb files. but then devices like the
pandaboard, beagleboardXM etc with no storage to speak of we have to
ship u-boot so likely will need to ship dtb files also. so far the best
vendor i know of for dtb support is calxeda. and thats where we should
encourage vendors to emulate, but until we get to there we need to take
baby steps.
I was wondering what the distros were planning to do, or has it even
been considered? Fedora 18 will likely ship 3.6.x but will be updated
to 3.7.1 likely and also 3.8.x if not 3.9.x We get the joy of things
breaking every kernel release because no one else seems to be testing
or using the upstream kernel.
I would like to see us as distros and linaro go to the vendors and get
them to ship dtb files and updated u-boot with dtb support. Ideally
with some consistent macro use to make distro support of u-boot saner.
appended dtb is pretty ugly and I do not want to support it. I feel
like we have an opportunity here to correct some of the wrongs of the
past as u-boot updates will be forced on the world to deal with the
forced move to DeviceTree. do we have vendors on this list? if not can
we get the list of contacts and reach out to them to get things
straightened up?
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAlBSCpsACgkQkSxm47BaWfcHeACeOkvZUdoGQOKBI9u2K/g5Fjct
BTEAn2ArwfQbGTVcmFK3y/FzJDsftGQq
=wMfb
-----END PGP SIGNATURE-----
Hi,
We (MAAS upstream) are having some issues figuring out how to
effectively detect the architecture of a system booting using U-Boot
pxelinux emulation in order to send back an appropriate kernel and
initrd.
In short, we'd like a mechanism that is separate from the DHCP vendor
option which I believe is the only way to differentiate at the moment.
I proposed an alternative mechanism in
https://launchpad.net/bugs/1041092 (description copied below) and it was
suggested to me that I could get feedback from this list.
If this mechanism is appropriate and we can get vendor consensus on it,
then I can continue and implement the other end of it in MAAS. If it is
not suitable then I'd love to hear about alternatives. Either way, I'd
really like to move within a couple of weeks so that I can make our
12.10 release in October.
Without a non-DHCP mechanism for architecture detection, MAAS will be
stuck having to be configured for homogeneous architecture clusters
only, which would be unfortunte.
What do you think? The full text of the bug is below.
Thanks,
Robie
An outcome of a recent MAAS-related sprint is the conclusion that MAAS needs
to be able to operate in an environment where it cannot control the DHCP
server.
This means that we cannot rely on the ability to differentiate architectures
based on ISC dhcpd.conf conditional statements on vendor-class-identifier
setting alternate next-server filenames as we are doing at the moment (see bug
927781 for details of this mechanism).
Instead we need some other way for MAAS to detect the architecture of the
booting system in order to send it the correct architecture kernel/initrd.
If this doesn't happen, then MAAS will have to resort to guessing based on MAC
addresses supplied by vendors, or the user entering in the information on a
per-MAC basis manually, or the user nominating an entire MAAS cluster as
homogeneous on a particular architecture. None of these options are ideal.
Instead, I propose the following minor change to U-Boot to enable architecture
detection outside of DHCP.
The original (Intel) pxelinux.0 falls back through MAC addresses, IP address
and subnets and then to "default". Prior to U-Boot pxelinux emulation, a TFTP
server could assume that sending an i386 kernel would always work.
pxelinux emulation on other architectures breaks this assumption. So I propose
that all alternative architecture pxelinux emulators (eg. U-Boot) fall back to
"default.<arch>-<subarch>" and then "default.<arch>" before further falling
back to "default" as usual.
<arch> and <subarch> must be defined in a new pxelinux emulator namespace, and
MAAS will consequently need to map this namespace to Ubuntu's architecture and
kernel flavour names. But to start with, they'll probably match 1-1.
So: default.arm-highbank default.arm-armadaxp default.arm-omap4
For this proposed change to work, we need all vendors to take this up. I think
the change would be trivial, but I would appreciate feedback from U-Boot
maintainers and vendors before we commit to this direction.
