RPi Pico play with slackwareARM

Exaga · 02-25-2021, 04:12 PM

Quote:

Originally Posted by louigi600

Maybe I need to look at how they built the pico toolchain to sort this out on SlackwareARM.

Code:

arm-none-eabi-gcc: error: nosys.specs: No such file or directory

This is a stab in the dark from me... re: toolchains. You're missing 'nosys.specs' in the toolchain you're using.

Code:

root@endo:/tmp# wget https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update/+download/gcc-arm-none-eabi-5_4-2016q3-20160926-linux.tar.bz2
root@endo:/tmp# tar -xf gcc-arm-none-eabi-5_4-2016q3-20160926-linux.tar.bz2
root@endo:/tmp# ls -lah gcc-arm-none-eabi-5_4-2016q3/arm-none-eabi/lib/nosys.specs
-rw-r--r-- 1 root root 277 Sep 26  2016 gcc-arm-none-eabi-5_4-2016q3/arm-none-eabi/lib/nosys.specs

Not sure which toolchain you're using or what it contains, but this one has the lib file that's missing.

Sorry if this is a waste of your time.

gus3 · 02-25-2021, 05:48 PM

Slightly OT: I went the "interactive" route and started with MicroPython on the Pico, using the on-board USB via:

Code:

$ minicom -D /dev/ttyACM0

on my desktop.

MicroPython's port to the Pico includes a couple hardware-specific libraries, for access to most of the on-chip features (so far, only the hardware fixed-point divider seems to be ignored as redundant, since that's handled within Python anyway).

After a few little experiments with it, I decided to forego Thonny and put together my own program loader, all in Python. First challenge: a slider on the UI that adjusts the brightness of the Pico's on-board LED. Python 3 on the desktop (the "director"), using pyserial and Tkinter; MicroPython on the Pico (the "actor"). The director code soft-boots the MicroPython, then transmits the actor code and launches it.

I finally got it to work Tuesday last week, as we dug ourselves out of the previous night's snowstorm. It isn't the best code I've ever written, and the style shows I'm a Python amateur, but the fact that it works at all is pretty darn satisfying. Oh, did I mention that the notes I took before and during development are 5x longer than the working Python code itself?

Next challenge: re-work the director side as OO. Starting with:

louigi600 · 02-26-2021, 12:50 AM

Quote:

Originally Posted by Exaga

Code:

arm-none-eabi-gcc: error: nosys.specs: No such file or directory

This is a stab in the dark from me... re: toolchains. You're missing 'nosys.specs' in the toolchain you're using.

Code:

root@endo:/tmp# wget https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update/+download/gcc-arm-none-eabi-5_4-2016q3-20160926-linux.tar.bz2
root@endo:/tmp# tar -xf gcc-arm-none-eabi-5_4-2016q3-20160926-linux.tar.bz2
root@endo:/tmp# ls -lah gcc-arm-none-eabi-5_4-2016q3/arm-none-eabi/lib/nosys.specs
-rw-r--r-- 1 root root 277 Sep 26  2016 gcc-arm-none-eabi-5_4-2016q3/arm-none-eabi/lib/nosys.specs

Not sure which toolchain you're using or what it contains, but this one has the lib file that's missing.

Sorry if this is a waste of your time.

Yes the message says gcc can't find it but it is there where LD_LIBRARY_PATH says it can find it.
I will try to pull clean again the toolchain and see what happens.

@gus3 if I liked python I would have probably gone that way but any time I had to get my hands dirty with python I hated it (so many dirty tricks to do the low level stuff) + what the fuck I want to indent in a way that it pleases me no the syntax itself

drmozes · 02-26-2021, 04:28 AM

Quote:

Originally Posted by louigi600

Yes the message says gcc can't find it but it is there where LD_LIBRARY_PATH says it can find it.

LD_LIBRARY_PATH is for the linker to locate shared objects at run time that are not in the standard locations. This isn't going to help provide the path to the specs file.

Try to figure out what path the gcc is using. Do something like this with the gcc you're using. It may be something as simple as putting the specs file into the path gcc's looking for it in.

Code:

root@zippy:~# gcc -v 2>&1|grep specs
Reading specs from /usr/lib/gcc/arm-slackware-linux-gnueabihf/10.2.0/specs

