failure to add ppa:team-gcc-arm-embedded/ppa

[ppelleti]

The README suggests:

$ sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa -y
$ sudo apt update
$ sudo apt install gcc-arm-embedded

However, sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa -y gives me the error:

Err:8 http://ppa.launchpad.net/team-gcc-arm-embedded/ppa/ubuntu focal Release
  404  Not Found [IP: 91.189.95.83 80]

I went to the page for team-gcc-arm-embedded, which says:

Currently supports Ubuntu 10.04/12.04/14.04/14.10

So it seems to be 6 years out of date.

Where should I be getting arm-none-eabi-gdb from instead?

[jessebraham]

I have found this answer on StackOverflow which explains the cause of the issue and provides an apparent solution. Would you be willing to try it out and report back? We can update the README once we've confirmed it works.

[ppelleti]

Thanks! I tried that out and it worked for me, although I did it slightly differently due to taste.

I installed the toolchain in /opt and added the bin directory to my PATH:

$ cd /opt
$ tar -xf ~/Desktop/gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux.tar.bz2
$ export PATH="/opt/gcc-arm-none-eabi-9-2020-q2-update/bin:$PATH"

I found that I did not need to make symlinks to libncurses and libtinfo. Ncurses 5 seems to have been already installed on my system. Even if it was not already installed, I would recommend installing it with sudo apt-get install libncurses5, rather than making symlinks from 5 to 6.

[BalmaBrian]

Any updates on the ppa?

[ppelleti]

From reading the StackOverflow answer, my impression was that the PPA was dead, and we're supposed to use the tarballs from ARM's site instead.

[kdsch]

I noticed that README.md doesn't yet reflect this new information, so I'm planning to open a PR for that.

[twitchyliquid64]

Do we still have issues with Ubuntu/Debian packages for arm-none? Ive been using debian stable without issues for the whole year without realizing this was an issue :O

Specifically, package gcc-arm-none-eabi is working fine for me

[kdsch]

@twitchyliquid64 Possibly, but I'm not sure. I'm running into issues with cargo-hf2 having invalid binaries (no entrypoint, all symbols at address 0x0) so I assumed it was the compiler, which is what led me to try to update it. The compiler used for the binary in question is

compiler Linker: LLD 11.0.0 GCC: (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch 

which isn't the latest version.

[twitchyliquid64]

My version, which works:

[xxx@xxx]:~> arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm running into issues with cargo-hf2 having invalid binaries (no entrypoint, all symbols at address 0x0)

What error are you getting? and what rust version?

[kdsch]

Hope this doesn't take the thread too off-topic given that it involves cargo-hf2. (I'm new to Rust so there's a good chance I have misconfigured something.)

rustc 1.49.0 (e1884a8e3 2020-12-29)
cargo-hf2 0.3.1

The error is

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: InvalidBinary', /home/karl/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-hf2-0.3.1/src/main.rs:118:47

Upon inspection, the error is generated here, implying an empty byte slice, which would have come from the function elf_to_bin.

Seems to me that something is wrong with the ELF file produced by the cargo invocation. I checked it with radare, and I'm not familiar with ELFs for embedded systems (cargo-hf2 seems to be transforming the ELF before flashing anyway).

[twitchyliquid64]

Yeah thats dicey. Could you open another issue for this? I think something might have changed with 1.49 :/