Attempting compile of pico firmware error?

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
Jibun no kage
Posts: 144
Joined: Mon Jul 25, 2022 9:45 pm

Attempting compile of pico firmware error?

Post by Jibun no kage » Sat Aug 20, 2022 3:48 am

Attempting compile of pico firmware error?

I git cloned the entire micropython master, installed the dependencies, the Unix port complied without issue. Ran tests, no errors. I also pulled the pico SDK.


But when I tried to compile the pico port got the following error. What did I miss?
# git clone https://github.com/raspberrypi/pico-sdk.git /root/pico-sdk
# git -C /root/pico-sdk submodule update --init
# echo 'export PICO_SDK_PATH=/root/pico-sdk' | sudo tee -a /etc/profile.d/pico-sdk.sh
# source /etc/profile

# cd /root/micropython/ports/rp2
# make submodules
# make
/root/micropython/ports/rp2/main.c:40:10: fatal error: tusb.h: No such file or directory
#include "tusb.h"
^~~~~~~~
compilation terminated.
make[3]: *** [CMakeFiles/firmware.dir/build.make:2859: CMakeFiles/firmware.dir/main.c.obj] Error 1
make[2]: *** [CMakeFiles/Makefile2:1641: CMakeFiles/firmware.dir/all] Error 2
make[1]: *** [Makefile:103: all] Error 2
make: *** [Makefile:27: all] Error 2

# cat /etc/profile.d/pico-sdk.sh
declare -x PICO_SDK_PATH="/root/pico-sdk"

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: Attempting compile of pico firmware error?

Post by jimmo » Sat Aug 20, 2022 1:45 pm

See https://github.com/micropython/micropyt ... 2#building

I suspect you haven't run `make submodules` in the ports/rp2 directory. (You're missing the tinyusb submodule)

jomas
Posts: 59
Joined: Mon Dec 25, 2017 1:48 pm
Location: Netherlands

Re: Attempting compile of pico firmware error?

Post by jomas » Sat Aug 20, 2022 7:05 pm

These instructions are wrong/incomplete.

Use the instructions from this document https://datasheets.raspberrypi.com/pico ... on-sdk.pdf
Chapter 1.3

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: Attempting compile of pico firmware error?

Post by jimmo » Mon Aug 22, 2022 12:33 am

jomas wrote:
Sat Aug 20, 2022 7:05 pm
These instructions are wrong/incomplete.
Could you please elaborate?

User avatar
scruss
Posts: 360
Joined: Sat Aug 12, 2017 2:27 pm
Location: Toronto, Canada
Contact:

Re: Attempting compile of pico firmware error?

Post by scruss » Mon Aug 22, 2022 2:50 pm

It's also probably best not to build firmware as root. All the Pico build instructions assume that you're not

Jibun no kage
Posts: 144
Joined: Mon Jul 25, 2022 9:45 pm

Re: Attempting compile of pico firmware error?

Post by Jibun no kage » Mon Aug 22, 2022 3:32 pm

You are right, I created a specific user, and have continued in that user context, given the issues with crosstool-NG use. I also, with a pointer from jimmo, got the right pico SDK setup/staging, so I was successful generating a Pico firmware image. For my overall project I really only need to customize a ESP firmware image, but figuring out how do generate Pico firmware was knowledge development.

@jimmo, the reference to the instructions being incomplete or such, goes back to the seemingly endless of examples of how to do something that are dated, obsolete or whatever. There is so much 'noise' about how to do say generate a Pico firmware image, you find references that may have worked at Jan 2021, but now in 2022 don't, or some 3rd party component has changed breaking an example in 2021 that likely worked. Pico is what, less than 2 years old, and already the noise of how to work with in and custom firmware is an issue. Now image what ESP8266 world is like for some new to the scope.

It is the one off examples that are the most confusing or misleading, and no one (per se) seems to remove dated content. Youtube for example has 10s or more of examples of ESP firmware generation, but none of them likely work, 6 months later. Do the authors remove anything? No, because every time someone watches useless old content, they get credit, view count bump. There is no auditing or system to force content providers to clean up, but there should be.

A example closer to home, use of Python3 deltas to MP firmware generation. Python2 was dropped when? Yet, I found that that every single github example of firmware generation, initially, did not address this explicitly. Where it was addressed was hidden in newer docker images. But with over 40+ docker images, which one is the right one? Moreover, how does documentation between docker versus non-docker methods get out of sync is another example? It is easy to understand, someone has limited time, so they do what they are interested in at the time, and the previous content remains static, becomes dated, then becomes an issue for others. This is not a judgement, just an observation, that people do what they can when they can.

My suggestion is, if you publish it, you are responsible to maintain it. If you can't maintain it, get help or remove it. I understand this, remove it step, is a major mind set difference to the current open-source community approach.

Only read this if interested...

In enterprise computing best practices, we had a method to enforce this idea, as policy. It took top level 3 steps:

1) The original author, engineering, of a solution can NOT do QA or QC of the solution, beyond the DEV lab, nor UAT test environment.
2) Operations must certify via their own QA and QC team, that engineering, has a valid solution in UAT environment
3) Every X interval, depending on the solution, said solution must be re-certified by someone that has NOT done such certification immediately previously before, this includes engineering and operations teams. This was an federal audit requirement for some environments/scopes... the financial firms under federal charter for example.

Given new OS versions, application versions, these 3 steps often happened 1 year or less intervals. But as I am sure you gather, we often validated our solution every few months worst case. I realize this model is difficult for free, volunteer, open source. But it does keep things cleaner more accurate. In my experience, open source needs to have a sponsor to do this well, say for example how Fedora is the playground of what later is integrated to RHEL core, for Red Hat.

An example of when even with an open-source sponsor, there is a tendency to not want to take ownership by some entities...

Real life example, that happened to me in 2014, IBM had a custom virtualization monitoring agent solution, that was used by my firm on well over 300,000 servers, that had elements of open-source and IBM commercial patented code base. I found a horrible bug in the IBM solution, I documented it, reported it, and an IBM tech/software engineer acknowledged the bug, but then stated, since it was in open source side of the product and they could not, would not fix it. Because? They did not own the open-source. And I quote, "We cannot impose our requirements on the open source elements of the design." Are you kidding me? I think I said a few bad words in German at the time, before I got control of myself, the shock subsided.

I replied, "We have committed $10 million on your solution for the next 5 years, we expect it to work right, fix it." IBM refused for about 5 days until, they realized I could recommend to my company at the time, to abandon the solution, not complete said contract. Guess what happened, IBM submitted and championed an open-source fix, that was completed and solved the problem. It was an easy fix by the way, it was about 10 lines of C source, that otherwise would cost us $100,000s in bad monitoring reporting, false alarms, in the first year of use, unless fixed. Dell had a similar problem, why, they used the same open-source component, Dell fixed their issue in 24 hours of notification, and the head of all DELL engineering worldwide, stopped me in a hallway at the VMworld 2014 convention, to ask me if I had tested their fix, and if I planned to approve it. I guess someone at IBM or from the open-source side, told DELL about the issue. How he knew I was even at the VMworld 2014 convention and found me, I have no clue, but he did.

Sorry for the book, and I realize I am preaching to the choir, but if open-source does not have a sponsor, said open source solution maintainers have to more disciplined in behavior not less. But there are few motivators to uphold this high level of discipline, or so history suggests. And as for the core MP maintainers, hey, I posted an issue on GitHub that tripped me up, and it was addressed. Yahoo!

Post Reply