There's also the gcc command line option -specs you could set as CFLAGS to point directly to it.

louigi600 · 02-26-2021, 05:56 AM

Quote:

Originally Posted by drmozes

LD_LIBRARY_PATH is for the linker to locate shared objects at run time that are not in the standard locations. This isn't going to help provide the path to the specs file.

Try to figure out what path the gcc is using. Do something like this with the gcc you're using. It may be something as simple as putting the specs file into the path gcc's looking for it in.

Code:

root@zippy:~# gcc -v 2>&1|grep specs
Reading specs from /usr/lib/gcc/arm-slackware-linux-gnueabihf/10.2.0/specs

There's also the gcc command line option -specs you could set as CFLAGS to point directly to it.

The toolchain borrowed from RPiOS says "Using built-in specs"

the slackwareARM-current says:

Code:

root@rpi4:/usr/src/pico/blink/build# gcc -v 2>&1 |grep specs
Reading specs from /usr/lib/gcc/arm-slackware-linux-gnueabihf/10.2.0/specs
root@rpi4:/usr/src/pico/blink/build# ls -l /usr/lib/gcc/arm-slackware-linux-gnueabihf/10.2.0/specs
-rw-r--r-- 1 root root 9502 Feb  1  2021 /usr/lib/gcc/arm-slackware-linux-gnueabihf/10.2.0/specs
root@rpi4:/usr/src/pico/blink/build#

But now as the proper toolchain is using builtin specs I'm no longer sure which file to put in /usr/lib/gcc/arm-slackware-linux-gnueabihf/10.2.0/nosys.specs
I tried this one first (it looked the best fit):
/usr/src/pico/pico-sdk/toolchain/usr/lib/arm-none-eabi/newlib/thumb/v6-m/nosys.specs
and I got this error:

Code:

[ 16%] Linking ASM executable bs2_default.elf
/usr/bin/ld: cannot find -lnosys
collect2: error: ld returned 1 exit status
make[2]: *** [pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/build.make:96: pico-sdk/src/rp2_common/boot_stage2/bs2_default.elf] Error 1
make[1]: *** [CMakeFiles/Makefile2:1575: pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/all] Error 2
make: *** [Makefile:103: all] Error 2

drmozes · 02-26-2021, 06:11 AM

Quote:

Originally Posted by louigi600

But now as the proper toolchain is using builtin specs I'm no longer sure which file to put in /usr/lib/gcc/arm-slackware-linux-gnueabihf/10.2.0/nosys.specs
I tried this one first (it looked the best fit):

This was an example of how to find the path to the spec file that gcc is configured to use.
Do the same thing using the other compiler and see if you can find what it expects the path to be, since it's unable to find it.
You could also run it through strace.

You should fix your system time, too. Building with a wildly out of sync time does funny things to builds.

louigi600 · 02-26-2021, 06:24 AM

The toolchain borrowed from RPiOS says : "Using built-in specs"

drmozes · 02-26-2021, 06:44 AM

Quote:

Originally Posted by louigi600

The toolchain borrowed from RPiOS says : "Using built-in specs"

Perhaps make the build run gcc through strace so you can figure out what paths it's searching when looking for the specs file name included in the previous posts.

louigi600 · 02-27-2021, 12:49 AM

Quote:

Originally Posted by Exaga

[CODE]You're missing 'nosys.specs' in the toolchain you're using.

Code:

root@endo:/tmp# wget https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update/+download/gcc-arm-none-eabi-5_4-2016q3-20160926-linux.tar.bz2
root@endo:/tmp# tar -xf gcc-arm-none-eabi-5_4-2016q3-20160926-linux.tar.bz2
root@endo:/tmp# ls -lah gcc-arm-none-eabi-5_4-2016q3/arm-none-eabi/lib/nosys.specs
-rw-r--r-- 1 root root 277 Sep 26  2016 gcc-arm-none-eabi-5_4-2016q3/arm-none-eabi/lib/nosys.specs

Not sure which toolchain you're using or what it contains, but this one has the lib file that's missing.

Sorry if this is a waste of your time.

That's fairly old: currently launchpad says this about the gcc-arm-embedded toolchain:

Code:

As previously announced all new binary and source packages will not be released on Launchpad henceforth, they can be found on:
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm.

PPA location remains unchanged.

Quote:

Originally Posted by drmozes

