-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: architectures: added cortex-a72 architecture. #42
base: master
Are you sure you want to change the base?
Conversation
To actually compile this testbed vehicle it's needed a more recent version of gcc, kernel, etc. I tried doing such maintenance with diogogithub@88dd2cf but I was going through a very long hellish experience and stopped trying when I finally got stuck with libssl-dev. Hence, I think we're just going to use another distro and compile Dune on it. The impression this repo's code gives is that it isn't seriously maintained since 2015~2017. I really don't understand why everything is compiled from source with the rules, why not simply use a package manager? Being that said, I hope some of this code turns out to be helpful contributions and I'm sorry if I'm misunderstanding and confusing things, did learn something from trying to make this work so, at least there's that. |
The way I see it package managers are very compelling for being easy to use but they can quickly clutter the OS with packages. Most of our needs with this distro have been more or less static for each system in terms of packages so they are compiled at build time and that's it. On the rare occasion we need a new package you re-compile and do a quick a field-upgrade over the air. From you patches I see that you set |
Alpine has a package manager and doesn't get all that cluttered but I get your point. I think I only got a bit annoyed with the versions that are set in the rules as I was expecting this to be as trivial as adding the architecture, the system and bada bim bada bum, things work :') Okay, so these flags aren't as right as I thought they were, hm... |
Currently for RPI4 we only have the 32Bit version (feature/rpi4), the 64Bit version is not yet created. |
I meant for our specific use case. Alpine's a bit more generic |
Tried this for compilation/testing: diogogithub@727baa9
Read the following to better understand what flags would make sense:
https://developer.arm.com/documentation/ihi0056/g/
https://github.com/bminor/binutils-gdb/blob/master/gas/config/tc-aarch64.c#L32
https://embeddedartistry.com/blog/2017/10/11/demystifying-arm-floating-point-compiler-options/
https://www.mail-archive.com/[email protected]/msg218644.html
https://gist.github.com/fm4dd/c663217935dc17f0fc73c9c81b0aa845
https://en.wikipedia.org/wiki/ARM_Cortex-A72
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0.pdf
I'm a bit unsure if the right
target_ar
argument isaarch64-elf
, I kinda feelelf64-little
would make sense as well?And there's also floating point that, from ARM docs, I ended settling on this...