| Summary: | Eclipse BSP/Kernel Plugin | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] Eclipse Plugin | Reporter: | Jessica <jessica.zhang> |
| Component: | eclipse-plugin | Assignee: | Jessica <jessica.zhang> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Low | CC: | dvhart, hongnax.xu, jjardon, lianhao.lu, song.liu, tom.zanussi, yp.ep.watcher, yp.watcher |
| Version: | unspecified | ||
| Target Milestone: | 1.3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | (p2) - development complete | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
| Bug Depends on: | 1678, 2222 | ||
| Bug Blocks: | |||
|
Description
Jessica
2011-10-04 11:03:18 UTC
Here's a dump of my slides on this topic. Basically my idea was to have 3 scripts to cover the 3 most common use cases for dealing with the kernel in BSPs: - creating a new BSP - setting config items - patching the kernel It's become apparent that people have a hard time dealing with the kernel, and Yocto adds another level of confusion to that, with machine and meta branches in recipes, git, etc. Dealing with the kernel is a big part of dealing with BSPs Creating BSPs is also error-prone, and a lot of it boilerplate. So we should make it all easy if we can for users who just want to get Yocto running on their board. Create a script or wizard to start a BSP with. Allow it to take a few parameters: the name and architecture of the new machine, what it's based on e.g standard, base, preempt-rt, etc, and any others that make sense. This would create a meta-machine layer in userspace. It would also create and point to a local clone of the repo. Within that clone, it would create the machine branch. It would also create the necessary meta branch items. At this point everything is ready to go – the user can proceed to build an image. The other thing that BSP maintainers need to do a lot of is enable and disable config items. Assuming you know the config items to set, you should be able to simply have them added to the BSP, committed to the meta branch, and have a rebuild pick them up. The third common use case is applying a patch to the kernel. Again, assuming the patch is good, you should be able to add them to the machine branch, have them committed, and have a rebuild pick them up. Sometimes a combination of patch + config item is necessary, that can be done as a combination of the above. All of the above should be doable without knowing a thing about git, or the Yocto kernel or even about Yocto. Basically: I have this board, I have this config option that Google tells me enables the CDROM drive, I want to try that without having to read anything. Anything above and beyond that involves reading something or using the other Yocto tools like Hob, in case there's a need to add some userspace changes. Speaking of which, should it be designed to integrate with Hob in some way? Initial implementation would probably just be 3 command-line scripts e.g. makebsp, configbsp, patchbsp. I'm assuming Python would be the best choice, but could be done as shell scripts, etc. *** Bug 1637 has been marked as a duplicate of this bug. *** Since we got the finished version of bsp tool by end of M3 and I was at OSTS and given the time remaining for M4 and the scope of this plugin work, it's likely won't be able to deliver for 1.2 Initial implementation checked in with commit 7a120f8d724ad9b04602fde00a4f0e507f2d9e78 please refer to commit in the last comment The code is not quite functioning due to the latest yocto-bsp tool changes in master. The latest change is in denzil release which functioning well with the latest yocto-bsp |