Skip to content
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

Rework paths for eeprom locations. #17326

Merged
merged 4 commits into from
Jun 7, 2022
Merged

Conversation

tzarc
Copy link
Member

@tzarc tzarc commented Jun 7, 2022

Description

NVRAM/Wear-leveling prepwork.

Types of Changes

  • Core
  • Bugfix
  • New feature
  • Enhancement/optimization
  • Keyboard (addition or update)
  • Keymap/layout/userspace (addition or update)
  • Documentation

Checklist

  • My code follows the code style of this project: C, Python
  • I have read the PR Checklist document and have made the appropriate changes.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • I have tested the changes and verified that they work and don't break anything (as well as I can manage).

@tzarc tzarc requested a review from a team June 7, 2022 05:33
@github-actions github-actions bot added the core label Jun 7, 2022
Copy link
Contributor

@sigprof sigprof left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

platforms/chibios/flash.mkplatforms/chibios/drivers/flash/flash.mk move looks like a mistake.

And apparently some include path adjustment is needed to make #include "flash_stm32.h" work.

@tzarc
Copy link
Member Author

tzarc commented Jun 7, 2022

platforms/chibios/flash.mkplatforms/chibios/drivers/flash/flash.mk move looks like a mistake.

And apparently some include path adjustment is needed to make #include "flash_stm32.h" work.

Yeah, the file move was in error.
Not sure why you're seeing an issue with the #include "flash_stm32.h" -- multibuild worked fine?

@drashna
Copy link
Member

drashna commented Jun 7, 2022

It's the test itself that is erroring out.

Edit: Digging into this a bit more, and it looks like the tests assume/need the chibiOS driver paths for both the c and h files. Yay.

In the couple of files, full path includes will fix the errors:

#include "platforms/chibios/drivers/flash/flash_stm32.h"
#include "platforms/chibios/drivers/eeprom/eeprom_stm32.h"

However, that introduces additional errors. Name:

remake[1]: *** No rule to make target '.build/test_obj/eeprom_stm32_large/platforms/chibios/eeprom_stm32.o', needed by '.build/test/eeprom_stm32_large.elf'.  Stop.

@tzarc
Copy link
Member Author

tzarc commented Jun 7, 2022

Yeah, those tests are kinda gross.
Over time they'll swap over to the wear-leveling implementations, so we can get rid of these in due course.

@drashna drashna requested a review from a team June 7, 2022 06:39
@tzarc tzarc requested a review from sigprof June 7, 2022 06:51
@KarlK90
Copy link
Member

KarlK90 commented Jun 7, 2022

For the rp2040 PR I took the approach to move vendor specific drivers under platforms/chibios/drivers/RP/RP2040 and then serial_vendor.c and ws2812_vendor.c which allows automatic pickup by the makefile system. This might be an approach for the eeprom implementations as well? E.g. for stm32f4 STM32/STM32F4/eeprom_vendor.c

@tzarc tzarc merged commit 1085500 into qmk:develop Jun 7, 2022
@tzarc tzarc deleted the eeprom-restructure branch June 7, 2022 23:42
0xcharly pushed a commit to Bastardkb/bastardkb-qmk that referenced this pull request Jul 4, 2022
* Rework paths for eeprom locations.

* File relocation.

* Wrong file move.

* Fixup test paths.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants