≡
[00:19:12] <red_beard> (which is to say the specific opinionated variant of aarch64 known as ARM64)
[00:20:29] <braunr> are these different ?
[00:21:31] <red_beard> braunr: aarch64 vs ARM64?
[00:21:45] <braunr> yes
[00:30:44] <red_beard> braunr: so the "opinionation" of ARM64 includes that there is no (hardware) big endian support, ARM64 is also _supposed_ to specify the use of ACPI (versus device tree). Thus someone could hypothetically create an aarch64 build using device tree and emulated big endian, but it "isn't" ARM64 from the perspective of Linux developers
[00:30:47] <red_beard> ACTION shrugs
[00:31:38] <red_beard> we played this game when doing work on the Cavium & APM platforms
[00:32:42] <braunr> so arm64 implies acpi and little endian, and aarch64 implies a device tree and both endianness types ?
[00:45:54] <red_beard> more that aarch64 can be any of the above and only specifies the instruction set of the chip. kindof like comparing Xen and Amazon Web Services. All AWS hosts are _technically_ running on Xen... but it implies a lot of other things that are in place and available. It doesn't mean one cannot provide all of those services, more that one is a superset of the other.
[00:46:12] <braunr> ok
[00:46:23] <braunr> so arm64 is more specific than aarch64
[00:46:34] <braunr> why is that (if you're willing to explain) ?
[00:51:41] <red_beard> to give an example, when we do a linux build for amd64 (aka x86_64) we only need one specific config because we can assume how certain things will be done. Because a company can license the ARMv8 core and then make any number of changes to it, it requires building out a device tree to know the exact location of where your MMU is, find the interrupt of your real time clock, etc.
[00:52:05] <braunr> yes, that i get
[00:52:13] <red_beard> after years of software folks saying "to hell with this" ARM foundation worked with the Linux Foundation to define "ARM64" (after apple started going their own route)
[00:52:31] <red_beard> so that by specifying an arm64 configuration you wouldn't have to go figure all of that out
[00:52:50] <braunr> is acpi a better way to achieve that than device trees ?
[00:53:07] <red_beard> and the same kernel config could be used for multiple devices (or even distros) without having to build a new DTB
[00:53:18] <braunr> oh, ok i see
[00:53:35] <red_beard> that gets into a whole rats nest (regarding ACPI being better). _personally_ i think so
[00:53:55] <red_beard> but i've also fought with situations where when chainloading from one kernel to another the PCI table "got lost"
[00:54:57] <red_beard> kernel A knew exactly where everything was, but upon reloading it (using a mechanism like ksplice) it would just fail to know where any of the PCI devices were or how to address them
[00:56:42] <red_beard> geoff levand (who maintains the PS3 port of Linux) has done a lot of work on that front and actually moved from Huaweii to Cavium to improve the whole process
[00:58:01] <red_beard> braunr: this is a pretty good talk (IIRC) on the whole ACPI vs DT trade off - https://www.youtube.com/watch?v=xUiNjEU2Clo
[00:58:34] <braunr> thanks
[00:59:14] <red_beard> in fact, until very recently mjg59 was working on that with us (at CoreOS). he moved onto Google to do work on coreboot/UEFI/SecureBoot
[01:06:52] <adj__> red_beard, I don't know about u-boot on a64, I only own olimex's armv7 boards
[01:07:18] <braunr> i have an a64 that i intend to work on in a couple of weeks/months
[01:07:38] <braunr> so i'm quite interested in understanding aarch64/arm64 better
[02:09:44] <red_beard> braunr: my reference platform right now that i've been doing work on has been the pine64. for our case we will need to do a weird chainload of u-boot into GRUB2, but that's merely a matter of configuration assuming u-boot is good to go. the grub requirement comes from how we do dm-verity, partition pivoting, and a few other features.
[02:10:11] <red_beard> that being said, i've love to use _properly_ open hardware
[02:10:40] <braunr> i understand
[02:10:49] <braunr> i'll probably buy a pine64 at some point
[02:11:12] <braunr> or maybe just the pinebook :)
[02:11:53] <red_beard> FWIW, Linaro wrote up the GRUB/U-Boot bits a while ago - https://web.archive.org/web/20160810042608/https://wiki.linaro.org/LEG/Engineering/Kernel/GRUBonUBOOT
[08:28:11] **************** Logging Ended ****************
[08:30:30] **************** Logging Started ****************
[10:34:55] **************** Logging Ended ****************
[13:00:29] **************** Logging Started ****************
IRC #olimex 2017-09-21
[00:17:11] <red_beard> adj__: alas, my linux distro only supports ARM64. I'd rather pick the right chip to work with rather than re-working my entire SDK. It could just be that I wait a little longer to see what else shakes out on low end ARM64.[00:19:12] <red_beard> (which is to say the specific opinionated variant of aarch64 known as ARM64)
[00:20:29] <braunr> are these different ?
[00:21:31] <red_beard> braunr: aarch64 vs ARM64?
[00:21:45] <braunr> yes
[00:30:44] <red_beard> braunr: so the "opinionation" of ARM64 includes that there is no (hardware) big endian support, ARM64 is also _supposed_ to specify the use of ACPI (versus device tree). Thus someone could hypothetically create an aarch64 build using device tree and emulated big endian, but it "isn't" ARM64 from the perspective of Linux developers
[00:30:47] <red_beard> ACTION shrugs
[00:31:38] <red_beard> we played this game when doing work on the Cavium & APM platforms
[00:32:42] <braunr> so arm64 implies acpi and little endian, and aarch64 implies a device tree and both endianness types ?
[00:45:54] <red_beard> more that aarch64 can be any of the above and only specifies the instruction set of the chip. kindof like comparing Xen and Amazon Web Services. All AWS hosts are _technically_ running on Xen... but it implies a lot of other things that are in place and available. It doesn't mean one cannot provide all of those services, more that one is a superset of the other.
[00:46:12] <braunr> ok
[00:46:23] <braunr> so arm64 is more specific than aarch64
[00:46:34] <braunr> why is that (if you're willing to explain) ?
[00:51:41] <red_beard> to give an example, when we do a linux build for amd64 (aka x86_64) we only need one specific config because we can assume how certain things will be done. Because a company can license the ARMv8 core and then make any number of changes to it, it requires building out a device tree to know the exact location of where your MMU is, find the interrupt of your real time clock, etc.
[00:52:05] <braunr> yes, that i get
[00:52:13] <red_beard> after years of software folks saying "to hell with this" ARM foundation worked with the Linux Foundation to define "ARM64" (after apple started going their own route)
[00:52:31] <red_beard> so that by specifying an arm64 configuration you wouldn't have to go figure all of that out
[00:52:50] <braunr> is acpi a better way to achieve that than device trees ?
[00:53:07] <red_beard> and the same kernel config could be used for multiple devices (or even distros) without having to build a new DTB
[00:53:18] <braunr> oh, ok i see
[00:53:35] <red_beard> that gets into a whole rats nest (regarding ACPI being better). _personally_ i think so
[00:53:55] <red_beard> but i've also fought with situations where when chainloading from one kernel to another the PCI table "got lost"
[00:54:57] <red_beard> kernel A knew exactly where everything was, but upon reloading it (using a mechanism like ksplice) it would just fail to know where any of the PCI devices were or how to address them
[00:56:42] <red_beard> geoff levand (who maintains the PS3 port of Linux) has done a lot of work on that front and actually moved from Huaweii to Cavium to improve the whole process
[00:58:01] <red_beard> braunr: this is a pretty good talk (IIRC) on the whole ACPI vs DT trade off - https://www.youtube.com/watch?v=xUiNjEU2Clo
[00:58:34] <braunr> thanks
[00:59:14] <red_beard> in fact, until very recently mjg59 was working on that with us (at CoreOS). he moved onto Google to do work on coreboot/UEFI/SecureBoot
[01:06:52] <adj__> red_beard, I don't know about u-boot on a64, I only own olimex's armv7 boards
[01:07:18] <braunr> i have an a64 that i intend to work on in a couple of weeks/months
[01:07:38] <braunr> so i'm quite interested in understanding aarch64/arm64 better
[02:09:44] <red_beard> braunr: my reference platform right now that i've been doing work on has been the pine64. for our case we will need to do a weird chainload of u-boot into GRUB2, but that's merely a matter of configuration assuming u-boot is good to go. the grub requirement comes from how we do dm-verity, partition pivoting, and a few other features.
[02:10:11] <red_beard> that being said, i've love to use _properly_ open hardware
[02:10:40] <braunr> i understand
[02:10:49] <braunr> i'll probably buy a pine64 at some point
[02:11:12] <braunr> or maybe just the pinebook :)
[02:11:53] <red_beard> FWIW, Linaro wrote up the GRUB/U-Boot bits a while ago - https://web.archive.org/web/20160810042608/https://wiki.linaro.org/LEG/Engineering/Kernel/GRUBonUBOOT
[08:28:11] **************** Logging Ended ****************
[08:30:30] **************** Logging Started ****************
[10:34:55] **************** Logging Ended ****************
[13:00:29] **************** Logging Started ****************