Add support for aarch64

[troibe]

This allows both compiling opentitantool and images for the sival chips on hosts with ARM architecture. Before merging this we should adjust the release paths for crt, lowrisc toolchains and safe ftdi.

[troibe]

Depends on lowRISC/crt#42 and lowRISC/safe-ftdi#3.

Currently HOST_ARCHS is duplicated between 3 Bazel files.
I'm not quite sure where the best location would be to store this information.

[cfrantz]

Depends on lowRISC/crt#42 and lowRISC/safe-ftdi#3.

Currently HOST_ARCHS is duplicated between 3 Bazel files. I'm not quite sure where the best location would be to store this information.

I'd put common host definitions (like HOST_ARCHS and get_host_cpu) into //rules:host.bzl and import them elsewhere as needed (e.g. load("//rules:host.bzl", "HOST_ARCHS")).

[troibe]

Thanks for the advice. Let me do that. 👍

[troibe]

I had to put get_host_cpu() into it's own bazel rule file because host.bzl gets loaded too early leading to the following cycle:

ERROR: Failed to load Starlark extension '@local_config_platform//:constraints.bzl'.
Cycle in the workspace file detected. This indicates that a repository is used prior to being defined.
The following chain of repository dependencies lead to the missing definition.
 - @local_config_platform
This could either mean you have to add the '@local_config_platform' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive dependencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.
ERROR: Error computing the main repository mapping: cycles detected during computation of main repo mapping

Other than that this worked well so thanks again.
I had to make one more change to crt so I'll ask @jwnrt to do another release (PR coming soon) and change the dependency URL.

[troibe]

Currently only depends on lowRISC/crt#43.

[troibe]

Changes to all dependencies (crt, lowrisc toolchains and safe ftdi) are now merged and release paths adjusted.
This should be good to go from my side.

[jwnrt]

Looks okay to me

[cfrantz]

This isn't your error, but would it be better to convert the array to a CStr instead of this manual iterator to construct the string:

let cstr = std::ffi::CStr::from_bytes_until_nul(array);
cstr.to_string_lossy().to_string()

[troibe]

At least from a quick look at the documentation it seems like from_bytes_until_nul would error if there is no null character in array.
Now I'm not sure if the callers of c_string_to_string would actually pass in a non null terminated string but I would rather not introduce that slight change in behavior unless I'm sure about that.

[pamaury]

There is one instance where it can be called with a non-null termined string:

module_id: c_string_to_string(&mod_id)

However this ia a very special case for a 3-character string where none of them is expected to be a NUL anyway. So you could potentially rewrite a bit the code to eliminate c_string_to_string

[troibe]

Thanks for explaining. 😇
Would it be fine for you if I put that in a small follow up PR to this one?

[pamaury]

Sure :)