Add UF2 support #1
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
yonsch force-pushed the support_raspberrypi_pico branch from 0bdba34 to 2f1955d Compare yonsch force-pushed the support_raspberrypi_pico branch 7 times, most recently from 1aad670 to f272057 Compare yonsch force-pushed the support_raspberrypi_pico branch from f272057 to a7de8d0 Compare yonsch force-pushed the support_raspberrypi_pico branch 3 times, most recently from 5f5b148 to d7ef07c Compare 
Added Raspberry Pi's HAL remote. Currently, using a demo repository. Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com>
Added pinctrl_soc_pin_t to allowed typedefs in checkpatch, to allow structs to be used as the configuration type of a pinctrl. Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com>
Added basic support for the RP2040 SoC. Support includes booting and starting the kernel, on one core only. Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com> Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Added support for Raspberry Pi's Pico board, using the RP2040 SoC. Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com>
Added a pinctrl driver for the Raspberry Pi Pico series Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com>
Added a serial driver for the RP2040. Only polling API is supported. Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com>
Added GPIO support for the RP2040 SoC. Only one core is supported. Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com>
yonsch force-pushed the support_raspberrypi_pico branch from d7ef07c to fa6a098 Compare 
Some boards, e.g. RP2040, include the full flash offset in the offset used in their UF2 images, not just the offset from the flash start, so we should default the UF2 offset from the flash offset, but allow overriding it. Signed-off-by: Peter Johanson <peter@peterjohanson.com>
RP2040 uses a fixed offset for UF2 images of the flash start address, so default to 0x10000000 for that series, and add the family ID default. Signed-off-by: Peter Johanson <peter@peterjohanson.com>
Enable the UF2 build output for the Pico. Signed-off-by: Peter Johanson <peter@peterjohanson.com>
Add USB device driver for Rasberry Pico family of controllers.
Add `adafruit_bk2040` board with `sparkfun,pro-micro` header. Signed-off-by: Peter Johanson <peter@peterjohanson.com>
petejohanson force-pushed the support_raspberrypi_pico branch from ab4712f to a9857af Compare yonsch force-pushed the support_raspberrypi_pico branch 3 times, most recently from 42b860f to 0fdb49d Compare yonsch force-pushed the support_raspberrypi_pico branch from 0fdb49d to 3ed4d59 Compare yonsch force-pushed the support_raspberrypi_pico branch 2 times, most recently from 86d7ea3 to 314c4c4 Compare yonsch force-pushed the support_raspberrypi_pico branch 4 times, most recently from 2e9c80f to a69989e Compare yonsch force-pushed the support_raspberrypi_pico branch 12 times, most recently from e441781 to c93f206 Compare yonsch pushed a commit that referenced this pull request Dec 8, 2022
This patch reworks how fragments are handled in the net_buf infrastructure. In particular, it removes the union around the node and frags members in the main net_buf structure. This is done so that both can be used at the same time, at a cost of 4 bytes per net_buf instance. This implies that the layout of net_buf instances changes whenever being inserted into a queue (fifo or lifo) or a linked list (slist). Until now, this is what happened when enqueueing a net_buf with frags in a queue or linked list: 1.1 Before enqueueing: +--------+ +--------+ +--------+ |#1 node|\ |#2 node|\ |#3 node|\ | | \ | | \ | | \ | frags |------| frags |------| frags |------NULL +--------+ +--------+ +--------+ net_buf #1 has 2 fragments, net_bufs #2 and #3. Both the node and frags pointers (they are the same, since they are unioned) point to the next fragment. 1.2 After enqueueing: +--------+ +--------+ +--------+ +--------+ +--------+ |q/slist |------|#1 node|------|#2 node|------|#3 node|------|q/slist | |node | | *flag | / | *flag | / | | / |node | | | | frags |/ | frags |/ | frags |/ | | +--------+ +--------+ +--------+ +--------+ +--------+ When enqueing a net_buf (in this case #1) that contains fragments, the current net_buf implementation actually enqueues all the fragments (in this case #2 and #3) as actual queue/slist items, since node and frags are one and the same in memory. This makes the enqueuing operation expensive and it makes it impossible to atomically dequeue. The `*flag` notation here means that the `flags` member has been set to `NET_BUF_FRAGS` in order to be able to reconstruct the frags pointers when dequeuing. After this patch, the layout changes considerably: 2.1 Before enqueueing: +--------+ +--------+ +--------+ |#1 node|--NULL |#2 node|--NULL |#3 node|--NULL | | | | | | | frags |-------| frags |-------| frags |------NULL +--------+ +--------+ +--------+ This is very similar to 1.1, except that now node and frags are different pointers, so node is just set to NULL. 2.2 After enqueueing: +--------+ +--------+ +--------+ |q/slist |-------|#1 node|-------|q/slist | |node | | | |node | | | | frags | | | +--------+ +--------+ +--------+ | +--------+ +--------+ | |#2 node|--NULL |#3 node|--NULL | | | | | +------------| frags |-------| frags |------NULL +--------+ +--------+ When enqueuing net_buf #1, now we only enqueue that very item, instead of enqueing the frags as well, since now node and frags are separate pointers. This simplifies the operation and makes it atomic. Resolves zephyrproject-rtos#52718. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
yonsch pushed a commit that referenced this pull request Jan 28, 2024
Previously the sample was using some headers that aren't available to the host, now we can add a `Makefile.host` to compile the example on a POSIX OS like Linux: ``` # Go to the sample dir cd ${ZEPHYR_BASE}/samples/posix/uname # Compile the sample make -f Makefile.host # Run the binary ./build/uname sysname[65]: Linux nodename[65]: LAPTOP-YC release[65]: 5.10.16.3-microsoft-standard-WSL2 version[65]: #1 SMP Fri Apr 2 22:23:49 UTC 2021 machine[65]: x86_64 ``` Signed-off-by: Yong Cong Sin <ycsin@meta.com> Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
One thing to help with testing, if interested. This is the couple small bits needed to make the UF2 build output stuff I added a while back generate UF2 images for RP2040.
I'm using this for my QT Py RP2040 and works fine, but I sadly don't have a pico to test on yet.
Also, would you like me to open a PR, or include in here, my board definition for the QT Py?