Perhaps make the build run gcc through strace so you can figure out what paths it's searching when looking for the specs file name included in the previous posts.

The makefile is made by cmake ... it's not as easy as just changing the GCC variable and it pulls in some 40 odd pieces of code ... I think even if I make everyone call gcc with strace I will get a huge amount of information to look trough. Maybe not the best approach in this case.

The interesting is that over at developer.arm.com they don't have a tarball to download for arm 32bit ... probably because the native arm 32 bit compiler should be able to handle it natively. The only reason I can think that the pico SDK should force you to use a cross toolchain when not needed is because they did not want to make a separate case for native build while everyone else needs to cross compile.
Unfortunately I've not been successful at getting the SDK to use the native build toolchain.
Quick dirty workarounds options I can think of:

make a better attempt at gouging from RPiOS the xtoolchain
build the toolchain from sources
download the toolchain for linux x86_64 and try from my intel box ... once I get it working there maybe it will be easier to do the same on arm

For the moment I decided to build the toolchain from sources ... and even there I had to modify the build scripts because the were downloading some .MSI package and unpacking 7zip file with wrong tool. Anyway I got the build to start ... will come and check later how it is doing.

Am I the only one that wants to play with the pico from SlackwareARM or am I the only unsuccessful one at it ?

drmozes · 02-27-2021, 04:22 AM

Quote:

Originally Posted by louigi600

The makefile is made by cmake ... it's not as easy as just changing the GCC variable and it pulls in some 40 odd pieces of code ... I think even if I make everyone call gcc with strace I will get a huge amount of information to look trough. Maybe not the best approach in this case.

If the compiler is hard coded without an absolute path, you can create a wrapper that calls gcc via strace, and you filter the strace logs to search for the specified string.
That's just one way.

Having looked at the specs file in the post above, it refers to a relative location - but it may be because gcc has a search path elsewhere. I haven't played with using different spec files before though, but it looks like it'd be more of a local setup problem than something endemic within that toolchain.

Quote:

probably because the native arm 32 bit compiler should be able to handle it natively. The only reason I can think that the pico SDK should force you to use a cross toolchain when not needed is because they did not want to make a separate case for native build while everyone else needs to cross compile.

Building packages on a 133Mhz ARM CPU doesn't sound like something I'd want to be doing.
ARM have provided toolchains for years to save developers the bother of doing it themselves, and spun off Linaro to focus on the developer ecosystem.

The compiler in ARM -current will not produce output for armv6-m architecture (which the Cortex-M0 uses)

Code:

echo "int main() {}" | gcc -march=armv6-m -xc -
<stdin>: In function ‘main’:
<stdin>:1:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI

Unless you're set on using newlib rather than glibc, you may want to build a new Slackware package of gcc and binutils to support the target architecture, by changing the build-time settings; although you may as well build on an x86 instead because it's faster and neither option is 'native'.

Thinking about this for a moment longer: unless you want to build your own base platform, use the OS and tools they provide. It may be easier, at least once you get the toolchain working ;-)

louigi600 · 02-27-2021, 07:26 AM

Ok the quickest way around for not being entirely dependant on RPiOS is to install all that is needed on RPiOS Lite and chroot to it from slackwarearm.
Now I will try to take only what I need and maybe do without chroot.
But I do suspect that the sdk does not fully support setting the toolchain path to non standard location via
export PICO_TOOLCHAIN_PATH=/usr/src/pico/pico-sdk/toolchain

louigi600 · 03-01-2021, 07:00 AM

News: I downloaded the xtoolchain from developer.arm.com and I was able to use it from slackware64-current (would require upgrading cmake on 14.2).
This is what I did to get it to work:

Code:

cd /usr/local
mkdir pico
cd pico

git clone -b master https://github.com/raspberrypi/pico-sdk.git
cd pico-sdk
git submodule update --init


mkdir toolchain
cd toolchain
#download the toolchain and extract it
wget "https://developer.arm.com/-/media/Files/downloads/gnu-rm/10-2020q4/gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2?revision=ca0cbf9c-9de2-491c-ac48-898b5bbc0443&la=en&hash=68760A8AE66026BCF99F05AC017A6A50C6FD832A"
tar xf gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2


