-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Make BFLB not use the SDK code #91977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
d325362
3bad2c8
36ed3e2
bf73fa5
4d28783
946d235
523119b
06baa94
382a12e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,4 +2,4 @@ | |
|
||
interface cmsis-dap | ||
|
||
adapter speed 1000 | ||
adapter speed 400 |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,40 +6,35 @@ | |
|
||
#include <zephyr/kernel.h> | ||
#include <zephyr/drivers/pinctrl.h> | ||
#include <bflb_pinctrl.h> | ||
#include <bflb_glb.h> | ||
#include <bflb_gpio.h> | ||
|
||
/* clang-format off */ | ||
#include <zephyr/dt-bindings/pinctrl/bflb-common-pinctrl.h> | ||
|
||
int pinctrl_configure_pins(const pinctrl_soc_pin_t *pins, uint8_t pin_cnt, | ||
uintptr_t reg) | ||
#if defined(CONFIG_SOC_SERIES_BL60X) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would like to have a separated file to handle each SoC or combine then when appropriate. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's what i wanted to do initially but I remember being told this wasn't the way. Edit: need 2, one for bl70x and bl60x pinctrl, one for bl61x, same for GPIO. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
No problem I think. I would like to have a common pinctrl definition that we can use for all SoCs. Then we share the same Then we do something like
This way we keep code very well organized I supposed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
#include <zephyr/dt-bindings/pinctrl/bl60x-pinctrl.h> | ||
#else | ||
#error "Unsupported Platform" | ||
#endif | ||
|
||
void pinctrl_bflb_configure_uart(uint8_t pin, uint8_t func); | ||
void pinctrl_bflb_init_pin(pinctrl_soc_pin_t pin); | ||
|
||
int pinctrl_configure_pins(const pinctrl_soc_pin_t *pins, uint8_t pin_cnt, uintptr_t reg) | ||
{ | ||
GLB_GPIO_Cfg_Type pincfg; | ||
uint8_t i; | ||
|
||
ARG_UNUSED(reg); | ||
|
||
for (i = 0U; i < pin_cnt; i++) { | ||
pincfg.gpioFun = BFLB_PINMUX_GET_FUN(pins[i]); | ||
pincfg.gpioMode = BFLB_PINMUX_GET_MODE(pins[i]); | ||
pincfg.gpioPin = BFLB_PINMUX_GET_PIN(pins[i]); | ||
pincfg.pullType = BFLB_PINMUX_GET_PULL_MODES(pins[i]); | ||
pincfg.smtCtrl = BFLB_PINMUX_GET_SMT(pins[i]); | ||
pincfg.drive = BFLB_PINMUX_GET_DRIVER_STRENGTH(pins[i]); | ||
|
||
if (pincfg.gpioFun == BFLB_PINMUX_FUN_INST_uart0) { | ||
GLB_UART_Fun_Sel(pincfg.gpioPin % 8, | ||
(BFLB_PINMUX_GET_INST(pins[i])) | ||
* 0x4U /* rts, cts, rx, tx */ | ||
+ BFLB_PINMUX_GET_SIGNAL(pins[i]) | ||
); | ||
|
||
if ((BFLB_PINMUX_GET_FUN(pins[i]) & BFLB_PINMUX_FUN_MASK) | ||
== BFLB_PINMUX_FUN_INST_uart0) { | ||
pinctrl_bflb_configure_uart(BFLB_PINMUX_GET_PIN(pins[i]), | ||
BFLB_PINMUX_GET_SIGNAL(pins[i]) + 4 * BFLB_PINMUX_GET_INST(pins[i])); | ||
} | ||
|
||
GLB_GPIO_Init(&pincfg); | ||
/* gpio init*/ | ||
pinctrl_bflb_init_pin(pins[i]); | ||
} | ||
|
||
return 0; | ||
} | ||
|
||
/* clang-format on */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand your intention here. As far I know, Bouffalo uses a SPI bus to have access to flash memory. This means that we should keep that clear in the devicetree.
For instance, ST defines all the internal memory only for MCUboot and external NOR to application:
zephyr/boards/st/nucleo_h7s3l8/nucleo_h7s3l8.dts
Lines 169 to 230 in b3ccee4
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a dedicated flash controller that is not capable of doing general SPI, and that manages both internal OR external flash (or 'and' for bl616, but on a bank basis), transport is irrelevant and it cant be made to fit as anything purely SPI. ST example is completly irrelevant here, there is only one memory chip, either outside or inside, for bl60x.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm getting confuse because of this:
https://github.com/bouffalolab/bouffalo_sdk/blob/811e8c1f1cd62695cedd47367f0bf2c624707bc6/drivers/lhal/src/flash/bflb_sflash.c#L160-L178
and here there is an API to get the jedecid:
https://github.com/bouffalolab/bouffalo_sdk/blob/811e8c1f1cd62695cedd47367f0bf2c624707bc6/drivers/lhal/src/flash/bflb_xip_sflash.h#L81
So, the impression I have is that, this serial flash controller really rely on a bus like SPI or QSPI and it could maybe, autoconfigure using the JEDEC parameters. In some cases, we still need to define the memory parameters for some devices in Zephyr.
In this case, if this SFLASH CTRL uses a NOR memory it seems that we still need to define the phandle or the NOR memory definitions in the devicetree on my understanding. Then, inside of this NOR block we define the partitions.
At end, this SoC runs XIP from external NOR (or internal NOR). It seems to be a multi-chip module (MCM) or multi-chip package (MCP) which means that there is no real internal flash.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could auto-configure from the jedec settings (this is what the flash tool does in fact, and it puts those parameters in the boot header, which is why we dont need to do it ourselves out of using bank2 on bl616), but there is really no direct relation between them and the jedec ID (it's a mix of timing settings and commands to use to drive the flash), they are only the ones associated with a specific flash type, so we would need to copy the data store somewhere for those settings.
Do you simply mean replacing soc-nv-flash with jedec-nor?