* [Qemu-arm] Beagle Board support @ 2019-08-10 3:38 Esteban Bosse 2019-08-10 10:07 ` Alex Bennée 2019-08-10 14:01 ` Peter Maydell 0 siblings, 2 replies; 7+ messages in thread From: Esteban Bosse @ 2019-08-10 3:38 UTC (permalink / raw) To: qemu-arm [-- Attachment #1: Type: text/plain, Size: 155 bytes --] Hi, I am new in this world, but I want to port the old beagle support for qemu-linaro to mainstream. Someone is actually working on it or is interested? [-- Attachment #2: Type: text/html, Size: 214 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-arm] Beagle Board support 2019-08-10 3:38 [Qemu-arm] Beagle Board support Esteban Bosse @ 2019-08-10 10:07 ` Alex Bennée 2019-08-10 15:02 ` Esteban Bosse 2019-08-10 14:01 ` Peter Maydell 1 sibling, 1 reply; 7+ messages in thread From: Alex Bennée @ 2019-08-10 10:07 UTC (permalink / raw) To: qemu-arm Esteban Bosse <estebanbosse@gmail.com> writes: > Hi, > > I am new in this world, but I want to port the old beagle support for > qemu-linaro to mainstream. I think the main problem is the chip is no longer supported by TI and I guess less likely to be supported in upstream OSes in the future. > Someone is actually working on it or is interested? Not that I'm aware of. If you want to do the port and are willing to be a maintainer of it going forward then I guess it would be doable. Is there any particular reason you want it in upstream rather than just using the old qemu-linaro branch for your use case? -- Alex Bennée ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-arm] Beagle Board support 2019-08-10 10:07 ` Alex Bennée @ 2019-08-10 15:02 ` Esteban Bosse 0 siblings, 0 replies; 7+ messages in thread From: Esteban Bosse @ 2019-08-10 15:02 UTC (permalink / raw) To: Alex Bennée; +Cc: qemu-arm [-- Attachment #1: Type: text/plain, Size: 948 bytes --] El sáb., 10 ago. 2019 19:07, Alex Bennée <alex.bennee@linaro.org> escribió: > > Esteban Bosse <estebanbosse@gmail.com> writes: > > > Hi, > > > > I am new in this world, but I want to port the old beagle support for > > qemu-linaro to mainstream. > > I think the main problem is the chip is no longer supported by TI and I > guess less likely to be supported in upstream OSes in the future. > :/ > > > Someone is actually working on it or is interested? > > Not that I'm aware of. If you want to do the port and are willing to be > a maintainer of it going forward then I guess it would be doable. Is > there any particular reason you want it in upstream rather than just > using the old qemu-linaro branch for your use case? > There is no big reason, I just want to learn and I believe that is a good project to start beacouse it "works" (with the old api) and I can use it as base. > > -- > Alex Bennée > > [-- Attachment #2: Type: text/html, Size: 1752 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-arm] Beagle Board support 2019-08-10 3:38 [Qemu-arm] Beagle Board support Esteban Bosse 2019-08-10 10:07 ` Alex Bennée @ 2019-08-10 14:01 ` Peter Maydell 2019-08-10 15:23 ` Esteban Bosse 1 sibling, 1 reply; 7+ messages in thread From: Peter Maydell @ 2019-08-10 14:01 UTC (permalink / raw) To: Esteban Bosse; +Cc: qemu-arm On Sat, 10 Aug 2019 at 04:39, Esteban Bosse <estebanbosse@gmail.com> wrote: > I am new in this world, but I want to port the old beagle support for qemu-linaro to mainstream. That would certainly be nice. The major issue is that the patchset in that tree is (a) often in an older style of API that would need to be updated to use the current recommended-practice APIs to go upstream, and (b) in some places still has multiple changes tangled together that would need to be disentangled to form a clean reviewable patchset. I'm happy to provide advice and code review if you're interested in doing this work and helping to maintain it in the upstream tree. thanks -- PMM ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-arm] Beagle Board support 2019-08-10 14:01 ` Peter Maydell @ 2019-08-10 15:23 ` Esteban Bosse 2019-08-12 15:32 ` [Qemu-devel] " Peter Maydell 0 siblings, 1 reply; 7+ messages in thread From: Esteban Bosse @ 2019-08-10 15:23 UTC (permalink / raw) To: Peter Maydell; +Cc: qemu-arm [-- Attachment #1: Type: text/plain, Size: 1477 bytes --] El sáb., 10 ago. 2019 23:01, Peter Maydell <peter.maydell@linaro.org> escribió: > On Sat, 10 Aug 2019 at 04:39, Esteban Bosse <estebanbosse@gmail.com> > wrote: > > I am new in this world, but I want to port the old beagle support for > qemu-linaro to mainstream. > > That would certainly be nice. The major issue is that the > patchset in that tree is (a) often in an older style > of API that would need to be updated to use the current > recommended-practice APIs to go upstream, and (b) in > some places still has multiple changes tangled together > that would need to be disentangled to form a clean > reviewable patchset. > (a) Sounds "not impossible" then for a beginer, hahaha. I am looking other boards like Musca to use it as example (b) I don't know yet how to make the patches I have to learn everything. > I'm happy to provide advice and code review if you're > interested in doing this work and helping to maintain > it in the upstream tree. > Yes! I am interested, I have a repo where I am doing my firsts trys to understand how qemu and the beagle are. How do you recommend to start? I think that I can understand some things in the old beagle.c file but the omap3.c it's more heavy. Maybe I can start with de omap3.c trying to refactor and split it in more files styled for the new API. What files do you recommend to read to try to understand more about the CPU model? > thanks > -- PMM > Thank you! > [-- Attachment #2: Type: text/html, Size: 2936 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-arm] Beagle Board support 2019-08-10 15:23 ` Esteban Bosse @ 2019-08-12 15:32 ` Peter Maydell 0 siblings, 0 replies; 7+ messages in thread From: Peter Maydell @ 2019-08-12 15:32 UTC (permalink / raw) To: Esteban Bosse; +Cc: qemu-arm, QEMU Developers (I've added qemu-devel to the cc list; some people don't read the qemu-arm list.) On Sat, 10 Aug 2019 at 16:24, Esteban Bosse <estebanbosse@gmail.com> wrote: > El sáb., 10 ago. 2019 23:01, Peter Maydell <peter.maydell@linaro.org> escribió: >> On Sat, 10 Aug 2019 at 04:39, Esteban Bosse <estebanbosse@gmail.com> wrote: >> > I am new in this world, but I want to port the old beagle support for qemu-linaro to mainstream. >> >> That would certainly be nice. The major issue is that the >> patchset in that tree is (a) often in an older style >> of API that would need to be updated to use the current >> recommended-practice APIs to go upstream, and (b) in >> some places still has multiple changes tangled together >> that would need to be disentangled to form a clean >> reviewable patchset. > > (a) Sounds "not impossible" then for a beginer, hahaha. > I am looking other boards like Musca to use it as example > > (b) I don't know yet how to make the patches I have to learn everything. > >> >> I'm happy to provide advice and code review if you're >> interested in doing this work and helping to maintain >> it in the upstream tree. > > > Yes! I am interested, I have a repo where I am doing my firsts trys to understand how qemu and the beagle are. > > How do you recommend to start? Here's something I wrote up in 2015 the last time somebody talked about maybe trying to get the beagle/omap3 changes into master: The initial steps here would be: 1) rebase the patchset on to qemu master and fix up the breakage due to API changes in qemu [this will be moderately painful if you haven't been following the API changes as they happened; if you're interested in taking on the omap3 patches then I could maybe do this step for you] 2) add support for direct boot of a guest kernel via "-kernel" (currently only "boot via an SD card image" is supported, which is awkward because the u-boot image insists on checking every device on the board and won't boot if any are missing) 3) build a cut-down minimally configured kernel that only needs the smallest possible set of devices [in particular, no SPI, I2C, MMC or graphics] 4) reorder the patchstack so that it starts with those relating to the required minimal device set and the SoC model and the board model, and the complicated ones to do with I2C etc are afterwards; check the kernel boots on this initial set 5) update the patches to correspond to current QEMU practice for QOM device modelling (the code in that tree is somewhat old and does many things in out of date ways) 6) submit the minimal-device patches and get them through code review and into QEMU 7) then start trying to clean up the remaining patches one device at a time You'll need (or will learn :-)) familiarity with handling stacks of patches in git, rebasing them, reordering them, splitting them, and so on. Personally I use 'stgit' as a frontend to doing that, but you can do it all with raw git too. Back in 2014 or whenever it was I abandoned the idea of doing this upstreaming work I reckoned it was probably a couple of months worth of (full-time) work to get everything upstream. thanks -- PMM ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [Qemu-arm] Beagle Board support @ 2019-08-12 15:32 ` Peter Maydell 0 siblings, 0 replies; 7+ messages in thread From: Peter Maydell @ 2019-08-12 15:32 UTC (permalink / raw) To: Esteban Bosse; +Cc: qemu-arm, QEMU Developers (I've added qemu-devel to the cc list; some people don't read the qemu-arm list.) On Sat, 10 Aug 2019 at 16:24, Esteban Bosse <estebanbosse@gmail.com> wrote: > El sáb., 10 ago. 2019 23:01, Peter Maydell <peter.maydell@linaro.org> escribió: >> On Sat, 10 Aug 2019 at 04:39, Esteban Bosse <estebanbosse@gmail.com> wrote: >> > I am new in this world, but I want to port the old beagle support for qemu-linaro to mainstream. >> >> That would certainly be nice. The major issue is that the >> patchset in that tree is (a) often in an older style >> of API that would need to be updated to use the current >> recommended-practice APIs to go upstream, and (b) in >> some places still has multiple changes tangled together >> that would need to be disentangled to form a clean >> reviewable patchset. > > (a) Sounds "not impossible" then for a beginer, hahaha. > I am looking other boards like Musca to use it as example > > (b) I don't know yet how to make the patches I have to learn everything. > >> >> I'm happy to provide advice and code review if you're >> interested in doing this work and helping to maintain >> it in the upstream tree. > > > Yes! I am interested, I have a repo where I am doing my firsts trys to understand how qemu and the beagle are. > > How do you recommend to start? Here's something I wrote up in 2015 the last time somebody talked about maybe trying to get the beagle/omap3 changes into master: The initial steps here would be: 1) rebase the patchset on to qemu master and fix up the breakage due to API changes in qemu [this will be moderately painful if you haven't been following the API changes as they happened; if you're interested in taking on the omap3 patches then I could maybe do this step for you] 2) add support for direct boot of a guest kernel via "-kernel" (currently only "boot via an SD card image" is supported, which is awkward because the u-boot image insists on checking every device on the board and won't boot if any are missing) 3) build a cut-down minimally configured kernel that only needs the smallest possible set of devices [in particular, no SPI, I2C, MMC or graphics] 4) reorder the patchstack so that it starts with those relating to the required minimal device set and the SoC model and the board model, and the complicated ones to do with I2C etc are afterwards; check the kernel boots on this initial set 5) update the patches to correspond to current QEMU practice for QOM device modelling (the code in that tree is somewhat old and does many things in out of date ways) 6) submit the minimal-device patches and get them through code review and into QEMU 7) then start trying to clean up the remaining patches one device at a time You'll need (or will learn :-)) familiarity with handling stacks of patches in git, rebasing them, reordering them, splitting them, and so on. Personally I use 'stgit' as a frontend to doing that, but you can do it all with raw git too. Back in 2014 or whenever it was I abandoned the idea of doing this upstreaming work I reckoned it was probably a couple of months worth of (full-time) work to get everything upstream. thanks -- PMM ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-08-12 15:33 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-08-10 3:38 [Qemu-arm] Beagle Board support Esteban Bosse 2019-08-10 10:07 ` Alex Bennée 2019-08-10 15:02 ` Esteban Bosse 2019-08-10 14:01 ` Peter Maydell 2019-08-10 15:23 ` Esteban Bosse 2019-08-12 15:32 ` Peter Maydell 2019-08-12 15:32 ` [Qemu-devel] " Peter Maydell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.