#export some environment variables to have it work properly
export PICO_SDK_PATH=/usr/local/pico/pico-sdk
export PICO_TOOLCHAIN_PATH=/usr/local/pico/pico-sdk/toolchain/gcc-arm-none-eabi-10-2020-q4-major
export CMAKE_FIND_ROOT_PATH=/usr/local/pico/pico-sdk/toolchain/gcc-arm-none-eabi-10-2020-q4-major
export CMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER
export CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY
export CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY

I noticed that the pico-toolchain will rebuild the tools like elf2uf2 into each project ... anyway I think I can now get it working on the slackwarearm with a little borrowing from RPiOS.
I will mark the thread as solved once tested on slackwarearm.

edit: was unable to get it to work on slackware arm. Very much same setup but the toolchain was gouged out of a working RPiOS.
Well at least it's working on slackware64-current.

I suppose I did not gouge enough out of RPiOS so I wanted to try the ancient xtoolchain Exaga suggested (so it would be as close as possible to what I did on the intel box) but I noticed that there is no tarball for 32 bit arm host.

louigi600 · 03-12-2021, 12:15 AM

Should anyone want the pico to get automatically mounted and unmountd (the pico will reset after you load the uf2 file so the system will loose the sub-storage device and leave a bogus mount that will require umount -f to clean it up) ...

First create a new udev rule:

Code:

root@darkstar:/lib/udev/rules.d# cat 10-usb-storage.rules
ACTION=="add", KERNEL=="sd?[0-9]", SUBSYSTEM=="block", RUN+="usb_automount"
ACTION=="remove", KERNEL=="sd?[0-9]", SUBSYSTEM=="block", RUN+="usb_automount"
root@darkstar:/lib/udev/rules.d#

then create the usb_automount helper script that the new rule will call: (don't forget to create the mountpoint /mnt/pico)

Code:

root@darkstar:/lib/udev/rules.d# cat /lib/udev/usb_automount
#!/bin/bash 
#this will automatically mount and umount the RPi Pico on /mnt/pico
Name=$(basename $0)
Logger="/usr/bin/logger -p local3.info -t $Name "
#logger -p local3.info -t aoutomount -- testing
Message="$* $DEVNAME $ACTION $ID_FS_LABEL"
$Logger <<< $Message

pico_add ()
{ Message="automounting  $DEVNAME $ID_FS_LABEL"
  $Logger <<< $Message
  /sbin/mount $DEVNAME /mnt/pico && $Logger <<< "mounted" || $Logger <<< "failed"
}

pico_remove ()
{ Message="umounting  $DEVNAME $ID_FS_LABEL"
  $Logger <<< $Message
  /sbin/umount -f /mnt/pico && $Logger <<< "umounted" || $LOGGER "failed"
}

case $ID_FS_LABEL in
  RPI-RP2) pico_$ACTION ;;
  *) $Logger <<< "$ID_FS_LABEL is not configured for any automatic action"
esac
root@darkstar:/lib/udev/rules.d#

Reload the udev rules and you should be good to go:

Code:

udevadm control --reload-rules && udevadm trigger

Press the bootsel button on your pico, plug it in and it should get automatically mountd on /mnt/pico.
Upload your program to it (and sync if you want immediate response) and as the pico reboots /mnt/pico will be umounted.
You can check /var/log/messages is something did not work a expected as the helper scrits logs every step in there.

enine · 03-12-2021, 04:13 PM

I was starting down this road myself. Looking at thier list of deps, what did you use for build-essential and libftdi-dev? I've found equivilent Slackware packages, either already there or on Slackbuilds for everything else I think.

louigi600 · 03-12-2021, 05:21 PM

I'm using the prebuilt cross toolchain from developer.arm.com.
I don't have either of them installed on the Slackware sytem. The only thing on my system that matches partially with libftdi is vala.
I could not get it to work from 14.2 even after upgrading cmake so baybe there i also a minimum C requirement for building the native elf2uf2.
14.2 is some 5 years old anyway so it may get declared EOL as soon as 15.0 is released ... and there are several hints that this may actually happen soon but the official answer is still 15.0 will be released when it's ready.
If you follow to the letter the post #27 it should work on Intel current. Have not been able to get it to work on SlackwareARM ...I will try again.

Where did you find their list of deps ? maybe having a better look at it will reveal to me why I can't get it to work on SlackwareARM.