-
Notifications
You must be signed in to change notification settings - Fork 43
Intel keembay #60
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
Intel keembay #60
Conversation
Here's |
Hi @rgantois, could I ask you for a review and to let me know if there are any specific tests you'd want to run as the Keembay is not that common? |
Hi @phodina, thanks a bunch for the contribution! I'm a bit short on time at the moment but I'll do my best to review it next week. About the tests to be run on the target SoCs, I'd say that a basic snagrecover run should be sufficient, but I'll tell you if I think of something else. |
Hello, I've skimmed across this PR and there is one glaring issue: you're adding flashing code to snagrecover. Snagrecover should only handle recovery, i.e. getting a bootloader to run on the target without flashing anything to non-volatile storage. Anything that happens after this is out of scope for snagrecover, and will be handled by snagflash. So in your case, only the FIP step should be implemented in snagrecover. Once a bootloader is running in RAM and exposing a fastboot gadget, everything else can be handled in a board-agnostic way using snagflash commands. This is something that needs to be fixed before I review this PR further, since it will probably involve removing a lot of code from your current proposal. |
Okay, thanks for the comment . Will move the flashing code from snagrecover and move it to the snagflash. |
Cleanup the code to use snagrecover utilities and improved commit messages.
|
|
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.
Nice work! I've pointed out a few changes I'd like you to make before I merge this.
@rgantois what about the |
Reworked most of the comments, just need to test it again with real HW + test at least 2 devices for the issue above |
Yes indeed, that would be preferable. |
@rgantois LTGM
|
Added udev rule to allow access to Intel Keembay USB devices by default. This rule sets proper permissions and adds the "uaccess" tag for the following device: - Vendor ID 8087, Product ID 0b39 (recovery mode) Signed-off-by: Petr Hodina <petr.hodina@luxonis.com>
Extended documentation to include Intel Keembay SoC support: - Updated the list of supported SoCs in the README - Added a new section in board_setup.md explaining how to enter recovery mode and identifying USB device states - Added details in fw_binaries.md about the required firmware image packages (FIP) and expected filenames per board type Signed-off-by: Petr Hodina <petr.hodina@luxonis.com>
d224a67
to
78abc5e
Compare
Add initial support for Intel Keembay boards in Snagrecover. - Device specific recovery implementation in `recoveries/keembay.py`, which handles download of the Firmware Image Package (FIP) - Integration of the Keembay USB vendor/product ID (8087:0b39) into `config.py`. - Addition of Keembay to the `supported_socs.yaml` list. - New firmware configuration template `keembay-generic.yaml` covering FIP - Hooking Keembay into the recovery dispatcher in `utils.py`. Signed-off-by: Petr Hodina <petr.hodina@luxonis.com>
These patches add support for Intel Keembay SoC.
The SoC boots from eMMC ATF+u-boot stored in the boot bank and with support for the fastboot protocol.