LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 02-25-2021, 04:12 PM   #16
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375

Quote:
Originally Posted by louigi600 View Post
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.

Last edited by Exaga; 02-25-2021 at 04:14 PM. Reason: strawberry fields forever
 
Old 02-25-2021, 05:48 PM   #17
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 428

Rep: Reputation: Disabled
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:
 
1 members found this post helpful.
Old 02-26-2021, 12:50 AM   #18
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
Quote:
Originally Posted by Exaga View Post
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

Last edited by louigi600; 02-26-2021 at 01:22 AM.
 
Old 02-26-2021, 04:28 AM   #19
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 1,036

Rep: Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850
Quote:
Originally Posted by louigi600 View Post
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.
 
1 members found this post helpful.
Old 02-26-2021, 05:56 AM   #20
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
Quote:
Originally Posted by drmozes View Post
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

Last edited by louigi600; 02-26-2021 at 06:03 AM.
 
Old 02-26-2021, 06:11 AM   #21
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 1,036

Rep: Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850
Quote:
Originally Posted by louigi600 View Post
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.
 
Old 02-26-2021, 06:24 AM   #22
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
The toolchain borrowed from RPiOS says : "Using built-in specs"
 
Old 02-26-2021, 06:44 AM   #23
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 1,036

Rep: Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850
Quote:
Originally Posted by louigi600 View Post
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.
 
Old 02-27-2021, 12:49 AM   #24
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
Quote:
Originally Posted by Exaga View Post
[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 View Post
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 ?

Last edited by louigi600; 02-27-2021 at 01:58 AM.
 
Old 02-27-2021, 04:22 AM   #25
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 1,036

Rep: Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850
Quote:
Originally Posted by louigi600 View Post

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 ;-)

Last edited by drmozes; 02-27-2021 at 04:26 AM.
 
Old 02-27-2021, 07:26 AM   #26
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
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
 
Old 03-01-2021, 07:00 AM   #27
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
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.

Last edited by louigi600; 03-03-2021 at 04:00 AM.
 
Old 03-12-2021, 12:15 AM   #28
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
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.

Last edited by louigi600; 03-12-2021 at 12:25 AM.
 
Old 03-12-2021, 04:13 PM   #29
enine
Senior Member
 
Registered: Nov 2003
Distribution: Slackʍɐɹǝ
Posts: 1,303
Blog Entries: 4

Rep: Reputation: 193Reputation: 193
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.
 
Old 03-12-2021, 05:21 PM   #30
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
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.
 
  


Reply

Tags
microcontroller, slackwarearm, toolchain


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] slackwarearm-current RPi official display backlight. moldavia Slackware - ARM 5 02-01-2021 04:42 PM
[SOLVED] Running slackwareARM 14.2 on RPi 4 louigi600 Slackware - ARM 2 05-29-2020 05:47 PM
LXer: GNOME 3.33.2 Released, Krita 4.2 Debuts, RPi Camera Modules on RPi Zeros Power the Penguin Watch Project, Intrinsyc Switches Its Home LXer Syndicated Linux News 0 05-30-2019 06:23 AM
LXer: Mini-PC taps RPi Compute Module and supports RPi 2 LXer Syndicated Linux News 0 02-22-2015 03:03 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 07:46 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration