Re: [ptxdist] Classpath -- move out from staging?
El vie, 20 oct 2023 a las 10:06, Michael Olbrich () escribió: > > Hi, > > On Wed, Oct 18, 2023 at 10:34:10AM +0200, Guillermo Rodriguez Garcia wrote: > > El mié, 18 oct 2023 a las 8:00, Michael Olbrich > > () escribió: > > > On Sat, Oct 14, 2023 at 04:49:12PM +0200, Guillermo Rodriguez Garcia > > > wrote: > > > > I see that the classpath package was moved to staging in commit > > > > f2afdd541d3dc1cbac965ddaf899009780de2aae, with a note stating that it > > > > could not be built with any current (Java) distribution. > > > > > > > > My team and I are still using this actively, and it can be built with > > > > OpenJDK 8 which is still supported and is expected to be be supported > > > > for a while (for example Adoptium states it will be supported "At > > > > least until Nov 2026"). > > > > > > > > Can we move this out of staging? If so I will prepare a patch. > > > > > > No. In fakt, I should have removed it entirely some time ago. I just > > > missed > > > it. And I will remove it soon. The problem is, that I cannot even > > > build-test it any more and that's the minimum requirement for having it > > > upstream. > > > > > > It should build fine with OpenJDK 8 which is still fully supported and > > widely available. > > Are you having problems with this? > > Can you share the details? > > My main test infrastructure runs on Debian. And OpenJDK 8 (and javah, the > tool that is missing) was removed a long time ago. > > What's the benefit of having this upstream? You can easily put the package > in your BSP. Is has no special requirements. You seem to be the only user > of this package and without test coverage Upstream there is no benefit in > keeping it here. Well, yes, of course I can easily put the package in our BSPs (the same could be said for any other package, though). The benefits of having it upstream are: 1. Not having to manually add this to every BSP (we maintain a bunch of them already and will be adding more) 2. Having it upstream may increase visibility of the package and thus possibly increase the chances of people using it (it wouldn't be the first time I learn about a package because I see it in ptxdist and end up using it in our BSPs). More people using it is always a good thing (more eyes). 3. Test coverage upstream, if we can find a way to fix that. Would you be willing to reconsider if we can find a way to work around the missing javah? BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: [ptxdist] Classpath -- move out from staging?
Hi Michael, El mié, 18 oct 2023 a las 8:00, Michael Olbrich () escribió: > > Hi, > > On Sat, Oct 14, 2023 at 04:49:12PM +0200, Guillermo Rodriguez Garcia wrote: > > I see that the classpath package was moved to staging in commit > > f2afdd541d3dc1cbac965ddaf899009780de2aae, with a note stating that it > > could not be built with any current (Java) distribution. > > > > My team and I are still using this actively, and it can be built with > > OpenJDK 8 which is still supported and is expected to be be supported > > for a while (for example Adoptium states it will be supported "At > > least until Nov 2026"). > > > > Can we move this out of staging? If so I will prepare a patch. > > No. In fakt, I should have removed it entirely some time ago. I just missed > it. And I will remove it soon. The problem is, that I cannot even > build-test it any more and that's the minimum requirement for having it > upstream. It should build fine with OpenJDK 8 which is still fully supported and widely available. Are you having problems with this? Can you share the details? Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
[ptxdist] Classpath -- move out from staging?
Hi Michael, all, I see that the classpath package was moved to staging in commit f2afdd541d3dc1cbac965ddaf899009780de2aae, with a note stating that it could not be built with any current (Java) distribution. My team and I are still using this actively, and it can be built with OpenJDK 8 which is still supported and is expected to be be supported for a while (for example Adoptium states it will be supported "At least until Nov 2026"). Can we move this out of staging? If so I will prepare a patch. BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: [ptxdist] Regenerate license report
El vie, 21 abr 2023 a las 7:29, Michael Olbrich () escribió: > On Thu, Apr 20, 2023 at 12:24:21PM +0200, Guillermo Rodriguez Garcia wrote: > > El mié, 19 abr 2023 a las 10:18, Michael Olbrich (< > m.olbr...@pengutronix.de>) > > escribió: > > > On Wed, Apr 19, 2023 at 09:28:02AM +0200, Guillermo Rodriguez Garcia > wrote: > > > > El miércoles, 19 de abril de 2023, Michael Olbrich < > > > m.olbr...@pengutronix.de> > > > > escribió: > > > > > On Tue, Apr 18, 2023 at 05:18:58PM +0200, Guillermo Rodriguez > Garcia > > > wrote: > > > > > > El mar, 18 abr 2023 a las 16:37, Guillermo Rodriguez Garcia (< > > > > > > guille.rodrig...@gmail.com>) escribió: > > > > > > > Is there a way to force ptxdist to regenerate a license-report > > > after it > > > > > > > has been generated already with "ptxdist make license-report" ? > > > > > > > > > > > > > > I didn't find any "clean" rule for this, and the naive > approach of > > > just > > > > > > > deleting the platform-xxx/report dir doesn't work (trying to > run > > > > > ptxdist > > > > > > > make license-report after this results in errors). > > > > > > > > > > > > > > > > > > > The best I have found is: > > > > > > > > > > > > rm -rf platform-xxx/report > > > > > > rm platform-xxx/state/*.report > > > > > > > > > > > > But I assume there is a cleaner way :-) > > > > > > > > > > That depends a bit on why you want to regenerate the report. If you > > > need to > > > > > regenerate the per package stuff in platform-xxx/report/ then > removing > > > > > platform-xxx/state/*.report is the way to go. If that part remains > > > > > unchanged, then just removing the pdfs should be enough. > > > > > > > > > > > > This was because of adjustments to license info in the .make files > so I > > > > guess I need to remove the .report files :-) > > > > > > > > Thank you for the response, > > > > > > If you change a .make file, then that should be detected automatically > and > > > the license info for that package should be regenerated automatically. > > > It should not be necessary to do anything manually. > > > > > > > Yes; the problem is that I was not actually changing the .make files. > > Instead I have a rules/post/licenses.make file where I override some of > the > > xxx_LICENSE variables. I was looking for a way to regenerate the report > > when this file was updated. Anyway I think all is clear now with your > > explanations. Thanks again! > > Which PTXdist version? Since PTXdist 2021.12.0 you can use > rules/..make for that. These files are included directly > after rules/.make and they are part of the hash that determines if a > package needs to be rebuilt. > Using 2021.07.0 for this project. The goal with the rules/post/licenses.make was to have one central place with all necessary "tweaks" to the xxx_LICENSE vars; in this specific case this makes it easier (for me) than having the info scattered through multiple files. Anyway the hint about rules/..make is useful, thank you! Best regards, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: [ptxdist] Regenerate license report
El mié, 19 abr 2023 a las 10:18, Michael Olbrich () escribió: > On Wed, Apr 19, 2023 at 09:28:02AM +0200, Guillermo Rodriguez Garcia wrote: > > El miércoles, 19 de abril de 2023, Michael Olbrich < > m.olbr...@pengutronix.de> > > escribió: > > > On Tue, Apr 18, 2023 at 05:18:58PM +0200, Guillermo Rodriguez Garcia > wrote: > > > > El mar, 18 abr 2023 a las 16:37, Guillermo Rodriguez Garcia (< > > > > guille.rodrig...@gmail.com>) escribió: > > > > > Is there a way to force ptxdist to regenerate a license-report > after it > > > > > has been generated already with "ptxdist make license-report" ? > > > > > > > > > > I didn't find any "clean" rule for this, and the naive approach of > just > > > > > deleting the platform-xxx/report dir doesn't work (trying to run > > > ptxdist > > > > > make license-report after this results in errors). > > > > > > > > > > > > > The best I have found is: > > > > > > > > rm -rf platform-xxx/report > > > > rm platform-xxx/state/*.report > > > > > > > > But I assume there is a cleaner way :-) > > > > > > That depends a bit on why you want to regenerate the report. If you > need to > > > regenerate the per package stuff in platform-xxx/report/ then removing > > > platform-xxx/state/*.report is the way to go. If that part remains > > > unchanged, then just removing the pdfs should be enough. > > > > > > This was because of adjustments to license info in the .make files so I > > guess I need to remove the .report files :-) > > > > Thank you for the response, > > If you change a .make file, then that should be detected automatically and > the license info for that package should be regenerated automatically. > It should not be necessary to do anything manually. > Yes; the problem is that I was not actually changing the .make files. Instead I have a rules/post/licenses.make file where I override some of the xxx_LICENSE variables. I was looking for a way to regenerate the report when this file was updated. Anyway I think all is clear now with your explanations. Thanks again! Best, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: [ptxdist] Regenerate license report
El miércoles, 19 de abril de 2023, Michael Olbrich escribió: > Hi, > > On Tue, Apr 18, 2023 at 05:18:58PM +0200, Guillermo Rodriguez Garcia wrote: > > El mar, 18 abr 2023 a las 16:37, Guillermo Rodriguez Garcia (< > > guille.rodrig...@gmail.com>) escribió: > > > Is there a way to force ptxdist to regenerate a license-report after it > > > has been generated already with "ptxdist make license-report" ? > > > > > > I didn't find any "clean" rule for this, and the naive approach of just > > > deleting the platform-xxx/report dir doesn't work (trying to run > ptxdist > > > make license-report after this results in errors). > > > > > > > The best I have found is: > > > > rm -rf platform-xxx/report > > rm platform-xxx/state/*.report > > > > But I assume there is a cleaner way :-) > > That depends a bit on why you want to regenerate the report. If you need to > regenerate the per package stuff in platform-xxx/report/ then removing > platform-xxx/state/*.report is the way to go. If that part remains > unchanged, then just removing the pdfs should be enough. This was because of adjustments to license info in the .make files so I guess I need to remove the .report files :-) Thank you for the response, Guillermo -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: [ptxdist] Regenerate license report
El mar, 18 abr 2023 a las 16:37, Guillermo Rodriguez Garcia (< guille.rodrig...@gmail.com>) escribió: > Hi all, > > Is there a way to force ptxdist to regenerate a license-report after it > has been generated already with "ptxdist make license-report" ? > > I didn't find any "clean" rule for this, and the naive approach of just > deleting the platform-xxx/report dir doesn't work (trying to run ptxdist > make license-report after this results in errors). > The best I have found is: rm -rf platform-xxx/report rm platform-xxx/state/*.report But I assume there is a cleaner way :-) BR, Guillermo
[ptxdist] ptx/image-install for older ptxdist releases
Hi all, I have an "image" package that generates more than one image file. In the past I asked what would be the best way to handle this so that the clean target works correctly. Michael suggested to use ptx/image-install: > You should be able to use ptx/image-install in the image rule. Just like > regular packages. File installed with this are recorded and later removed > in the clean stage. I have found that ptx/image-install indeed solves the problem when available; however this was added relatively recently and does not exist for older ptxdist releases. Is there a way to achieve similar functionality in ptxdist releases where ptx/image-install is not available ? Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
[ptxdist] Regenerate license report
Hi all, Is there a way to force ptxdist to regenerate a license-report after it has been generated already with "ptxdist make license-report" ? I didn't find any "clean" rule for this, and the naive approach of just deleting the platform-xxx/report dir doesn't work (trying to run ptxdist make license-report after this results in errors). Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: [ptxdist] Image package creating several files
Hi Christian, El mié, 8 mar 2023 a las 18:49, Christian Melki () escribió: > > Hi. > > On 3/8/23 16:56, Guillermo Rodriguez Garcia wrote: > > Hello all, > > > > I have created an image package that signs some files. > > This package creates two separate files. > > > > What is the recommended way to handle this? From the documentation > > (https://www.ptxdist.org/doc/ref_make_variables.html#image-packages), > > I believe that _IMAGE is expected to contain the filename of one > > single file. For example the "clean" target uses this to know which > > file to delete. > > > > How can this be adapted for cases where more than one file is generated? > > > > Not sure what you mean by _IMAGE. But iirc, > barebox (etc) image installing packages handle this. > The rules can install multiple files into image directories and are > capable of cleaning up after themselves. Yes but that is a "regular" package. I am referring to "image packages", which are a bit different; see the documentation here: https://www.ptxdist.org/doc/ref_make_variables.html#image-packages In these packages, the _IMAGE variable points to a file (the image that is created by the rule). The clean target is automatically generated based on this variable. My question is how to do this if the package generates more than one image. BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
[ptxdist] Image package creating several files
Hello all, I have created an image package that signs some files. This package creates two separate files. What is the recommended way to handle this? From the documentation (https://www.ptxdist.org/doc/ref_make_variables.html#image-packages), I believe that _IMAGE is expected to contain the filename of one single file. For example the "clean" target uses this to know which file to delete. How can this be adapted for cases where more than one file is generated? Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: [ptxdist] TF-A FIP format and U-Boot
Hi, El vie, 1 oct 2021 a las 14:27, Roland Hieber () escribió: > On Thu, Sep 30, 2021 at 02:10:15PM +0200, Guillermo Rodriguez Garcia wrote: > > > So for such a use-case, the files must be installed in the install > stage. > > > Note, that you cannot install the files into platform/images: > > > 'ptxdist clean root' will remove that but only cleans the targetinstall > > > stages, so afterwards the files will be missing. > > > > > > So I suggest the files are installed to > > > $(_PKGDIR)/usr/lib// > > > The install stage will then copy the files to sysroot-target and the > next > > > package can find the files there. > > > > > > > Uhm, the files themselves are not needed in the target fs; they are only > > required as intermediate files to build the FIP image. > > Should I still copy them to sysroot-target? > > Yes. sysroot-target is not the contents of the image yet, but only the > staging area where target packages install their files. This is done > because in the install stage PTXdist uses the package's build system to > install files, which sometimes installs many more files that you maybe > don't want in your target. In the targetinstall stage you have to pick > them from sysroot-target into the image explicitly with the > $(call install_*) macros. > I see. Thank you for the clarification! Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] TF-A FIP format and U-Boot
Hi Michael,
El jue, 30 sept 2021 a las 12:55, Michael Olbrich ()
escribió:
> Hi,
>
> On Wed, Sep 29, 2021 at 05:57:54PM +0200, Guillermo Rodriguez Garcia wrote:
> > TF-A recently introduced the FIP ("Firmware Image Package") which is a
> > format for embedding other bootloader images as payloads in a single
> > archive, which is then read and processed by TF-A.
> >
> > In platforms such as the stm32mp1 where TF-A is used in conjunction with
> > U-Boot, U-Boot is now embedded in the FIP image as part of the TF-A
> package
> > build.
> >
> > To achieve this we added a dependency in the TF-A rule files:
> >
> > select U_BOOT if TF_A_FIP
> >
> > The goal is to be able to build the fip command with a command similar to
> > this one:
> >
> > make ARM_ARCH_MAJOR=7 ARCH=aarch32 PLAT=stm32mp1 \
> > BL33=/u-boot-nodtb.bin \
> > BL33_CFG=/u-boot.dtb \
> > BL32=/bl32.bin \
> > FW_CONFIG=/fw-config.dtb \
> > DTB_FILE_NAME=.dtb \
> > fip
> >
> > The problem is that the dependency set in the tf-a.in file only ensures
> > that the install target of u-boot will run before the install target of
> > tf-a, but at that time the images have not yet been copied to their final
> > destination (platform/images..). Which is the proper way to work around
> > this?
>
> So, the way dependencies work in ptxdist, installing files in the
> targetinstall stage in one package and then using it in a build stage in
> another regular package (image packages are different here) is not
> possible.
> This issue has come up before and I've looked for a good solution but
> changing the dependencies is unfortunately not possible.
>
I understand.
>
> So for such a use-case, the files must be installed in the install stage.
> Note, that you cannot install the files into platform/images:
> 'ptxdist clean root' will remove that but only cleans the targetinstall
> stages, so afterwards the files will be missing.
>
> So I suggest the files are installed to
> $(_PKGDIR)/usr/lib//
> The install stage will then copy the files to sysroot-target and the next
> package can find the files there.
>
Uhm, the files themselves are not needed in the target fs; they are only
required as intermediate files to build the FIP image.
Should I still copy them to sysroot-target?
Thanks,
Guillermo
___
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to
ptxdist-requ...@pengutronix.de
[ptxdist] TF-A FIP format and U-Boot
Hi all,
TF-A recently introduced the FIP ("Firmware Image Package") which is a
format for embedding other bootloader images as payloads in a single
archive, which is then read and processed by TF-A.
In platforms such as the stm32mp1 where TF-A is used in conjunction with
U-Boot, U-Boot is now embedded in the FIP image as part of the TF-A package
build.
To achieve this we added a dependency in the TF-A rule files:
select U_BOOT if TF_A_FIP
The goal is to be able to build the fip command with a command similar to
this one:
make ARM_ARCH_MAJOR=7 ARCH=aarch32 PLAT=stm32mp1 \
BL33=/u-boot-nodtb.bin \
BL33_CFG=/u-boot.dtb \
BL32=/bl32.bin \
FW_CONFIG=/fw-config.dtb \
DTB_FILE_NAME=.dtb \
fip
The problem is that the dependency set in the tf-a.in file only ensures
that the install target of u-boot will run before the install target of
tf-a, but at that time the images have not yet been copied to their final
destination (platform/images..). Which is the proper way to work around
this?
Thanks,
--
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to
ptxdist-requ...@pengutronix.de
Re: [ptxdist] [PATCH 0/2] Add u-boot template
Hi Alexandar, El jue, 26 ago 2021 a las 14:25, Alexander Dahl () escribió: > Hello Guillermo, > > Am Thu, Aug 26, 2021 at 01:43:25PM +0200 schrieb Guillermo Rodriguez > Garcia: > > Hi Alexander, > > > > El jueves, 26 de agosto de 2021, Alexander Dahl > escribió: > > > > > Hei hei, > > > > > > I crafted this in the last weeks for a DistroKit based generic BSP, > > > which uses U-Boot for half a dozen boards. Maybe someone else finds it > > > useful? > > > > > > What does this do exactly, and how does it work? > > This adds a new package type 'u-boot' to the `ptxdist newpackage` > command. That newpackage command uses templates to create the > necessary rule files for a new package. You can write your own > templates and add it to your BSP, too. > > So why a package type 'u-boot' if there's already an u-boot package? > I had the idea when working with DistroKit [1] as a base layer for > another generic BSP. You can build a BSP with a rootfs common to > different SoCs of the armv7 family and use a common kernel as well. > However bootloaders for different SoC families differ, so for such a > generic BSP you need to build different bootloaders, and what you do > then is duplicate those bootloaders packages in ptxdist with slighty > changed names/variables making them unique. DistroKit for example has > multiple barebox packages. > > Creating such packages by copy and paste and search and replace is > cumbersome and error prone, so I thought why not doing the same thing > pengutronix did with barebox for u-boot as well?! > This looks great. I am sure I have a use for this in my BSPs. Is it possible to add these templates to my BSP without modifying ptxdist itself? Where should the files be installed? Thanks, Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] [PATCH 0/2] Add u-boot template
Hi Alexander, El jueves, 26 de agosto de 2021, Alexander Dahl escribió: > Hei hei, > > I crafted this in the last weeks for a DistroKit based generic BSP, > which uses U-Boot for half a dozen boards. Maybe someone else finds it > useful? What does this do exactly, and how does it work? Thank you, Guillermo > > I also have another template for at91bootstrap3, but maybe that's a > little to special? > Greets > Alex > > Alexander Dahl (2): > u-boot: Introduce make macro for URL > templates: Introduce new u-boot template > > rules/pre/u-boot.make| 15 ++ > rules/templates/template-u-boot-in | 221 + > rules/templates/template-u-boot-make | 233 +++ > rules/u-boot.make| 2 +- > scripts/lib/ptxd_lib_template.sh | 10 ++ > 5 files changed, 480 insertions(+), 1 deletion(-) > create mode 100644 rules/pre/u-boot.make > create mode 100644 rules/templates/template-u-boot-in > create mode 100644 rules/templates/template-u-boot-make > > > base-commit: 76d1f680233955839298435e9faf11f15434b4a4 > -- > 2.30.2 > > > ___ > ptxdist mailing list > ptxdist@pengutronix.de > To unsubscribe, send a mail with subject "unsubscribe" to > ptxdist-requ...@pengutronix.de > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] [PATCH] rust: new package
Hi Michael, El vie, 6 ago 2021 a las 8:25, Michael Olbrich () escribió: > On Thu, Aug 05, 2021 at 07:36:36PM +0200, Guillermo Rodriguez Garcia wrote: > > El mié, 4 ago 2021 a las 9:41, Michael Olbrich (< > m.olbr...@pengutronix.de>) > > escribió: > > > > > On Fri, Jul 30, 2021 at 07:41:56PM +0200, avazquez@gmail.com > wrote: > > > > From: Alejandro Vazquez > > > > > > > > - host-rust: This package provides a pre-built version of rustc, > > > > cargo and standard library for the host. > > > > - host-rust-std-target: A pre-built version of the standard library > for > > > > the target. > > > > > > No. The compiler should be built not just downloaded. > > > > > > Please take a look at the latest OSELAS.Toolchain. It contains a rust > > > compiler and std libraries for the target. I've done very little > testing > > > with that so far and I would be interested in some feedback. > Especially if > > > something isn't working. > > > > > > Also, I'm pretty sure that there are some hidden downloads in there for > > > cargo and maybe the host std library. So if you keep those rules > locally, > > > you should add that to the downloads. This way, they will be cached > with > > > the rest of the source. Take a look at what I did for the toolchain. > > > > > > > Just for the record, looks like there are no hidden downloads. > > The package that is donwloaded includes rustc, cargo, and the selected > > host-std lib. > > Thanks for the feedback. That's good to know. So there seem to be different > binary packages available. When building rustc from sources then for > bootstrapping rustc, cargo and the std lib are downloaded separately. > I am trying to build the rust-enabled toolchain from sources and I am having some trouble with the cross-rustc package. It seems that there are hidden downloads when using the toolchain rules. Specifically when you are building rustc 1.54, all sources for 1.54 are downloaded explicitly (so this is OK), but then in the compile stage it tries to download 1.53 automatically (this actually failed in my test, which is how I noticed). See this: === --- target: cross-rustc.compile --- downloading https://static.rust-lang.org/dist/2021-06-17/rust-std-1.53.0-x86_64-unknown-linux-gnu.tar.xz.sha256 running: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmpherqj8wk.sha256 https://static.rust-lang.org/dist/2021-06-17/rust-std-1.53.0-x86_64-unknown-linux-gnu.tar.xz.sha256 curl: (5) Could not resolve proxy: - Warning: Transient problem: timeout Will retry in 1 seconds. 3 retries left. #=#=- # curl: (5) Could not resolve proxy: - Warning: Transient problem: timeout Will retry in 2 seconds. 2 retries left. ##O=# # curl: (5) Could not resolve proxy: - Warning: Transient problem: timeout Will retry in 4 seconds. 1 retries left. #=#=-# # curl: (5) Could not resolve proxy: - === I guess this is not what is wanted? Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] [PATCH] rust: new package
Hi Michael, El mié, 4 ago 2021 a las 9:41, Michael Olbrich () escribió: > On Fri, Jul 30, 2021 at 07:41:56PM +0200, avazquez@gmail.com wrote: > > From: Alejandro Vazquez > > > > - host-rust: This package provides a pre-built version of rustc, > > cargo and standard library for the host. > > - host-rust-std-target: A pre-built version of the standard library for > > the target. > > No. The compiler should be built not just downloaded. > > Please take a look at the latest OSELAS.Toolchain. It contains a rust > compiler and std libraries for the target. I've done very little testing > with that so far and I would be interested in some feedback. Especially if > something isn't working. > > Also, I'm pretty sure that there are some hidden downloads in there for > cargo and maybe the host std library. So if you keep those rules locally, > you should add that to the downloads. This way, they will be cached with > the rest of the source. Take a look at what I did for the toolchain. > Just for the record, looks like there are no hidden downloads. The package that is donwloaded includes rustc, cargo, and the selected host-std lib. BR, Guillermo Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] [PATCH] rust: new package
El mié, 4 ago 2021 a las 12:16, Michael Olbrich () escribió: > On Wed, Aug 04, 2021 at 11:52:49AM +0200, Guillermo Rodriguez Garcia wrote: > > El mié, 4 ago 2021 a las 9:41, Michael Olbrich (< > m.olbr...@pengutronix.de>) > > escribió: > > > > > On Fri, Jul 30, 2021 at 07:41:56PM +0200, avazquez@gmail.com > wrote: > > > > From: Alejandro Vazquez > > > > > > > > - host-rust: This package provides a pre-built version of rustc, > > > > cargo and standard library for the host. > > > > - host-rust-std-target: A pre-built version of the standard library > for > > > > the target. > > > > > > No. The compiler should be built not just downloaded. > > > > > > Please take a look at the latest OSELAS.Toolchain. It contains a rust > > > compiler and std libraries for the target. I've done very little > testing > > > with that so far and I would be interested in some feedback. > Especially if > > > something isn't working. > > > > > > > I think it would be useful to have rules that support building rust > > packages without the need to update the toolchain. > > Why would you not want to update the toolchain? > For existing BSPs that are already used in production we might want to add a new package or update an existing package but keep everything else the same. If the toolchain is updated, every package will/may change. > > > > Also, I'm pretty sure that there are some hidden downloads in there for > > > cargo and maybe the host std library. So if you keep those rules > locally, > > > you should add that to the downloads. > > > > > > Is it possible to specify more than one download in a single .make file? > > Yes, that's what I do in the rustc package[1] in the toolchain. Or take a > look at rules/shaderc.make in PTXdist itself if you need to extract all > archives. > Very interesting! I didn't know this was possible. Thx, Guillermo > > Michael > > [1] > https://git.pengutronix.de/cgit/OSELAS.Toolchain/tree/rules/cross-rustc.make > > > > This way, they will be cached with > > > the rest of the source. Take a look at what I did for the toolchain. > > > > > > Michael > > > > > > > Signed-off-by: Alejandro Vazquez > > > > --- > > > > rules/host-rust-std-target.in | 18 > > > > rules/host-rust-std-target.make | 81 > + > > > > rules/host-rust.in | 8 > > > > rules/host-rust.make| 80 > > > > > 4 files changed, 187 insertions(+) > > > > create mode 100644 rules/host-rust-std-target.in > > > > create mode 100644 rules/host-rust-std-target.make > > > > create mode 100644 rules/host-rust.in > > > > create mode 100644 rules/host-rust.make > > > > > > > > diff --git a/rules/host-rust-std-target.in b/rules/ > > > host-rust-std-target.in > > > > new file mode 100644 > > > > index 0..ed47f8c89 > > > > --- /dev/null > > > > +++ b/rules/host-rust-std-target.in > > > > @@ -0,0 +1,18 @@ > > > > +## SECTION=hosttools > > > > + > > > > +menuconfig HOST_RUST_STD_TARGET > > > > + bool > > > > + select HOST_RUST > > > > + prompt "host-rust-std-target (pre-built)" > > > > + help > > > > + This package will install pre-built versions of > > > > + the Rust standard library for the target. > > > > + > > > > +if HOST_RUST_STD_TARGET > > > > + > > > > +config HOST_RUST_STD_TARGET_ARCH > > > > + string > > > > + default "armv7-unknown-linux-gnueabihf" > > > > + prompt "Target Architecture" > > > > + > > > > +endif > > > > diff --git a/rules/host-rust-std-target.make > > > b/rules/host-rust-std-target.make > > > > new file mode 100644 > > > > index 0..f41c2caa1 > > > > --- /dev/null > > > > +++ b/rules/host-rust-std-target.make > > > > @@ -0,0 +1,81 @@ > > > > +# -*-makefile-*- > > > > +# > > > > +# Copyright (C) 2021 by Alejandro Vazquez > > > > +# > > > > +# For further information about the PTXdist project and license > > > conditions > > > > +# see the README file. > > > >
Re: [ptxdist] [PATCH] rust: new package
--- > > +# Compile > > +# > > > + > > +$(STATEDIR)/host-rust.compile: > > + @$(call targetinfo) > > + @$(call touch) > > + > > +# > > > +# Install > > +# > > > + > > +$(STATEDIR)/host-rust.install.post: > > + @$(call targetinfo) > > + > > + @cd "$(HOST_RUST_DIR)" && sh install.sh $(HOST_RUST_INSTALL_OPTS) > > + @cd "$(PTXDIST_SYSROOT_HOST)/lib/rustlib/" && mv uninstall.sh > uninstall-host.sh > > + > > + @$(call touch) > > + > > +# > > > +# Clean > > +# > > > + > > +$(STATEDIR)/host-rust.clean: > > + @$(call targetinfo) > > + > > + sh $(PTXDIST_SYSROOT_HOST)/lib/rustlib/uninstall-host.sh \ > > + --uninstall \ > > + --prefix=$(PTXDIST_SYSROOT_HOST) \ > > + $(HOST_RUST_INSTALL_COMPONENTS) > > + > > + @$(call clean_pkg, HOST_RUST) > > + > > +# vim: syntax=make > > -- > > 2.25.1 > > > > > > ___ > > ptxdist mailing list > > ptxdist@pengutronix.de > > To unsubscribe, send a mail with subject "unsubscribe" to > ptxdist-requ...@pengutronix.de > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > > ___ > ptxdist mailing list > ptxdist@pengutronix.de > To unsubscribe, send a mail with subject "unsubscribe" to > ptxdist-requ...@pengutronix.de > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] Host and target triplets
Hi, El jueves, 22 de julio de 2021, Michael Olbrich escribió: > On Thu, Jul 22, 2021 at 12:29:49PM +0200, Guillermo Rodriguez Garcia wrote: > > El mié, 21 jul 2021 a las 18:35, Guillermo Rodriguez Garcia (< > > guille.rodrig...@gmail.com>) escribió: > > > El mié, 21 jul 2021 a las 17:15, Michael Olbrich (< > > > m.olbr...@pengutronix.de>) escribió: > > >> On Wed, Jul 21, 2021 at 04:07:34PM +0200, Guillermo Rodriguez Garcia > > >> wrote: > > >> > Are there any variables in ptxdist holding the host and target > triplets, > > >> > such as: > > >> > > > >> > Host: x86_64-unknown-linux-gnu > > >> > Target: amrv7-unknown-linux-gnueabihf > > >> > > >> I assume, you mean variables that can be used in the package rules. > > >> There are multiple variables available. In your example that would be: > > >> > > >> PTXCONF_GNU_TARGET = amrv7-unknown-linux-gnueabihf > > >> PTXCONF_COMPILER_PREFIX = amrv7-unknown-linux-gnueabihf- > > >> > > > > > Something does not seem to work as expected, value of PTXCONF_GNU_TARGET > is > > arm-v7a-linux-gnueabihf whereas I need armv7-unknown-linux-gnueabihf. Is > > there a standard way to translate between the two? > > Right, so you don't need the GNU tripple from the toolchain. So the > question is, what exactly is armv7-unknown-linux-gnueabihf? What do you > need it for? It is a Rust target spec. I need this in order to download the right rust-std for the target. Guillermo > > Michael > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] Host and target triplets
Hi Michael, El mié, 21 jul 2021 a las 18:35, Guillermo Rodriguez Garcia (< guille.rodrig...@gmail.com>) escribió: > > El mié, 21 jul 2021 a las 17:15, Michael Olbrich (< > m.olbr...@pengutronix.de>) escribió: > >> Hi, >> >> On Wed, Jul 21, 2021 at 04:07:34PM +0200, Guillermo Rodriguez Garcia >> wrote: >> > Are there any variables in ptxdist holding the host and target triplets, >> > such as: >> > >> > Host: x86_64-unknown-linux-gnu >> > Target: amrv7-unknown-linux-gnueabihf >> >> I assume, you mean variables that can be used in the package rules. >> There are multiple variables available. In your example that would be: >> >> PTXCONF_GNU_TARGET = amrv7-unknown-linux-gnueabihf >> PTXCONF_COMPILER_PREFIX = amrv7-unknown-linux-gnueabihf- >> > Something does not seem to work as expected, value of PTXCONF_GNU_TARGET is arm-v7a-linux-gnueabihf whereas I need armv7-unknown-linux-gnueabihf. Is there a standard way to translate between the two? Guillermo >> GNU_HOST = x86_64-host-linux-gnu > > >> Note that GNU_HOST has '-host-' instead of '-unknown-'. This is ab git of >> a >> hack to support x86_64-unknown-linux-gnu for the target: If host and >> target >> are the same then the packages won't be cross-compiled. >> > > Thank you Michael, this is exactly what I needed. > > Best, > > Guillermo Rodriguez Garcia > guille.rodrig...@gmail.com > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] Host and target triplets
El mié, 21 jul 2021 a las 17:15, Michael Olbrich () escribió: > Hi, > > On Wed, Jul 21, 2021 at 04:07:34PM +0200, Guillermo Rodriguez Garcia wrote: > > Are there any variables in ptxdist holding the host and target triplets, > > such as: > > > > Host: x86_64-unknown-linux-gnu > > Target: amrv7-unknown-linux-gnueabihf > > I assume, you mean variables that can be used in the package rules. > There are multiple variables available. In your example that would be: > > PTXCONF_GNU_TARGET = amrv7-unknown-linux-gnueabihf > PTXCONF_COMPILER_PREFIX = amrv7-unknown-linux-gnueabihf- > > GNU_HOST = x86_64-host-linux-gnu > > Note that GNU_HOST has '-host-' instead of '-unknown-'. This is ab git of a > hack to support x86_64-unknown-linux-gnu for the target: If host and target > are the same then the packages won't be cross-compiled. > Thank you Michael, this is exactly what I needed. Best, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
[ptxdist] Host and target triplets
Hello, Are there any variables in ptxdist holding the host and target triplets, such as: Host: x86_64-unknown-linux-gnu Target: amrv7-unknown-linux-gnueabihf Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] Kernel GCC plugins
Hello,
El mar, 20 jul 2021 a las 14:02, Michael Olbrich ()
escribió:
> Hi,
>
> On Mon, Jul 19, 2021 at 01:45:44PM +0200, Guillermo Rodriguez Garcia wrote:
> > El vie, 16 jul 2021 a las 15:04, Michael Olbrich (<
> m.olbr...@pengutronix.de>)
> > escribió:
> > > On Fri, Jul 16, 2021 at 02:45:40PM +0200, Guillermo Rodriguez Garcia
> wrote:
> > > > El viernes, 16 de julio de 2021, Alexander Dahl
> > > escribió:
> > > > > On Fri, Jul 16, 2021 at 01:32:29PM +0200, Guillermo Rodriguez
> Garcia
> > > wrote:
> > > > > > I notice that the kernelconfig files changes depending on the
> host
> > > gcc
> > > > > > version; in particular depending on supported gcc plugins.
> > > > > >
> > > > > > However this does not seem to make much sense -- the kernel will
> not
> > > be
> > > > > > built using the host gcc; it will be built using the cross
> compiler
> > > from
> > > > > > the toolchain.
> > > > > >
> > > > > > Is it possible to avoid this?
> > > > >
> > > > > IIRC this was addressed several times in recent ptxdist versions:
> > > > >
> > > > > - ptxdist-2021.04.0-14-g533f7709f ("kernel/kernel-template: set
> > > > > PTXDIST_NO_GCC_PLUGINS=1 in _MAKE_ENV as well")
> > > > > - ptxdist-2021.03.0-69-g7a90f622f ("template: kernel: fix
> disabling gcc
> > > > > plugins for >= v5.11")
> > > > > - ptxdist-2021.03.0-33-g114fecbd4 ("kernel: really fix disabling
> gcc
> > > > > plugins for >= v5.11)
> > > > > - ptxdist-2021.02.0-41-gd57abb428 ("kernel: fix disabling gcc
> plugins
> > > for
> > > > > >= v5.11")
> > > > >
> > > > > … and maybe more?
> > > > >
> > > > > Or is yours another problem?
> > > >
> > > >
> > > > Do I need to do something special for this to work?
> > > >
> > > > I’m on ptxdist 2021.07.0 so the above fixes should be merged, yet I
> am
> > > > still having the problem ..
> > >
> > > Is PTXCONF_KERNEL_GCC_PLUGINS disabled?
> >
> > Yes.
>
> Ok.
>
> > > And which kernel version?
> >
> >
> > 5.4.56
> >
> > I am rechecking, perhaps I did something wrong in the process.
>
> Or maybe that version has a different check. Looking hat the history, I
> definitely checked v4.19 and v5.6. I'm not sure about the versions in
> between. Take a look at what scripts/gcc-plugins/Kconfig is doing.
>
I can confirm that this was a mistake on my side.
Sorry for the noise.
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to
ptxdist-requ...@pengutronix.de
Re: [ptxdist] Kernel GCC plugins
Hello,
El vie, 16 jul 2021 a las 15:04, Michael Olbrich ()
escribió:
> On Fri, Jul 16, 2021 at 02:45:40PM +0200, Guillermo Rodriguez Garcia wrote:
> > El viernes, 16 de julio de 2021, Alexander Dahl
> escribió:
> > > On Fri, Jul 16, 2021 at 01:32:29PM +0200, Guillermo Rodriguez Garcia
> wrote:
> > > > I notice that the kernelconfig files changes depending on the host
> gcc
> > > > version; in particular depending on supported gcc plugins.
> > > >
> > > > However this does not seem to make much sense -- the kernel will not
> be
> > > > built using the host gcc; it will be built using the cross compiler
> from
> > > > the toolchain.
> > > >
> > > > Is it possible to avoid this?
> > >
> > > IIRC this was addressed several times in recent ptxdist versions:
> > >
> > > - ptxdist-2021.04.0-14-g533f7709f ("kernel/kernel-template: set
> > > PTXDIST_NO_GCC_PLUGINS=1 in _MAKE_ENV as well")
> > > - ptxdist-2021.03.0-69-g7a90f622f ("template: kernel: fix disabling gcc
> > > plugins for >= v5.11")
> > > - ptxdist-2021.03.0-33-g114fecbd4 ("kernel: really fix disabling gcc
> > > plugins for >= v5.11)
> > > - ptxdist-2021.02.0-41-gd57abb428 ("kernel: fix disabling gcc plugins
> for
> > > >= v5.11")
> > >
> > > … and maybe more?
> > >
> > > Or is yours another problem?
> >
> >
> > Do I need to do something special for this to work?
> >
> > I’m on ptxdist 2021.07.0 so the above fixes should be merged, yet I am
> > still having the problem ..
>
> Is PTXCONF_KERNEL_GCC_PLUGINS disabled?
Yes.
> And which kernel version?
5.4.56
I am rechecking, perhaps I did something wrong in the process.
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to
ptxdist-requ...@pengutronix.de
Re: [ptxdist] Kernel GCC plugins
Hello,
El viernes, 16 de julio de 2021, Alexander Dahl escribió:
> Hei hei,
>
> On Fri, Jul 16, 2021 at 01:32:29PM +0200, Guillermo Rodriguez Garcia wrote:
> > I notice that the kernelconfig files changes depending on the host gcc
> > version; in particular depending on supported gcc plugins.
> >
> > However this does not seem to make much sense -- the kernel will not be
> > built using the host gcc; it will be built using the cross compiler from
> > the toolchain.
> >
> > Is it possible to avoid this?
>
> IIRC this was addressed several times in recent ptxdist versions:
>
> - ptxdist-2021.04.0-14-g533f7709f ("kernel/kernel-template: set
> PTXDIST_NO_GCC_PLUGINS=1 in _MAKE_ENV as well")
> - ptxdist-2021.03.0-69-g7a90f622f ("template: kernel: fix disabling gcc
> plugins for >= v5.11")
> - ptxdist-2021.03.0-33-g114fecbd4 ("kernel: really fix disabling gcc
> plugins for >= v5.11)
> - ptxdist-2021.02.0-41-gd57abb428 ("kernel: fix disabling gcc plugins for
> >= v5.11")
>
> … and maybe more?
>
> Or is yours another problem?
Do I need to do something special for this to work?
I’m on ptxdist 2021.07.0 so the above fixes should be merged, yet I am
still having the problem ..
Guillermo
--
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to
ptxdist-requ...@pengutronix.de
[ptxdist] Kernel GCC plugins
Hi all, I notice that the kernelconfig files changes depending on the host gcc version; in particular depending on supported gcc plugins. However this does not seem to make much sense -- the kernel will not be built using the host gcc; it will be built using the cross compiler from the toolchain. Is it possible to avoid this? BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] Regenerating debug files for debugging a core dump
Hi Michael, El mié, 26 may 2021 a las 11:32, Michael Olbrich () escribió: > Hi, > > On Tue, May 25, 2021 at 04:43:54PM +0200, Guillermo Rodriguez Garcia wrote: > > I am trying to debug a core dump from a system based on > ptxdist-2018.05.0. > > > > I see that the debug symbols are generated in > > platform-xxx/root/usr/lib/debug. > > > > The thing is that I don't have the original debug files anymore. > > If I regenerate the root fs and everything else from the same sources > > (ptxdist clean + ptxdist go), will the generated debug files be valid for > > debugging the core dump? > > It may or may not work. PTXdist tries to make builds reproducible. But > there are cases where it does not work and the resulting binaries are > different. > So it's worth a try if you don't have the debug files any more, but it's > better to keep them to avoid relying on this. > > > I guess the general question is: should we be storing debug files for > each > > release, or can we rely on regenerating these from scratch when needed? > > I would not rely on it. I would either just package the whole > platform-xxx/root and save that. Or you could enable > PTXCONF_DEBUG_PACKAGES. In this case PTXdist will create a debug ipkg for > each package that contains the debug files. You can den archive all ipgk > files (regular and debug) and extract those as needed. > All clear. Thank you for the quick and useful answer. Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
[ptxdist] Regenerating debug files for debugging a core dump
Hi all, I am trying to debug a core dump from a system based on ptxdist-2018.05.0. I see that the debug symbols are generated in platform-xxx/root/usr/lib/debug. The thing is that I don't have the original debug files anymore. If I regenerate the root fs and everything else from the same sources (ptxdist clean + ptxdist go), will the generated debug files be valid for debugging the core dump? I guess the general question is: should we be storing debug files for each release, or can we rely on regenerating these from scratch when needed? Thank you, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] Generate UBIFS Images
Hi Alex, El lun, 25 ene 2021 a las 6:56, Sascha Hauer () escribió: > > Hi Alex, > > On Sun, Jan 24, 2021 at 07:29:05PM +0100, Alex Vazquez wrote: > > El jue, 21 ene 2021 a las 7:54, Alexander Dahl () > > escribió: > > > > > > Hello Alex, > > > > > > On Wed, Jan 20, 2021 at 11:56:55PM +0100, Alex Vazquez wrote: > > > > I have some questions about generating UBIFS images. > > > > First, I am using ptxdist-2018.05. For this version, I use Generate > > > > UBIFS Images (NO new version). > > > > > > I would recommend to use the new approach, that should also work with > > > ptxdist-2018.05 already. > > > > > > > Thanks, Alex! > > Following your recommendation I will use the new approach. > > I'm testing and it works. > > > > I have a question. In genimage, max_leb_cnt is calculated > > automatically and there isn't an option in the flash section to set a > > value. Is there any alternative to set it to a specific value? > > There is the max-size property for > ubifs, see > https://github.com/pengutronix/genimage/blob/master/README.rst#ubifs Not sure why genimage does not support specifying max_leb_cnt directly, but I guess you can pass it to mkfs.ubifs via extraargs (-c xxx) Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] [PATCH v2] ptxd_make_fit_image: Add support for kernel load/entry addresses
Hi Michael,
El vie., 13 nov. 2020 a las 9:46, Michael Olbrich
() escribió:
>
> On Wed, Nov 11, 2020 at 04:23:39PM +0100, avazquez@gmail.com wrote:
> > From: AVazquez
> >
> > Make it possible to specify load/entry addresses for the kernel.
> > These are required by the FIT image specification, but in some cases
> > users may not want to include them, so they are made optional.
> >
> > Also add mandatory "os" property for kernel and ramdisk.
> >
> > Signed-off-by: AVazquez
> > ---
> > Changes since v1:
> > - load/entry addresses made optional
> >
> > platforms/kernel-fit.in| 8
> > scripts/lib/ptxd_make_fit_image.sh | 14 ++
> > 2 files changed, 22 insertions(+)
> >
> > diff --git a/platforms/kernel-fit.in b/platforms/kernel-fit.in
> > index 8cbc1a8..b5f9da6 100644
> > --- a/platforms/kernel-fit.in
> > +++ b/platforms/kernel-fit.in
> > @@ -17,6 +17,14 @@ menuconfig KERNEL_FIT
> >
> > if KERNEL_FIT
> >
> > +config KERNEL_FIT_LOAD
> > + string
> > + prompt "Kernel load address (optional)"
>
> I'd like some help text here to clarify when this is needed. From what I
> understand from the discussion, u-boots requires this, right?
> But barebox does not? Never, or does it depend on the kernel image type?
According to the FIT image specification, the "load" and "entry"
properties are mandatory for the "kernel" node. See:
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/uImage.FIT/source_file_format.txt#L181
So for a valid FIT image these properties should always be present.
However according to Sascha, Barebox does not enforce this (and
actually ignores the properties even if they are present?).
U-boot certainly requires them.
Guillermo
>
> Sascha, can you help here?
>
> > +
> > +config KERNEL_FIT_ENTRY
> > + string
> > + prompt "Kernel entry address (optional)"
>
> The same here.
>
> > +
> > config KERNEL_FIT_SIGNED
> > bool
> > prompt "sign FIT image"
> > diff --git a/scripts/lib/ptxd_make_fit_image.sh
> > b/scripts/lib/ptxd_make_fit_image.sh
> > index 9754d1e..1edf5c5 100644
> > --- a/scripts/lib/ptxd_make_fit_image.sh
> > +++ b/scripts/lib/ptxd_make_fit_image.sh
> > @@ -21,7 +21,20 @@ ptxd_make_image_fit_its() {
> > data = /incbin/("${image_kernel}");
> > type = "kernel";
> > arch = "$(ptxd_get_ptxconf PTXCONF_ARCH_STRING)";
> > + os = "linux";
>
> Sascha, setting this is ok for barebox, right?
>
> > compression = "none";
> > +EOF
> > + if [ -n "$(ptxd_get_ptxconf PTXCONF_KERNEL_FIT_LOAD)"
> > ]; then
> > + cat << EOF
>
> The code should be indented to align with the code above.
>
> if [ ... ]; then
> cat << EOF
>
> I think.
>
> > + load = <$(ptxd_get_ptxconf PTXCONF_KERNEL_FIT_LOAD)>;
> > +EOF
> > + fi
> > + if [ -n "$(ptxd_get_ptxconf
> > PTXCONF_KERNEL_FIT_ENTRY)" ]; then
> > + cat << EOF
>
> same here.
>
> Michael
>
> > + entry = <$(ptxd_get_ptxconf
> > PTXCONF_KERNEL_FIT_ENTRY)>;
> > +EOF
> > + fi
> > + cat << EOF
> > hash-1 {
> > algo = "sha256";
> > };
> > @@ -33,6 +46,7 @@ EOF
> > description = "initramfs";
> > data = /incbin/("${image_initramfs}");
> > type = "ramdisk";
> > + os = "linux";
> > compression = "none";
> > hash-1 {
> > algo = "sha256";
> > --
> > 1.9.1
> >
> >
> > ___
> > ptxdist mailing list
> > ptxdist@pengutronix.de
> > To unsubscribe, send a mail with subject "unsubscribe" to
> > ptxdist-requ...@pengutronix.de
> >
>
> ___
> ptxdist mailing list
> ptxdist@pengutronix.de
> To unsubscribe, send a mail with subject "unsubscribe" to
> ptxdist-requ...@pengutronix.de
--
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to
ptxdist-requ...@pengutronix.de
Re: [ptxdist] [PATCH] tf-a: Allow to build for multiple platforms
El jue., 24 sept. 2020 a las 11:31, Sascha Hauer () escribió: > > A single ptxdist build can be for multiple platforms, so allow to > compile the ARM trusted firmware for multiple platforms as well. Sorry if this is slightly off-topic but is this possible for u-boot as well? Specifically it would be good to be able to build several boardconfigs for the same board (e.g. a debug config and a production config). Do you know if this is currently possible? Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-requ...@pengutronix.de
Re: [ptxdist] [RFC PATCH 1/3] imx-uuc: new package
El mié., 25 mar. 2020 a las 19:44, Roland Hieber () escribió: > > +IMX_UUC_VERSION:= d6afb27e55d73d7ad08cd2dd51c784d8ec9694dc > > Nitpick: I don't know how picky opkg-based systems are with having > monotonically increasing version numbers, but in case someone uses them > to update software, you could make them happy by providing a fake > 'git describe' tag as a version: It is picky, and will refuse to upgrade if the version number seems to be lower than whatever is currently installed. So yes, the package version should be monotonically increasing and not simply a commit hash. When I face this case in my own packages I normally define two different varaibles, e.g.: IMX_UUC_VERSION := 0.0.1 IMX_UUC_GIT_TAG := d6afb27e55d73d7ad08cd2dd51c784d8ec9694dc and then use IMX_UUC_VERSION everywhere except in the URL: IMX_UUC_URL:= https://github.com/NXPmicro/imx-uuc.git;tag=$(IMX_UUC_GIT_TAG) Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v4] tf-a: new package for ARM trusted firmware A
+ifdef PTXCONF_TF_A > +ifeq ($(PTXCONF_TF_A_ARTIFACTS),) > +$(error TF_A_ARTIFACTS is empty. nothing to install.) > +endif > +endif > + > +TF_A_CONF_TOOL := NO > + > +$(STATEDIR)/tf-a.prepare: > + @$(call targetinfo) > + @rm -rf $(TF_A_DIR)/build/ > + @$(call touch) > + > +# > > +# Compile > +# > > + > +TF_A_MAKE_ENV := $(CROSS_ENV) > + > +# > > +# Install > +# > > + > +TF_A_BUILD_OUTPUT_DIR := $(TF_A_DIR)/build/$(call remove_quotes, \ > + $(PTXCONF_TF_A_PLATFORM))/$(if $(filter > 1,$(TF_A_RELEASE)),release,debug) > +TF_A_ARTIFACTS_SRC = $(wildcard $(addprefix $(TF_A_BUILD_OUTPUT_DIR)/, \ > + $(call remove_quotes,$(PTXCONF_TF_A_ARTIFACTS > +TF_A_ARTIFACTS_DEST = $(subst > $(TF_A_BUILD_OUTPUT_DIR)/,,$(TF_A_ARTIFACTS_SRC)) > + > +$(STATEDIR)/tf-a.install: > + @$(call targetinfo) > + @$(foreach artifact, $(TF_A_ARTIFACTS_SRC), \ > + install -v -D -m 644 $(artifact) \ > + $(TF_A_PKGDIR)/usr/lib/firmware/$(notdir > $(artifact))$(ptx/nl)) > + @$(call touch) > + > +# > > +# Target-Install > +# > > + > +$(STATEDIR)/tf-a.targetinstall: > + @$(call targetinfo) > + @$(foreach artifact, $(TF_A_ARTIFACTS_SRC), \ > + install -v -D -m 644 $(artifact) \ > + $(IMAGEDIR)/$(notdir $(artifact))$(ptx/nl)) > + @$(call touch) > + > +# > > +# Clean > +# > > + > +$(STATEDIR)/tf-a.clean: > + @$(call targetinfo) > + @rm -f $(addprefix $(IMAGEDIR)/, $(TF_A_ARTIFACTS_DEST)) > + @$(call clean_pkg, TF_A) > + > +# vim: syntax=make > -- > 2.25.0 > > > ___ > ptxdist mailing list > ptxdist@pengutronix.de -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v2] tf-a: new package for ARM trusted firmware A
El mar., 18 feb. 2020 a las 8:36, Michael Olbrich () escribió: > > On Mon, Feb 17, 2020 at 05:33:57PM +0100, Guillermo Rodriguez Garcia wrote: > > El lun., 17 feb. 2020 a las 17:26, Michael Tretter > > () escribió: > > > > > > On Wed, 12 Feb 2020 17:40:33 +0100, Ahmad Fatoum wrote: > > > > Trusted Firmware-A (TF-A) is a reference implementation of secure world > > > > software for Arm A-Profile architectures (Armv8-A and Armv7-A). > > > > > > I successfully built the TF-A BL31 for the ZynqMP using this rule. > > > > > > However, I saw that the TF-A build uses the current git commitish for > > > BUILD_STRING, which will be written into the binary. If I build the > > > TF-A with this rule, this ends up to be the commitish of the BSP. I'm > > > not sure if I actually want this, but I don't know what to put there > > > instead. > > > > Since we finally agreed to keep TF_A_EXTRA_ARGS in the final TF-A rule > > files, you can actually set BUILD_STRING to anything you want. Just > > include BUILD_STRING=whatever in the TF_A_EXTRA_ARGS parameter. > > There should always be a default BUILD_STRING that does not depend on the > BSP commit-ish. $(TF_A_VERSION) probably. OK, then we could add this to the .make file: TF_A_MAKE_OPT:= \ CROSS_COMPILE=$(BOOTLOADER_CROSS_COMPILE) \ HOSTCC=$(HOSTCC) \ PLAT=$(PTXCONF_TF_A_PLATFORM) \ ARCH=$(PTXCONF_TF_A_ARCH_STRING) \ ARM_ARCH_MAJOR=$(PTXCONF_TF_A_ARM_ARCH_MAJOR) \ BUILD_STRING=$(PTXCONF_TF_A_VERSION) \ $(call remove_quotes,$(PTXCONF_TF_A_EXTRA_ARGS)) \ all BUILD_STRING can still be overriden in TF_A_EXTRA_ARGS if needed. Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v2] tf-a: new package for ARM trusted firmware A
Hi Michael, El lun., 17 feb. 2020 a las 17:26, Michael Tretter () escribió: > > On Wed, 12 Feb 2020 17:40:33 +0100, Ahmad Fatoum wrote: > > Trusted Firmware-A (TF-A) is a reference implementation of secure world > > software for Arm A-Profile architectures (Armv8-A and Armv7-A). > > I successfully built the TF-A BL31 for the ZynqMP using this rule. > > However, I saw that the TF-A build uses the current git commitish for > BUILD_STRING, which will be written into the binary. If I build the > TF-A with this rule, this ends up to be the commitish of the BSP. I'm > not sure if I actually want this, but I don't know what to put there > instead. Since we finally agreed to keep TF_A_EXTRA_ARGS in the final TF-A rule files, you can actually set BUILD_STRING to anything you want. Just include BUILD_STRING=whatever in the TF_A_EXTRA_ARGS parameter. Best, Guillermo > > Michael > > > > > Cc: Alejandro Vazquez > > Signed-off-by: Rouven Czerwinski > > Signed-off-by: Ahmad Fatoum > > --- > > v1 -> v2: > > - Made TF_A_ARCH_MAJOR configurable to support 32 bit ARMv8 (Guillermo) > > - Replaces stm32mp-specific TF_A_DTB with TF_A_EXTRA_ARGS to contain > >all board/vendor specific options > > - removed reference to no longer existing CREDITS file > > - removed TF_A_MAKE_OPT contents that are set elsewhere > > - reduced uses of += in favor of directly appending to the string > > - delete old build directory in prepare instead of compile > > - use default compile stage (Guillermo) > > - install artifacts to sysroot /usr/lib/firmware in install stage > > - install artifacts to IMAGEDIR in targetinstall > > - fix clean stage to delete proper artifacts > > --- > > platforms/tf-a.in | 138 ++ > > rules/tf-a.make | 114 ++ > > 2 files changed, 252 insertions(+) > > create mode 100644 platforms/tf-a.in > > create mode 100644 rules/tf-a.make > > ___ > ptxdist mailing list > ptxdist@pengutronix.de -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] u-boot: Add support for custom make options
Hi all, A little explanation on this. I need to pass DEVICE_TREE=xxx to uboot as this is the "official" way to build u-boot for the stm32mp1 platform with a device tree other than the board's default. I started preparing a patch to allow setting a DEVICE_TREE value specifically, but there are other ways to do the same, e.g. EXT_DTB to specify a precompiled device tree instead. So I though perhaps a generic mechanism would be more useful. I also had a look at buildroot and a similar (generic) mechanism exists as well, so I ended up doing it like that. Comments welcome. Guillermo El vie., 14 feb. 2020 a las 12:07, Guillermo Rodríguez () escribió: > > Add a generic mechanism to allow passing custom make options to > U-boot. This can be used for example to pass a DEVICE_TREE= value. > > Signed-off-by: Guillermo Rodriguez > --- > platforms/u-boot.in | 7 +++ > rules/u-boot.make | 3 ++- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/platforms/u-boot.in b/platforms/u-boot.in > index 50fb008a3..491faed60 100644 > --- a/platforms/u-boot.in > +++ b/platforms/u-boot.in > @@ -71,6 +71,13 @@ config U_BOOT_CONFIG > > endif > > +config U_BOOT_CUSTOM_MAKE_OPTS > + prompt "Custom make options" > + string > + help > + List of custom make options passed at build time. Can be > + used for example to pass a DEVICE_TREE= value. > + > choice > prompt "Generate environment image" > default U_BOOT_ENV_IMAGE_NONE > diff --git a/rules/u-boot.make b/rules/u-boot.make > index 0c6bccc71..e386dc4d2 100644 > --- a/rules/u-boot.make > +++ b/rules/u-boot.make > @@ -55,7 +55,8 @@ U_BOOT_WRAPPER_BLACKLIST := \ > U_BOOT_CONF_OPT:= \ > -C $(U_BOOT_DIR) \ > O=$(U_BOOT_BUILD_DIR) \ > - V=$(PTXDIST_VERBOSE) > + V=$(PTXDIST_VERBOSE) \ > + $(call remove_quotes,$(PTXCONF_U_BOOT_CUSTOM_MAKE_OPTS)) > > U_BOOT_MAKE_ENV:= \ > CROSS_COMPILE=$(BOOTLOADER_CROSS_COMPILE) \ > -- > 2.21.0 > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v2] tf-a: new package for ARM trusted firmware A
El jue., 13 feb. 2020 a las 16:27, Ahmad Fatoum () escribió: > > On 2/13/20 4:24 PM, Guillermo Rodriguez Garcia wrote: > > El jue., 13 feb. 2020 a las 16:08, Ahmad Fatoum > > () escribió: > >> > >> On 2/13/20 4:05 PM, Guillermo Rodriguez Garcia wrote: > >> > >>>>>>> > >>>>>>>>>>> +# > >>>>>>>>>>> > >>>>>>>>>>> +# Install > >>>>>>>>>>> +# > >>>>>>>>>>> > >>>>>>>>>>> + > >>>>>>>>>>> +$(STATEDIR)/tf-a.install: > >>>>>>>>>>> + @$(call targetinfo) > >>>>>>>>>>> +ifeq ($(TF_A_ARTIFACTS_SRC),) > >>>>>>>>>>> + $(warning TF_A_ARTIFACTS is empty. nothing to install.) > >>>>>>>>>>> +else > >>>>>>>>>>> + @install -m644 -D \ > >>>>>>>>>>> + > >>>>>>>>>>> --target-directory=$(PTXCONF_SYSROOT_TARGET)/usr/lib/firmware \ > >>>>>>>>>> > >> > >>> OK this makes sense. > >>> > >>> But, you should at least make sure > >>> $(PTXCONF_SYSROOT_TARGET)/usr/lib/firmware exists before trying to > >>> copy anything into it. > >> > >> That's why -D is there. From man install(1): > >> > >> -D create all leading components of DEST except the last, or all > >> components of > >> --target-directory, then copy SOURCE to DEST > > > > Yes but the effect of -D combined with --target-directory does not > > seem to be standard; my version of install does not support it. > > The man page for my version says: > > > > -D create all leading components of DEST except the last, then > > copy SOURCE to DEST > > > > And a quick test yields the following: > > > > $ touch test > > $ install -D --target-directory a/b/c test > > install: failed to access 'a/b/c': No such file or director > > > > I guess it's better to avoid relying on that behaviour and create the > > directory explicitly instead. > > I see. Will replace with separate install -d in a v3 then. You might also want to update the targetinstall stage: - If IMAGEDIR is guaranteed to exist when the targetinstall rule runs, then the -D option can be dropped - If IMAGEDIR is not guaranteed to exist, then -D will not create the directory properly in the way the command is currently written, and you probably want also explicitly create the directory Thx, Guillermo > > > > > BR, > > > > Guillermo Rodriguez Garcia > > guille.rodrig...@gmail.com > > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | https://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v2] tf-a: new package for ARM trusted firmware A
El jue., 13 feb. 2020 a las 16:08, Ahmad Fatoum () escribió: > > On 2/13/20 4:05 PM, Guillermo Rodriguez Garcia wrote: > > >>>>> > >>>>>>>>> +# > >>>>>>>>> > >>>>>>>>> +# Install > >>>>>>>>> +# > >>>>>>>>> > >>>>>>>>> + > >>>>>>>>> +$(STATEDIR)/tf-a.install: > >>>>>>>>> + @$(call targetinfo) > >>>>>>>>> +ifeq ($(TF_A_ARTIFACTS_SRC),) > >>>>>>>>> + $(warning TF_A_ARTIFACTS is empty. nothing to install.) > >>>>>>>>> +else > >>>>>>>>> + @install -m644 -D \ > >>>>>>>>> + > >>>>>>>>> --target-directory=$(PTXCONF_SYSROOT_TARGET)/usr/lib/firmware \ > >>>>>>>> > > > OK this makes sense. > > > > But, you should at least make sure > > $(PTXCONF_SYSROOT_TARGET)/usr/lib/firmware exists before trying to > > copy anything into it. > > That's why -D is there. From man install(1): > > -D create all leading components of DEST except the last, or all > components of > --target-directory, then copy SOURCE to DEST Yes but the effect of -D combined with --target-directory does not seem to be standard; my version of install does not support it. The man page for my version says: -D create all leading components of DEST except the last, then copy SOURCE to DEST And a quick test yields the following: $ touch test $ install -D --target-directory a/b/c test install: failed to access 'a/b/c': No such file or director I guess it's better to avoid relying on that behaviour and create the directory explicitly instead. BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v2] tf-a: new package for ARM trusted firmware A
El jue., 13 feb. 2020 a las 15:44, Ahmad Fatoum () escribió: > > On 2/13/20 3:35 PM, Guillermo Rodriguez Garcia wrote: > > El jue., 13 feb. 2020 a las 15:32, Ahmad Fatoum > > () escribió: > >> > >> On 2/13/20 3:28 PM, Ahmad Fatoum wrote: > >>> On 2/13/20 3:25 PM, Guillermo Rodriguez Garcia wrote: > >>>> El jue., 13 feb. 2020 a las 14:30, Ahmad Fatoum > >>>> () escribió: > >>> > >>>>>>> +# > >>>>>>> > >>>>>>> +# Install > >>>>>>> +# > >>>>>>> > >>>>>>> + > >>>>>>> +$(STATEDIR)/tf-a.install: > >>>>>>> + @$(call targetinfo) > >>>>>>> +ifeq ($(TF_A_ARTIFACTS_SRC),) > >>>>>>> + $(warning TF_A_ARTIFACTS is empty. nothing to install.) > >>>>>>> +else > >>>>>>> + @install -m644 -D \ > >>>>>>> + > >>>>>>> --target-directory=$(PTXCONF_SYSROOT_TARGET)/usr/lib/firmware \ > >>>>>> > >>>>>> This doesn't look right. > >>>>>> Shouldn't the install stage install things to the package install > >>>>>> directory only? > >>>>>> And, in case you want to install something somewhere else, shouldn't > >>>>>> the actual target directory at least be configurable? > >>>>>> For example there is no /usr/lib/firmware in my platform. > >>>>> > >>>>> That's only in the sysroot for use by other rules (e.g. barebox > >>>>> embedding TF-A > >>>>> on some i.MX8). It's not installed in the target rootfs. > >>>> > >>>> Ok but that's specific to that particular configuration, and the > >>>> choice of directory also seems to be arbitrary. > >>> > >>> You got to standardize on something. If this is good, a > >>> $(PTXCONF_SYSROOT_FIRMWARE) > >>> might be a good thing to agree on. > >>> > >>>> Does this belong in a generic rules file ? > >>> > >>> How would that look like? > >> > >> Ah, you mean this is too specific that it shouldn't be in tf-a.make? > > > > Yes. > > > >> > >> Well, Some Zynqs do this as well. If you are embedding OPTEE in TF-A, you > >> will need > >> to save optee somewhere too. It's not a niche use case. The split between > >> install > > > > For cases like this (optee) you're going to need to amend tf-a.in > > anyway because you need to add dependencies (you mentioned this > > yourself in a previous email) > > > >> and target-install is just because so many vendors have their own idea of > >> where the TF-A > >> comes from. If most of these can be made to work by installing the file to > >> sysroot along > >> with the IMAGEDIR, so why not do so? > > > > If it really covers "most of these" use cases, then I guess it may make > > sense. > > if it's consumed by image rules, it's in IMAGEDIR. If it's consumed by > "normal" rules, > it's in the sysroot at a fixed place. Not sure if there is another use case I > am missing. > > > > > Still -- shouldn't it at least be optional? > > Why should the .install stage be behind an option, but the .targetinstall not? > Should there be options for enabling/disabling each one of them? > > And why? Just to save a few hundred kilobytes extra in the _build_ directory? > Doesn't sound like a good enough reason to me. OK this makes sense. But, you should at least make sure $(PTXCONF_SYSROOT_TARGET)/usr/lib/firmware exists before trying to copy anything into it. Guillermo > > Cheers > Ahmad > > > > > Guillermo > > > >> > >> Cheers > >> Ahmad > >> > >>> > >>> > >>> Cheers > >>> Ahmad > >>> > >> > >> > >> -- > >> Pengutronix e.K. | | > >> Steuerwalder Str. 21 | https://www.pengutronix.de/ | > >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > > > > > > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | https://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v2] tf-a: new package for ARM trusted firmware A
El jue., 13 feb. 2020 a las 15:32, Ahmad Fatoum () escribió: > > On 2/13/20 3:28 PM, Ahmad Fatoum wrote: > > On 2/13/20 3:25 PM, Guillermo Rodriguez Garcia wrote: > >> El jue., 13 feb. 2020 a las 14:30, Ahmad Fatoum > >> () escribió: > > > >>>>> +# > >>>>> > >>>>> +# Install > >>>>> +# > >>>>> > >>>>> + > >>>>> +$(STATEDIR)/tf-a.install: > >>>>> + @$(call targetinfo) > >>>>> +ifeq ($(TF_A_ARTIFACTS_SRC),) > >>>>> + $(warning TF_A_ARTIFACTS is empty. nothing to install.) > >>>>> +else > >>>>> + @install -m644 -D \ > >>>>> + > >>>>> --target-directory=$(PTXCONF_SYSROOT_TARGET)/usr/lib/firmware \ > >>>> > >>>> This doesn't look right. > >>>> Shouldn't the install stage install things to the package install > >>>> directory only? > >>>> And, in case you want to install something somewhere else, shouldn't > >>>> the actual target directory at least be configurable? > >>>> For example there is no /usr/lib/firmware in my platform. > >>> > >>> That's only in the sysroot for use by other rules (e.g. barebox embedding > >>> TF-A > >>> on some i.MX8). It's not installed in the target rootfs. > >> > >> Ok but that's specific to that particular configuration, and the > >> choice of directory also seems to be arbitrary. > > > > You got to standardize on something. If this is good, a > > $(PTXCONF_SYSROOT_FIRMWARE) > > might be a good thing to agree on. > > > >> Does this belong in a generic rules file ? > > > > How would that look like? > > Ah, you mean this is too specific that it shouldn't be in tf-a.make? Yes. > > Well, Some Zynqs do this as well. If you are embedding OPTEE in TF-A, you > will need > to save optee somewhere too. It's not a niche use case. The split between > install For cases like this (optee) you're going to need to amend tf-a.in anyway because you need to add dependencies (you mentioned this yourself in a previous email) > and target-install is just because so many vendors have their own idea of > where the TF-A > comes from. If most of these can be made to work by installing the file to > sysroot along > with the IMAGEDIR, so why not do so? If it really covers "most of these" use cases, then I guess it may make sense. Still -- shouldn't it at least be optional? Guillermo > > Cheers > Ahmad > > > > > > > Cheers > > Ahmad > > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | https://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v2] tf-a: new package for ARM trusted firmware A
El jue., 13 feb. 2020 a las 14:30, Ahmad Fatoum () escribió: > > On 2/13/20 1:59 PM, Guillermo Rodriguez Garcia wrote: > > Hi Ahmad, > > > > El mié., 12 feb. 2020 a las 17:40, Ahmad Fatoum > > () escribió: > >> > >> Trusted Firmware-A (TF-A) is a reference implementation of secure world > >> software for Arm A-Profile architectures (Armv8-A and Armv7-A). > >> > >> Cc: Alejandro Vazquez > >> Signed-off-by: Rouven Czerwinski > >> Signed-off-by: Ahmad Fatoum > >> --- > >> v1 -> v2: > >> - Made TF_A_ARCH_MAJOR configurable to support 32 bit ARMv8 (Guillermo) > >> - Replaces stm32mp-specific TF_A_DTB with TF_A_EXTRA_ARGS to contain > >>all board/vendor specific options > >> - removed reference to no longer existing CREDITS file > >> - removed TF_A_MAKE_OPT contents that are set elsewhere > >> - reduced uses of += in favor of directly appending to the string > >> - delete old build directory in prepare instead of compile > >> - use default compile stage (Guillermo) > >> - install artifacts to sysroot /usr/lib/firmware in install stage > >> - install artifacts to IMAGEDIR in targetinstall > >> - fix clean stage to delete proper artifacts > >> --- > >> platforms/tf-a.in | 138 ++ > >> rules/tf-a.make | 114 ++ > >> 2 files changed, 252 insertions(+) > >> create mode 100644 platforms/tf-a.in > >> create mode 100644 rules/tf-a.make > >> > >> diff --git a/platforms/tf-a.in b/platforms/tf-a.in > >> new file mode 100644 > >> index ..f3971c4c2a3a > >> --- /dev/null > >> +++ b/platforms/tf-a.in > >> @@ -0,0 +1,138 @@ > >> +## SECTION=bootloader > >> + > >> +menuconfig TF_A > >> + select BOOTLOADER > >> + prompt "ARM Trusted Firmware-A" > >> + depends on ARCH_ARM || ARCH_ARM64 > >> + bool > >> + > >> +if TF_A > >> + > >> +config TF_A_ARCH_STRING > >> +string > >> +default "aarch32" if ARCH_ARM > >> +default "aarch64" if ARCH_ARM64 > >> + > >> +choice > >> + prompt "TF-A Architecture" > >> + default TF_A_ARM_ARCH_MAJOR_7 if ARCH_ARM > >> + default TF_A_ARM_ARCH_MAJOR_8 if ARCH_ARM64 > >> + help > >> + Architecture version major number > >> + > >> + config TF_A_ARM_ARCH_MAJOR_7 > >> + depends on ARCH_ARM > >> + prompt "ARMv7" > >> + bool > >> + > >> + config TF_A_ARM_ARCH_MAJOR_8_32_BIT > >> + depends on ARCH_ARM > >> + prompt "ARMv8 32-bit" > >> + bool > >> + > >> + config TF_A_ARM_ARCH_MAJOR_8 > >> + depends on ARCH_ARM64 > >> + prompt "ARMv8" > >> + bool > >> + > >> +endchoice > >> + > >> +config TF_A_ARM_ARCH_MAJOR > >> +int > >> +default 7 if TF_A_ARM_ARCH_MAJOR_7 > >> +default 8 if TF_A_ARM_ARCH_MAJOR_8_32_BIT > >> +default 8 if TF_A_ARM_ARCH_MAJOR_8 > >> + > >> +config TF_A_VERSION > >> + string > >> + default "v2.2" > >> + prompt "TF-A version" > >> + help > >> + Enter the TF-A version you want to build. Usally something like > >> "v2.2" > >> + > >> +config TF_A_MD5 > >> + string > >> + default "bb300e5a62c911e189c80d935d497a4b" > >> + prompt "TF-A source md5" > >> + > >> +config TF_A_PLATFORM > >> + string > >> + prompt "TF-A target platform" > >> + help > >> + The TF-A target platform. > >> + > >> +config TF_A_ARM_ARCH_MINOR > >> + depends on TF_A_ARM_ARCH_MAJOR_8 || TF_A_ARM_ARCH_MAJOR_8_32_BIT > >> + int > >> + default 0 > >> + prompt "TF-A target ARMv8.MINOR version" > >> + help > >> + The minor version of the ARMv8 architecture targeted. Defaults > >> to 0. > >> + > >> +config TF_A_EXTRA_ARGS > >> +
Re: [ptxdist] [PATCH v2] tf-a: new package for ARM trusted firmware A
_A_ARTIFACTS_SRC) > +endif > + @$(call touch) > + > +# > > +# Target-Install > +# > > + > +$(STATEDIR)/tf-a.targetinstall: > + @$(call targetinfo) > +ifeq ($(TF_A_ARTIFACTS_SRC),) > + $(warning TF_A_ARTIFACTS is empty. nothing to install.) > +else > + @install -D -m644 $(TF_A_ARTIFACTS_SRC) $(IMAGEDIR) > +endif > + @$(call touch) > + > +# > > +# Clean > +# > > + > +$(STATEDIR)/tf-a.clean: > + @$(call targetinfo) > + @$(call clean_pkg, TF_A) > + @rm -f $(addprefix $(PTXCONF_SYSROOT_TARGET)/usr/lib/firmware/, \ > + TF_A_ARTIFACTS_DEST) > + @rm -f $(addprefix $(IMAGEDIR), TF_A_ARTIFACTS_DEST) > + > +# vim: syntax=make > -- > 2.25.0 > > > ___ > ptxdist mailing list > ptxdist@pengutronix.de -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] tf-a: new package for ARM trusted firmware A
El mié., 12 feb. 2020 a las 10:28, Ahmad Fatoum () escribió: > > Hi, > > On 2/12/20 10:07 AM, Guillermo Rodriguez Garcia wrote: > >>> Uhm, here I didn't need to specify CROSS_ENV and things seemed to work > >>> just fine. > >> > >> CROSS_ENV sets stuff like CC and LD. I took a look inside the v2.2 TF-A > >> Makefile > >> and on line 808 there is a reference to $(CC) before it's defined, > > > > That would be a bug in the Makefile, and if this was the case, > > shouldn't we add a > > patch to fix the Makefile (and possibly submit it to upstream), > > instead of trying to > > work around the bug by setting CROSS_ENV ? > > > > Anyway I am not sure this is actually a bug -- I see that CC is > > defined in line 160 > > in v2.2 of the Makefile; that should happen before the usage in line 808. > > Sorry, see line 93, which happens before the definition. Ah, yes. That indeed looks like a bug. > > > > >> so in that case it > >> would come from the environment. It's probably unintended, but to account > >> for > >> any other scripts that may reference LD, CC and the like without defining > >> them > >> first, I guess it's better to have CROSS_ENV in. Do you agree? > > > > I guess keeping it can not do any harm. However it can also hide bugs, > > so I am not > > sure what is best. > > yes, it's a bug and should be fixed. But this might not be the only instance, > so we can either: > > - Not do anything > - Give CC and friends a proper value Yes, or: 3. Add a patch to fix the Makefile (as it is done in many other ptxdist packages) But anyway, as I said above, I don't have a strong opinion on this. Setting CROSS_ENV works around the bug, which is both good and bad (good for obvious reasons, bad because it sidesteps this kind of issues rather than fixing them). So, looking forward to v2 :-) Best, Guillermo > > I think #2 is reasonable. > > Cheers > Ahmad > > > > > Guillermo > > > >> > >>> > >>>> > >>>>>> +$(STATEDIR)/tf-a.prepare: > >>>>>> + @$(call targetinfo) > >>>>>> + @$(call touch) > >>>>> > >>>>> I think this does nothing and can be removed. > >>>> > >>>> Right. See tf-a.compile below > >>>> > >>>>> > >>>>>> + > >>>>>> +# > >>>>>> > >>>>>> +# Compile > >>>>>> +# > >>>>>> > >>>>>> +TF_A_MAKE_OPT += PLAT=$(PTXCONF_TF_A_PLATFORM) > >>>>>> + > >>>>>> +TF_A_MAKE_OPT += DEBUG=$(call ptx/ifdef,TF_A_DEBUG,1,0) > >>>>>> +TF_A_BUILD_OUTPUT_DIR := $(call ptx/ifdef,TF_A_DEBUG,debug,release) > >>>>>> + > >>>>>> +TF_A_MAKE_OPT += ARCH=$(PTXCONF_TF_A_ARCH_STRING) > >>>>>> +TF_A_MAKE_OPT += LOAD_IMAGE_V2=1 > >>> > >>> I think this should not be hardcoded. > >>> > >>> (Sorry, didn't spot this one before) > >> > >> Will drop it. > >> > >>> > >>>>>> +ifdef PTXCONF_TF_A_BL32_TSP > >>>>>> +TF_A_MAKE_OPT += > >>>>>> ARM_TSP_RAM_LOCATION=$(PTXCONF_TF_A_BL32_TSP_RAM_LOCATION_STRING) > >>>>>> +endif > >>>>>> +TF_A_MAKE_OPT += ARM_ARCH_MAJOR=$(PTXCONF_TF_A_ARM_ARCH_MAJOR) > >>>>>> +ifdef PTXCONF_TF_A_ARM_ARCH_MINOR > >>>>>> +TF_A_MAKE_OPT += ARM_ARCH_MINOR=$(PTXCONF_TF_A_ARM_ARCH_MINOR) > >>>>>> +endif > >>>>>> + > >>>>>> +ifneq ($(PTXCONF_TF_A_DTB),) > >>>>>> +TF_A_MAKE_OPT += DTB_FILE_NAME=$(PTXCONF_TF_A_DTB) > >>>>>> +endif > >>>>>> + > >>>>>> +ifdef PTXCONF_TF_A_BL32_SP_MIN > >>>>>> +TF_A_MAKE_OPT += AARCH32_SP=sp_min > >>>>>> +endif > >>>>>> + > >>>>>> +TF_A_MAKE_OPT += all > >>>>>> + > >>>>>> +TF_A_ARTIFACTS = $(addprefix > >>>>>> $(TF_A_DIR)/build/$(PTXCONF_TF_A_PLATFORM)/$(TF_A_BUILD_OUTPUT_DIR)/, \ > >>>>>> + $(call remove_quotes,$(PTXCONF_TF_A_ARTIFACTS))) > >>
Re: [ptxdist] [PATCH] tf-a: new package for ARM trusted firmware A
Hi Ahmad, El mar., 11 feb. 2020 a las 17:53, Ahmad Fatoum () escribió: > > Hello Guillermo, > > On 2/11/20 5:27 PM, Guillermo Rodriguez Garcia wrote: > > Hi Ahmad, > > > > El mar., 11 feb. 2020 a las 16:22, Ahmad Fatoum > > () escribió: > >> > >> Hi, > >> > >> On 2/11/20 9:37 AM, Guillermo Rodriguez Garcia wrote: > >>> Hi Ahmad, > >>> > >>> Some other questions and comments, please see below. > >>> > >>> El lun., 10 feb. 2020 a las 17:16, Ahmad Fatoum > >>> () escribió: > >>>> > >>>> Trusted Firmware-A (TF-A) is a reference implementation of secure world > >>>> software for Arm A-Profile architectures (Armv8-A and Armv7-A). > >>>> > >>>> Cc: Alejandro Vazquez > >>>> Signed-off-by: Rouven Czerwinski > >>>> Signed-off-by: Ahmad Fatoum > >>>> --- > >>>> platforms/tf-a.in | 113 ++ > >>>> rules/tf-a.make | 123 ++ > >>>> 2 files changed, 236 insertions(+) > >>>> create mode 100644 platforms/tf-a.in > >>>> create mode 100644 rules/tf-a.make > >>>> > >>>> diff --git a/platforms/tf-a.in b/platforms/tf-a.in > >>>> new file mode 100644 > >>>> index ..5aa4ca473c35 > >>>> --- /dev/null > >>>> +++ b/platforms/tf-a.in > >>>> @@ -0,0 +1,113 @@ > >>>> +## SECTION=bootloader > >>>> + > >>>> +menuconfig TF_A > >>>> + select BOOTLOADER > >>>> + prompt "ARM Trusted Firmware-A" > >>>> + depends on ARCH_ARM || ARCH_ARM64 > >>>> + bool > >>>> + > >>>> +if TF_A > >>>> + > >>>> +config TF_A_ARCH_STRING > >>>> +string > >>>> +default "aarch32" if ARCH_ARM > >>>> +default "aarch64" if ARCH_ARM64 > >>>> + > >>>> +config TF_A_ARM_ARCH_MAJOR > >>>> +int > >>>> +default "7" if ARCH_ARM > >>>> +default "8" if ARCH_ARM64 > >>> > >>> Shouldn't this be configurable? > >>> aarch64 is always v8, but for aarch32 you can have either v7 or v8. > >> > >> Ah, indeed. Didn't know about cores like the Cortex-A32. > >> I will make this configurable. > >> > >>>> + > >>>> +config TF_A_VERSION > >>>> + string > >>>> + default "v2.2" > >>>> + prompt "TF-A version" > >>>> + help > >>>> + Enter the TF-A version you want to build. Usally something > >>>> like "v2.2" > >>>> + > >>>> +config TF_A_MD5 > >>>> + string > >>>> + default "bb300e5a62c911e189c80d935d497a4b" > >>>> + prompt "TF-A source md5" > >>>> + > >>>> +config TF_A_PLATFORM > >>>> + string > >>>> + prompt "TF-A target platform" > >>>> + help > >>>> + The TF-A target platform. > >>>> + > >>>> +if ARCH_ARM64 > >>>> +config TF_A_ARM_ARCH_MINOR > >>>> + int > >>>> + default 0 > >>>> + prompt "TF-A target ARMv8.MINOR version" > >>>> + help > >>>> + The minor version of the ARMv8 architecture targeted. Defaults > >>>> to 0. > >>>> +endif > >>>> + > >>>> +config TF_A_DTB > >>>> + string > >>>> + prompt "TF-A DTB file name" > >>>> + help > >>>> + Device Tree Binary file name > >>>> + > >>>> +config TF_A_ARTIFACTS > >>>> + string > >>>> + prompt "TF-A artifact file names" > >>>> + default "bl2.bin" > >>>> + help > >>>> + A space-separated list of artifacts to copy to the image > >>>> directory. > >>>> + All file names are relative to the appropriate TF-A platform
Re: [ptxdist] [PATCH] tf-a: new package for ARM trusted firmware A
Hi Ahmad, El mar., 11 feb. 2020 a las 16:22, Ahmad Fatoum () escribió: > > Hi, > > On 2/11/20 9:37 AM, Guillermo Rodriguez Garcia wrote: > > Hi Ahmad, > > > > Some other questions and comments, please see below. > > > > El lun., 10 feb. 2020 a las 17:16, Ahmad Fatoum > > () escribió: > >> > >> Trusted Firmware-A (TF-A) is a reference implementation of secure world > >> software for Arm A-Profile architectures (Armv8-A and Armv7-A). > >> > >> Cc: Alejandro Vazquez > >> Signed-off-by: Rouven Czerwinski > >> Signed-off-by: Ahmad Fatoum > >> --- > >> platforms/tf-a.in | 113 ++ > >> rules/tf-a.make | 123 ++ > >> 2 files changed, 236 insertions(+) > >> create mode 100644 platforms/tf-a.in > >> create mode 100644 rules/tf-a.make > >> > >> diff --git a/platforms/tf-a.in b/platforms/tf-a.in > >> new file mode 100644 > >> index ..5aa4ca473c35 > >> --- /dev/null > >> +++ b/platforms/tf-a.in > >> @@ -0,0 +1,113 @@ > >> +## SECTION=bootloader > >> + > >> +menuconfig TF_A > >> + select BOOTLOADER > >> + prompt "ARM Trusted Firmware-A" > >> + depends on ARCH_ARM || ARCH_ARM64 > >> + bool > >> + > >> +if TF_A > >> + > >> +config TF_A_ARCH_STRING > >> +string > >> +default "aarch32" if ARCH_ARM > >> +default "aarch64" if ARCH_ARM64 > >> + > >> +config TF_A_ARM_ARCH_MAJOR > >> +int > >> +default "7" if ARCH_ARM > >> +default "8" if ARCH_ARM64 > > > > Shouldn't this be configurable? > > aarch64 is always v8, but for aarch32 you can have either v7 or v8. > > Ah, indeed. Didn't know about cores like the Cortex-A32. > I will make this configurable. > > >> + > >> +config TF_A_VERSION > >> + string > >> + default "v2.2" > >> + prompt "TF-A version" > >> + help > >> + Enter the TF-A version you want to build. Usally something like > >> "v2.2" > >> + > >> +config TF_A_MD5 > >> + string > >> + default "bb300e5a62c911e189c80d935d497a4b" > >> + prompt "TF-A source md5" > >> + > >> +config TF_A_PLATFORM > >> + string > >> + prompt "TF-A target platform" > >> + help > >> + The TF-A target platform. > >> + > >> +if ARCH_ARM64 > >> +config TF_A_ARM_ARCH_MINOR > >> + int > >> + default 0 > >> + prompt "TF-A target ARMv8.MINOR version" > >> + help > >> + The minor version of the ARMv8 architecture targeted. Defaults > >> to 0. > >> +endif > >> + > >> +config TF_A_DTB > >> + string > >> + prompt "TF-A DTB file name" > >> + help > >> + Device Tree Binary file name > >> + > >> +config TF_A_ARTIFACTS > >> + string > >> + prompt "TF-A artifact file names" > >> + default "bl2.bin" > >> + help > >> + A space-separated list of artifacts to copy to the image > >> directory. > >> + All file names are relative to the appropriate TF-A platform > >> build > >> + directory. > >> + > >> +comment "Payloads" > >> + > >> +choice > >> + prompt "BL32 Payload" > >> + default TF_A_BL32_NONE > >> + help > >> + payload for BL32 (Secure World OS) > >> + > >> + config TF_A_BL32_NONE > >> + prompt "None" > >> + bool > >> + > >> + config TF_A_BL32_SP_MIN > >> + depends on ARCH_ARM > >> + prompt "sp_min" > >> + bool > >> + > >> + config TF_A_BL32_TSP > >> + depends on ARCH_ARM64 > >> + prompt "Test Secure Payload" > >> + bool > > > > No way to specify other payloads? > > I don't use any others at the moment, so no. &
Re: [ptxdist] [PATCH] tf-a: new package for ARM trusted firmware A
contributed to this project. > +# > +# For further information about the PTXdist project and license conditions > +# see the README file. > +# > + > +# > +# We provide this package > +# > +PACKAGES-$(PTXCONF_TF_A) += tf-a > + > +# > +# Paths and names > +# > +TF_A_VERSION := $(call remove_quotes,$(PTXCONF_TF_A_VERSION)) > +TF_A_MD5 := $(call remove_quotes,$(PTXCONF_TF_A_MD5)) > +TF_A := tf-a-$(TF_A_VERSION) > +TF_A_SUFFIX:= tar.gz > +TF_A_URL := > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/snapshot/$(TF_A_VERSION).$(TF_A_SUFFIX) > +TF_A_SOURCE:= $(SRCDIR)/$(TF_A).$(TF_A_SUFFIX) > +TF_A_DIR := $(BUILDDIR)/$(TF_A) > +TF_A_LICENSE:= BSD-3-Clause > + > +# > > +# Prepare > +# > > + > +TF_A_WRAPPER_BLACKLIST := \ > + TARGET_HARDEN_RELRO \ > + TARGET_HARDEN_BINDNOW \ > + TARGET_HARDEN_PIE \ > + TARGET_DEBUG \ > + TARGET_BUILD_ID > + > +TF_A_PATH := PATH=$(CROSS_PATH) > +TF_A_MAKE_OPT := \ > + V=$(PTXDIST_VERBOSE) \ > + CROSS_COMPILE=$(BOOTLOADER_CROSS_COMPILE) \ > + HOSTCC=$(HOSTCC) > +TF_A_CONF_TOOL := NO > +TF_A_MAKE_ENV := $(CROSS_ENV) Do you need $(CROSS_ENV) here? (not used in e.g. u-boot.make) > +# TF_A_DEBUG=yes > + > + > +$(STATEDIR)/tf-a.prepare: > + @$(call targetinfo) > + @$(call touch) I think this does nothing and can be removed. > + > +# > > +# Compile > +# > > +TF_A_MAKE_OPT += PLAT=$(PTXCONF_TF_A_PLATFORM) > + > +TF_A_MAKE_OPT += DEBUG=$(call ptx/ifdef,TF_A_DEBUG,1,0) > +TF_A_BUILD_OUTPUT_DIR := $(call ptx/ifdef,TF_A_DEBUG,debug,release) > + > +TF_A_MAKE_OPT += ARCH=$(PTXCONF_TF_A_ARCH_STRING) > +TF_A_MAKE_OPT += LOAD_IMAGE_V2=1 > +ifdef PTXCONF_TF_A_BL32_TSP > +TF_A_MAKE_OPT += > ARM_TSP_RAM_LOCATION=$(PTXCONF_TF_A_BL32_TSP_RAM_LOCATION_STRING) > +endif > +TF_A_MAKE_OPT += ARM_ARCH_MAJOR=$(PTXCONF_TF_A_ARM_ARCH_MAJOR) > +ifdef PTXCONF_TF_A_ARM_ARCH_MINOR > +TF_A_MAKE_OPT += ARM_ARCH_MINOR=$(PTXCONF_TF_A_ARM_ARCH_MINOR) > +endif > + > +ifneq ($(PTXCONF_TF_A_DTB),) > +TF_A_MAKE_OPT += DTB_FILE_NAME=$(PTXCONF_TF_A_DTB) > +endif > + > +ifdef PTXCONF_TF_A_BL32_SP_MIN > +TF_A_MAKE_OPT += AARCH32_SP=sp_min > +endif > + > +TF_A_MAKE_OPT += all > + > +TF_A_ARTIFACTS = $(addprefix > $(TF_A_DIR)/build/$(PTXCONF_TF_A_PLATFORM)/$(TF_A_BUILD_OUTPUT_DIR)/, \ > + $(call remove_quotes,$(PTXCONF_TF_A_ARTIFACTS))) > + > +$(STATEDIR)/tf-a.compile: > + @$(call targetinfo) > + @rm -rf $(TF_A_DIR)/build/ > + @$(call world/compile, TF_A) > + @$(call touch) Can't you use the default compile rule here? > + > +# > > +# Install > +# > > + > +$(STATEDIR)/tf-a.install: > + @$(call targetinfo) > + > +ifeq ($(TF_A_ARTIFACTS),) > + $(warning TF_A_ARTIFACTS is empty. nothing to install.) > +else > + @install -D -m644 $(TF_A_ARTIFACTS) $(IMAGEDIR) > +endif Shouldn't this (copying files to IMAGEDIR) happen in targetinstall rather than install? Again based on what is being done for other bootloaders. Thanks, Guillermo > + > + @$(call touch) > + > +# > > +# Target-Install > +# > > + > +$(STATEDIR)/tf-a.targetinstall: > + @$(call targetinfo) > + @$(call touch) > + > +# > > +# Clean > +# > > + > +$(STATEDIR)/tf-a.clean: > + @$(call targetinfo) > + @$(call clean_pkg, TF_A) > + @rm -f $(IMAGEDIR)/bl1.bin $(IMAGEDIR)/fip.bin > + > +# vim: syntax=make > -- > 2.25.0 > > > ___ > ptxdist mailing list > ptxdist@pengutronix.de -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] tf-a: new package for ARM trusted firmware A
El lun., 10 feb. 2020 a las 17:33, Ahmad Fatoum () escribió: > > Hello Guillermo, > > On 2/10/20 5:29 PM, Guillermo Rodriguez Garcia wrote: > > Hello, > > > > El lun., 10 feb. 2020 a las 17:16, Ahmad Fatoum > > () escribió: > >> > >> Trusted Firmware-A (TF-A) is a reference implementation of secure world > >> software for Arm A-Profile architectures (Armv8-A and Armv7-A). > >> > >> Cc: Alejandro Vazquez > >> Signed-off-by: Rouven Czerwinski > >> Signed-off-by: Ahmad Fatoum > >> --- > >> platforms/tf-a.in | 113 ++ > >> rules/tf-a.make | 123 ++ > >> 2 files changed, 236 insertions(+) > >> create mode 100644 platforms/tf-a.in > >> create mode 100644 rules/tf-a.make > >> > >> diff --git a/platforms/tf-a.in b/platforms/tf-a.in > >> new file mode 100644 > >> index ..5aa4ca473c35 > >> --- /dev/null > >> +++ b/platforms/tf-a.in > >> @@ -0,0 +1,113 @@ > >> +## SECTION=bootloader > >> + > >> +menuconfig TF_A > >> + select BOOTLOADER > >> + prompt "ARM Trusted Firmware-A" > >> + depends on ARCH_ARM || ARCH_ARM64 > >> + bool > >> + > >> +if TF_A > >> + > >> +config TF_A_ARCH_STRING > >> +string > >> +default "aarch32" if ARCH_ARM > >> +default "aarch64" if ARCH_ARM64 > >> + > >> +config TF_A_ARM_ARCH_MAJOR > >> +int > >> +default "7" if ARCH_ARM > >> +default "8" if ARCH_ARM64 > >> + > >> +config TF_A_VERSION > >> + string > >> + default "v2.2" > >> + prompt "TF-A version" > >> + help > >> + Enter the TF-A version you want to build. Usally something like > >> "v2.2" > >> + > >> +config TF_A_MD5 > >> + string > >> + default "bb300e5a62c911e189c80d935d497a4b" > >> + prompt "TF-A source md5" > >> + > >> +config TF_A_PLATFORM > >> + string > >> + prompt "TF-A target platform" > >> + help > >> + The TF-A target platform. > >> + > >> +if ARCH_ARM64 > >> +config TF_A_ARM_ARCH_MINOR > >> + int > >> + default 0 > >> + prompt "TF-A target ARMv8.MINOR version" > >> + help > >> + The minor version of the ARMv8 architecture targeted. Defaults > >> to 0. > >> +endif > >> + > >> +config TF_A_DTB > >> + string > >> + prompt "TF-A DTB file name" > >> + help > >> + Device Tree Binary file name > >> + > >> +config TF_A_ARTIFACTS > >> + string > >> + prompt "TF-A artifact file names" > >> + default "bl2.bin" > >> + help > >> + A space-separated list of artifacts to copy to the image > >> directory. > >> + All file names are relative to the appropriate TF-A platform > >> build > >> + directory. > >> + > >> +comment "Payloads" > >> + > >> +choice > >> + prompt "BL32 Payload" > >> + default TF_A_BL32_NONE > >> + help > >> + payload for BL32 (Secure World OS) > >> + > >> + config TF_A_BL32_NONE > >> + prompt "None" > >> + bool > >> + > >> + config TF_A_BL32_SP_MIN > >> + depends on ARCH_ARM > >> + prompt "sp_min" > >> + bool > >> + > >> + config TF_A_BL32_TSP > >> + depends on ARCH_ARM64 > >> + prompt "Test Secure Payload" > >> + bool > >> + > >> +endchoice > >> + > >> +if TF_A_BL32_TSP > >> +choice TF_A_BL32_TSP_RAM_LOCATION > >> + prompt "TSP location" > >> + default TF_A_BL32_TSP_RAM_LOCATION_TSRAM > >> + > >> + config TF_A_BL32_TSP_RAM_LOCATION_TSRAM > >> + prompt "Trusted SRAM" > >> +
Re: [ptxdist] [PATCH] tf-a: new package for ARM trusted firmware A
Hello, El lun., 10 feb. 2020 a las 17:16, Ahmad Fatoum () escribió: > > Trusted Firmware-A (TF-A) is a reference implementation of secure world > software for Arm A-Profile architectures (Armv8-A and Armv7-A). > > Cc: Alejandro Vazquez > Signed-off-by: Rouven Czerwinski > Signed-off-by: Ahmad Fatoum > --- > platforms/tf-a.in | 113 ++ > rules/tf-a.make | 123 ++ > 2 files changed, 236 insertions(+) > create mode 100644 platforms/tf-a.in > create mode 100644 rules/tf-a.make > > diff --git a/platforms/tf-a.in b/platforms/tf-a.in > new file mode 100644 > index ..5aa4ca473c35 > --- /dev/null > +++ b/platforms/tf-a.in > @@ -0,0 +1,113 @@ > +## SECTION=bootloader > + > +menuconfig TF_A > + select BOOTLOADER > + prompt "ARM Trusted Firmware-A" > + depends on ARCH_ARM || ARCH_ARM64 > + bool > + > +if TF_A > + > +config TF_A_ARCH_STRING > +string > +default "aarch32" if ARCH_ARM > +default "aarch64" if ARCH_ARM64 > + > +config TF_A_ARM_ARCH_MAJOR > +int > +default "7" if ARCH_ARM > +default "8" if ARCH_ARM64 > + > +config TF_A_VERSION > + string > + default "v2.2" > + prompt "TF-A version" > + help > + Enter the TF-A version you want to build. Usally something like > "v2.2" > + > +config TF_A_MD5 > + string > + default "bb300e5a62c911e189c80d935d497a4b" > + prompt "TF-A source md5" > + > +config TF_A_PLATFORM > + string > + prompt "TF-A target platform" > + help > + The TF-A target platform. > + > +if ARCH_ARM64 > +config TF_A_ARM_ARCH_MINOR > + int > + default 0 > + prompt "TF-A target ARMv8.MINOR version" > + help > + The minor version of the ARMv8 architecture targeted. Defaults to 0. > +endif > + > +config TF_A_DTB > + string > + prompt "TF-A DTB file name" > + help > + Device Tree Binary file name > + > +config TF_A_ARTIFACTS > + string > + prompt "TF-A artifact file names" > + default "bl2.bin" > + help > + A space-separated list of artifacts to copy to the image directory. > + All file names are relative to the appropriate TF-A platform build > + directory. > + > +comment "Payloads" > + > +choice > + prompt "BL32 Payload" > + default TF_A_BL32_NONE > + help > + payload for BL32 (Secure World OS) > + > + config TF_A_BL32_NONE > + prompt "None" > + bool > + > + config TF_A_BL32_SP_MIN > + depends on ARCH_ARM > + prompt "sp_min" > + bool > + > + config TF_A_BL32_TSP > + depends on ARCH_ARM64 > + prompt "Test Secure Payload" > + bool > + > +endchoice > + > +if TF_A_BL32_TSP > +choice TF_A_BL32_TSP_RAM_LOCATION > + prompt "TSP location" > + default TF_A_BL32_TSP_RAM_LOCATION_TSRAM > + > + config TF_A_BL32_TSP_RAM_LOCATION_TSRAM > + prompt "Trusted SRAM" > + bool > + > + config TF_A_BL32_TSP_RAM_LOCATION_TDRAM > + prompt "Trusted DRAM (if available)" > + bool > + > + config TF_A_BL32_TSP_RAM_LOCATION_DRAM > + prompt "Secure DRAM region (configured by TrustZone > controller)" > + bool > +endchoice > + > +config TF_A_BL32_TSP_RAM_LOCATION_STRING > +string > +default "tsram" if TF_A_BL32_TSP_RAM_LOCATION_TSRAM > +default "tdram" if TF_A_BL32_TSP_RAM_LOCATION_TDRAM > +default "dram" if TF_A_BL32_TSP_RAM_LOCATION_DRAM > + > +endif > + > +endif I am missing here a way to pass additional parameters to TF-A (as in TFA_ADDITIONAL_PARAMETERS in Alejandro's version) as there are many other options (some of which may be vendor specific) that are not explicitly defined in the .in file. > diff --git a/rules/tf-a.make b/rules/tf-a.make > new file mode 100644 > index ..9ee554476927 > --- /dev/null > +++ b/rules/tf-a.make > @@ -0,0 +1,123 @@ > +# -*-makefile-*- > +# > +# Copyright (C) 2018 by Rouven Czerwinski > +# 2019 by Ahmad Fatoum > +# > +# See CREDITS for details about who has contributed to this project. > +# > +# For further information about the PTXdist project and license conditions > +# see the README file. > +# > + > +# > +# We provide this package > +# > +PACKAGES-$(PTXCONF_TF_A) += tf-a > + > +# > +# Paths and names > +# > +TF_A_VERSION := $(call remove_quotes,$(PTXCONF_TF_A_VERSION)) > +TF_A_MD5 := $(call remove_quotes,$(PTXCONF_TF_A_MD5)) > +TF_A := tf-a-$(TF_A_VERSION) > +TF_A_SUFFIX:= tar.gz > +TF_A_URL := > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/snapshot/$(TF_A_VERSION).$(TF_A_SUFFIX) > +TF_A_SOURCE:= $(SRCDIR)/$(TF_A).$(TF_A_SUFFIX) > +TF_A_DIR := $(BUILDDIR)/$(TF_A) >
Re: [ptxdist] [PATCH] Weston: Fix compilation for certain DRM targets
El vie., 10 ene. 2020 a las 10:13, Michael Olbrich () escribió: > > On Wed, Jan 08, 2020 at 04:47:47PM +0100, Guillermo Rodríguez wrote: > > If none of LIBDRM_INTEL, LIBDRM_FREEDRENO, or LIBDRM_ETNAVIV is defined, > > the simple-dmabuf-drm Meson option is set to an empty list, which breaks > > compilation. Fix this by setting the option to 'auto' in this case. > > > > Signed-off-by: Guillermo Rodriguez > > --- > > rules/weston.make | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/rules/weston.make b/rules/weston.make > > index eaabebe61..45b9c6ea6 100644 > > --- a/rules/weston.make > > +++ b/rules/weston.make > > @@ -35,6 +35,10 @@ endif > > WESTON_SIMPLE_DMABUF_DRM-$(PTXCONF_WESTON_SIMPLE_DMABUF_DRM_FREEDRENO) += > > freedreno > > WESTON_SIMPLE_DMABUF_DRM-$(PTXCONF_WESTON_SIMPLE_DMABUF_DRM_ETNAVIV) += > > etnaviv > > > > +ifeq ($(WESTON_SIMPLE_DMABUF_DRM-y),) > > +WESTON_SIMPLE_DMABUF_DRM-y := auto > > Hmm, we handle all possible options above, so none should be found with > 'auto', so I think the correct setting here is: > > WESTON_SIMPLE_DMABUF_DRM-y := [] > > To provide an empty list. I am not sure. The error I saw specifically complained about the option being an empty list, so it looks like Meson didn't like that. But the thing is that for some reason I cannot reproduce it anymore. Will see if I can find what the exact problem was. Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] udev-legacy: Fix build with recent glibc versions.
El dom., 12 ene. 2020 a las 13:52, Michael Olbrich () escribió: > > On Tue, Dec 10, 2019 at 07:55:36PM +0100, Guillermo Rodríguez wrote: > > Signed-off-by: Guillermo Rodriguez > > --- > > .../0003-include-sysmacros-for-new-glibc.patch | 17 + > > patches/udev-182/series | 1 + > > 2 files changed, 18 insertions(+) > > create mode 100644 > > patches/udev-182/0003-include-sysmacros-for-new-glibc.patch > > > > diff --git a/patches/udev-182/0003-include-sysmacros-for-new-glibc.patch > > b/patches/udev-182/0003-include-sysmacros-for-new-glibc.patch > > new file mode 100644 > > index 0..b2f8db670 > > --- /dev/null > > +++ b/patches/udev-182/0003-include-sysmacros-for-new-glibc.patch > > @@ -0,0 +1,17 @@ > > +Fix build with recent glibc releases where is no > > +longer included as part of . > > + > > +Ref.: https://wiki.gentoo.org/wiki/Glibc_2.26_porting_notes/sysmacros.h > > + > > +Index: udev-182/src/libudev.h > > +=== > > Please provide a proper patch header. Just recreating the patches with > git[1] should work. I created the patch using quilt as described in the ptxdist documentation (https://www.ptxdist.org/doc/dev_manual.html#using-quilt). If you don't intend to support this workflow, then I think you should cleary state that in the docs. Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] How to express a dependency that can be satisfied by alternative packages
El mar., 7 ene. 2020 a las 12:29, Michael Olbrich () escribió: > > On Tue, Jan 07, 2020 at 12:11:19PM +0100, Guillermo Rodriguez Garcia wrote: > > El jue., 2 ene. 2020 a las 16:15, Michael Olbrich > > () escribió: > > > On Thu, Jan 02, 2020 at 12:53:36PM +0100, Roland Hieber wrote: > > > > On Mon, Dec 16, 2019 at 07:23:13PM +0100, Guillermo Rodriguez Garcia > > > > wrote: > > > > > Let's say I have a package that requires a specific cmd line utility > > > > > (e.g. openvt). > > > > > This can be provided by two different packages (e.g. busybox or kbd) > > > > > How to express that dependency in the .in file of my package ? > > > > > > > > PTXdist (or rather kconfig) does not have a notion of "provides" or > > > > metapackages. I think is currently no way other than making a choice > > > > option that selects the one or the other, or letting your config option > > > > deoend on BUSYBOX_OPENVT || KBD_OPENVT. In the latter case it is > > > > probably good to add a comment above it that depends on the opposite > > > > value notifying the user that neither one of them is selected (see the > > > > comment above IPTABLES_INSTALL_IPTABLES_APPLY in iptables.in for > > > > example). > > > > > > Actually, the correct way to do this is probably: > > > > > > select KBD if !BUSYBOX_OPENVT && RUNTIME > > > select KBD_OPENVT if !BUSYBOX_OPENVT && RUNTIME > > > > What is exactly the meaning of RUNTIME? Why is it needed here? > > This means, that kbd is only needed at runtime and not at buildtime. This > relaxes the build dependencies a bit and allows more parallelization. > It's really only needed for the first line, but we add it to both for > consistency reasons. > > > Apart from that. What about the following: > > > > select KBDif !BUSYBOX > > select KBD_OPENVT if !BUSYBOX > > select BUSYBOX_OPENVT if BUSYBOX && !KBD_OPENVT > > > > This would prefer the Busybox version of openvt if none is explicitly > > selected and Busybox is already present (thus avoiding to pull in the > > kbd package if we can avoid it) > > Does that work? kconfig sometimes produces circular dependency errors, even > if they don't really exist. > If it works, then that's ok too (with the '&& RUNTIME' added). Uhm, indeed Kconfig complains. What would then be the way to achieve this: - If busybox is selected, then select BUSYBOX_OPENVT, unless KBD_OPENVT is already selected - If busybox is NOT selected, then select KBD_OPENVT ? The closest I've got is this: select KBDif !BUSYBOX select KBD_OPENVT if !BUSYBOX select BUSYBOX_OPENVT if BUSYBOX But this will end up selecting both versions of openvt if KBD_OPENVT was already selected... Guillermo -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] How to express a dependency that can be satisfied by alternative packages
El jue., 2 ene. 2020 a las 16:15, Michael Olbrich () escribió: > > Hi, > > On Thu, Jan 02, 2020 at 12:53:36PM +0100, Roland Hieber wrote: > > On Mon, Dec 16, 2019 at 07:23:13PM +0100, Guillermo Rodriguez Garcia wrote: > > > Let's say I have a package that requires a specific cmd line utility > > > (e.g. openvt). > > > This can be provided by two different packages (e.g. busybox or kbd) > > > How to express that dependency in the .in file of my package ? > > > > PTXdist (or rather kconfig) does not have a notion of "provides" or > > metapackages. I think is currently no way other than making a choice > > option that selects the one or the other, or letting your config option > > deoend on BUSYBOX_OPENVT || KBD_OPENVT. In the latter case it is > > probably good to add a comment above it that depends on the opposite > > value notifying the user that neither one of them is selected (see the > > comment above IPTABLES_INSTALL_IPTABLES_APPLY in iptables.in for > > example). > > Actually, the correct way to do this is probably: > > select KBD if !BUSYBOX_OPENVT && RUNTIME > select KBD_OPENVT if !BUSYBOX_OPENVT && RUNTIME What is exactly the meaning of RUNTIME? Why is it needed here? Apart from that. What about the following: select KBDif !BUSYBOX select KBD_OPENVT if !BUSYBOX select BUSYBOX_OPENVT if BUSYBOX && !KBD_OPENVT This would prefer the Busybox version of openvt if none is explicitly selected and Busybox is already present (thus avoiding to pull in the kbd package if we can avoid it) Best, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] weston: Add init script
El lun., 6 ene. 2020 a las 12:18, Michael Olbrich () escribió: > > On Thu, Dec 12, 2019 at 01:54:57PM +0100, Guillermo Rodríguez wrote: > > Signed-off-by: Guillermo Rodriguez > > --- > > Please take a look at how other packages handle this. You'll need a > WESTON_STARTSCRIPT option in weston.in and weston-bbinit.in for the link. I had looked at Avahi. Apparently it is the only package that does it in a different way :-/ Will submit a v2, thank you. Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] How to express a dependency that can be satisfied by alternative packages
Hi all, Let's say I have a package that requires a specific cmd line utility (e.g. openvt). This can be provided by two different packages (e.g. busybox or kbd) How to express that dependency in the .in file of my package ? Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Extra args to mkfs.ubifs with new image creation options
Hello, El vie., 13 dic. 2019 a las 17:14, Ahmad Fatoum () escribió: > > Hi, > > On 12/12/19 7:23 PM, Guillermo Rodriguez Garcia wrote: > > Hi all, > > > > I am trying to switch from the "legacy" ptxdist image creation options > > to the new system based on genimage. This is because I want to > > generate an ubi image out of three separate volumes, and the legacy > > approach does not support this very well. > > > > I am still trying to see how it all works; first issue I have found > > is, how to specify extra arguments to mkfs.ubifs? In particular I need > > to add --space-fixup; however I don't see any place where I could > > configure this with the new system. > > The genimage README documents an extraargs option for > "Extra arguments passed to mkubifs". Would this work for you? Yes. The missing bit is that I was not sure where to add these extraargs. But Alexander's reply already pointed me in the right direction. Thanks, guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Extra args to mkfs.ubifs with new image creation options
Hi Alexander, El jue., 12 dic. 2019 a las 20:14, Alexander Dahl () escribió: > > Hello, > > On Thu, Dec 12, 2019 at 07:23:10PM +0100, Guillermo Rodriguez Garcia wrote: > > I am trying to switch from the "legacy" ptxdist image creation options > > to the new system based on genimage. This is because I want to > > generate an ubi image out of three separate volumes, and the legacy > > approach does not support this very well. > > Did you already find the genimage docs? Look for pengutronix at > GitHub. genimage works with config files, everything is set there. > > > I am still trying to see how it all works; first issue I have found > > is, how to specify extra arguments to mkfs.ubifs? In particular I need > > to add --space-fixup; however I don't see any place where I could > > configure this with the new system. > > ptxdist ships those genimage config files in folder 'config/images' > and you can "overwrite" those in your BSP as you would do with rules. Thanks for the pointers! Now I see how to customize existing configs. What is the proper way to add new targets? For example in my case -- I want to generate a ubi image out of three separate volumes; one of these is the rootfs volume which is already supported out of the box. How to add new targets for the additional volumes, so that ptxdist "notices" they need to be built? BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Extra args to mkfs.ubifs with new image creation options
Hi all, I am trying to switch from the "legacy" ptxdist image creation options to the new system based on genimage. This is because I want to generate an ubi image out of three separate volumes, and the legacy approach does not support this very well. I am still trying to see how it all works; first issue I have found is, how to specify extra arguments to mkfs.ubifs? In particular I need to add --space-fixup; however I don't see any place where I could configure this with the new system. Any hints? Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] How to override files from another package
Hi Robert, El jue., 28 nov. 2019 a las 7:39, Robert Schwebel () escribió: > > On Wed, Nov 27, 2019 at 10:22:04AM +0100, Guillermo Rodriguez Garcia wrote: > > > It's not possible. What exactly are you trying to achieve? Which files do > > > you want to overwrite? > > > > As in the post from the ML above -- I am trying to overwrite the > > generic GL libraries provided by Mesa and replace them with > > vendor-provided binaries. > > You don't want to do that. Etnaviv supports your GPU just fine :-) I don't know. I started a discussion about this with someone some time ago; we were talking about this and other topics (upstream vs vendor kernel, u-boot vs barebox, vendor GPU drivers vs etnaviv, NAND vs eMMC...) but then I suddenly stopped getting answers :-) BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] How to override files from another package
El mié., 27 nov. 2019 a las 10:38, Michael Olbrich () escribió: > > On Wed, Nov 27, 2019 at 10:22:04AM +0100, Guillermo Rodriguez Garcia wrote: > > El mié., 27 nov. 2019 a las 10:06, Michael Olbrich > > () escribió: > > > On Tue, Nov 26, 2019 at 07:21:32PM +0100, Guillermo Rodriguez Garcia > > > wrote: > > > > Is there a way for a ptxdist package to override files from another > > > > package? > > > > For example something similar to this: > > > > > > > > https://lists.linaro.org/pipermail/openembedded/2016-June/31.html > > > > > > > > I tried to create a package which depends on MESALIB (so that > > > > mesalib's targetinstall rule runs first), and then simply overwrite > > > > the files, but this fails when the package is generated, because there > > > > are multiple packages trying to provide the same files. > > > > > > It's not possible. What exactly are you trying to achieve? Which files do > > > you want to overwrite? > > > > As in the post from the ML above -- I am trying to overwrite the > > generic GL libraries provided by Mesa and replace them with > > vendor-provided binaries. > > Then you should not install mesa at all. Not all libraries are replaced. Also mesa is selected by other packages (such as weston), so if I wanted to skip mesa I would need to patch those as well.. BR; Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] How to override files from another package
Hi, El mié., 27 nov. 2019 a las 10:38, Ladislav Michl () escribió: > > On Wed, Nov 27, 2019 at 10:22:04AM +0100, Guillermo Rodriguez Garcia wrote: > > Hi, > > > > El mié., 27 nov. 2019 a las 10:06, Michael Olbrich > > () escribió: > > > > > > Hi, > > > > > > On Tue, Nov 26, 2019 at 07:21:32PM +0100, Guillermo Rodriguez Garcia > > > wrote: > > > > Is there a way for a ptxdist package to override files from another > > > > package? > > > > For example something similar to this: > > > > > > > > https://lists.linaro.org/pipermail/openembedded/2016-June/31.html > > > > > > > > I tried to create a package which depends on MESALIB (so that > > > > mesalib's targetinstall rule runs first), and then simply overwrite > > > > the files, but this fails when the package is generated, because there > > > > are multiple packages trying to provide the same files. > > > > > > It's not possible. What exactly are you trying to achieve? Which files do > > > you want to overwrite? > > > > As in the post from the ML above -- I am trying to overwrite the > > generic GL libraries provided by Mesa and replace them with > > vendor-provided binaries. > > A quick way is to copy mesa rules into your BSP and modify them not to copy > libraries you are not interested in to the target. Yes, that's what I am doing now. I was just wondering if there is a cleaner way. Thanks! Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] How to override files from another package
Hi, El mié., 27 nov. 2019 a las 10:06, Michael Olbrich () escribió: > > Hi, > > On Tue, Nov 26, 2019 at 07:21:32PM +0100, Guillermo Rodriguez Garcia wrote: > > Is there a way for a ptxdist package to override files from another package? > > For example something similar to this: > > > > https://lists.linaro.org/pipermail/openembedded/2016-June/31.html > > > > I tried to create a package which depends on MESALIB (so that > > mesalib's targetinstall rule runs first), and then simply overwrite > > the files, but this fails when the package is generated, because there > > are multiple packages trying to provide the same files. > > It's not possible. What exactly are you trying to achieve? Which files do > you want to overwrite? As in the post from the ML above -- I am trying to overwrite the generic GL libraries provided by Mesa and replace them with vendor-provided binaries. Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] How to override files from another package
Hi all, Is there a way for a ptxdist package to override files from another package? For example something similar to this: https://lists.linaro.org/pipermail/openembedded/2016-June/31.html I tried to create a package which depends on MESALIB (so that mesalib's targetinstall rule runs first), and then simply overwrite the files, but this fails when the package is generated, because there are multiple packages trying to provide the same files. BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Toolchain for STM32MP15x
Hi all, I have setup the toolchain with the settings from my previous email (-mcpu=cortex-a7 -mfpu=neon-vfpv4) When I try to build the Linux kernel I get lots of warnings about conflicting toolchain options: arch/arm/kernel/elf.c:1:0: warning: switch -mcpu=cortex-a7 conflicts with -march=armv5t switch This is with OSELAS.Toolchain-2016.06.1, using arm-v7a-linux-gnueabihf. I am not sure where the -march=armv5t is coming from, since this is an arm-v7a toolchain. Also if I use -mcpu=cortex-a9 instead of cortex-a7, there are no warnings :-? Can anyone sehd some light ? Thank you, Guillermo El lun., 25 nov. 2019 a las 13:33, Guillermo Rodriguez Garcia () escribió: > > Hi all, > > I am trying to setup a toolchain for the STM32MP15x. The main CPU is a > single or dual (depending on p/n) Cortex-A7, supporting NEON and > VFPv4. > > I'm using the OSELAS arm-v7a-linux-gnueabihf toolchain. As for the > extra flags I believe I should use -mcpu=cortex-a7 -mfpu=neon-vfpv4. > > Does this look correct? Any comments / hints? > > BR, > > Guillermo Rodriguez Garcia > guille.rodrig...@gmail.com -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Toolchain for STM32MP15x
Hi all, I am trying to setup a toolchain for the STM32MP15x. The main CPU is a single or dual (depending on p/n) Cortex-A7, supporting NEON and VFPv4. I'm using the OSELAS arm-v7a-linux-gnueabihf toolchain. As for the extra flags I believe I should use -mcpu=cortex-a7 -mfpu=neon-vfpv4. Does this look correct? Any comments / hints? BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] python3-pycparser: New package
Hi Michael, El lun., 25 nov. 2019 a las 8:04, Michael Olbrich () escribió: > > On Thu, Nov 21, 2019 at 10:17:05AM +0100, Guillermo Rodríguez wrote: > > pycparser is a complete parser of the C language, written in pure > > Python using the PLY parsing library. It parses C code into an AST > > and can serve as a front-end for C compilers or analysis tools. > > > > Guillermo Rodriguez > > --- > > rules/python3-pycparser.in | 10 +++ > > rules/python3-pycparser.make | 54 > > 2 files changed, 64 insertions(+) > > create mode 100644 rules/python3-pycparser.in > > create mode 100644 rules/python3-pycparser.make > > > > diff --git a/rules/python3-pycparser.in b/rules/python3-pycparser.in > > new file mode 100644 > > index 0..07cd9960e > > --- /dev/null > > +++ b/rules/python3-pycparser.in > > @@ -0,0 +1,10 @@ > > +## SECTION=python3 > > + > > +config PYTHON3_PYCPARSER > > + tristate > > + select PYTHON3 > > + prompt "python3-pycparser" > > + help > > + pycparser is a complete parser of the C language, written in pure > > + Python using the PLY parsing library. It parses C code into an AST > > + and can serve as a front-end for C compilers or analysis tools. > > diff --git a/rules/python3-pycparser.make b/rules/python3-pycparser.make > > new file mode 100644 > > index 0..8ef168299 > > --- /dev/null > > +++ b/rules/python3-pycparser.make > > @@ -0,0 +1,54 @@ > > +# -*-makefile-*- > > +# > > +# Copyright (C) 2019 by Guillermo Rodriguez > > +# > > +# For further information about the PTXdist project and license conditions > > +# see the README file. > > +# > > + > > +# > > +# We provide this package > > +# > > +PACKAGES-$(PTXCONF_PYTHON3_PYCPARSER) += python3-pycparser > > + > > +# > > +# Paths and names > > +# > > +PYTHON3_PYCPARSER_VERSION:= 2.18 > > +PYTHON3_PYCPARSER_MD5:= 72370da54358202a60130e223d488136 > > +PYTHON3_PYCPARSER:= pycparser-$(PYTHON3_PYCPARSER_VERSION) > > +PYTHON3_PYCPARSER_SUFFIX := tar.gz > > +PYTHON3_PYCPARSER_URL:= > > https://pypi.python.org/packages/source/p/pycparser/$(PYTHON3_PYCPARSER).$(PYTHON3_PYCPARSER_SUFFIX) > > +PYTHON3_PYCPARSER_SOURCE := > > $(SRCDIR)/$(PYTHON3_PYCPARSER).$(PYTHON3_PYCPARSER_SUFFIX) > > +PYTHON3_PYCPARSER_DIR:= $(BUILDDIR)/$(PYTHON3_PYCPARSER) > > +PYTHON3_PYCPARSER_LICENSE:= BSD > > This is not an SPDX license identifier. Which BSD license is this supposed > to be? This seems to be BSD-3-Clause. Shall I resend or will you fix that up? Guillermo > > Michael > > > +PYTHON3_PYCPARSER_LICENSE_FILES := \ > > + file://LICENSE;md5=86f1cedb4e6410a88ce8e30b91079169 > > + > > +# > > > > +# Prepare > > +# > > > > + > > +PYTHON3_PYCPARSER_CONF_TOOL := python3 > > + > > +# > > > > +# Target-Install > > +# > > > > + > > +$(STATEDIR)/python3-pycparser.targetinstall: > > + @$(call targetinfo) > > + > > + @$(call install_init, python3-pycparser) > > + @$(call install_fixup, python3-pycparser, PRIORITY, optional) > > + @$(call install_fixup, python3-pycparser, SECTION, base) > > + @$(call install_fixup, python3-pycparser, AUTHOR, "Guillermo > > Rodriguez ") > > + @$(call install_fixup, python3-pycparser, DESCRIPTION, missing) > > + > > + @$(call install_glob, python3-pycparser, 0, 0, -, \ > > + > > /usr/lib/python$(PYTHON3_MAJORMINOR)/site-packages/pycparser,, *.py) > > + > > + @$(call install_finish, python3-pycparser) > > + > > + @$(call touch) > > + > > +# vim: syntax=make > > -- > > 2.21.0 > > > > > > ___ > > ptxdist mailing list > > ptxdist@pengutronix.de > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > > ___ > ptxdist mailing list > ptxdist@pengutronix.de -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v7] python3-numpy: New package
does this refer to? > No need to resent it, I can do a fixup, but I need to know what to change. Not sure anymore, perhaps that's a leftover from a previous version of the patch (since I switched from 1.16.1 to 1.17.4, and some licenses have changed). I rechecked everything from scratch and I see the following: - Main numpy license is BSD-3-Clause. License text is here: https://github.com/numpy/numpy/blob/master/LICENSE.txt - According to https://github.com/numpy/numpy/blob/master/LICENSES_bundled.txt, the following additional licenses apply to certain bundled components: Name: lapack-lite Files: numpy/linalg/lapack_lite/* License: 3-clause BSD For details, see numpy/linalg/lapack_lite/LICENSE.txt -> So 3-clause BSD again Name: tempita Files: tools/npy_tempita/* License: BSD derived For details, see tools/npy_tempita/license.txt -> Despite the comment, this is actually the MIT license; see: https://github.com/numpy/numpy/blob/master/tools/npy_tempita/license.txt Name: dragon4 Files: numpy/core/src/multiarray/dragon4.c License: MIT For license text, see numpy/core/src/multiarray/dragon4.c -> MIT license again So I'd say that PYTHON3_NUMPY_LICENSE can be just "BSD-3-Clause AND MIT" Guillermo > > Michael > > > +PYTHON3_NUMPY_LICENSE_FILES := \ > > + file://LICENSE.txt;md5=1a32aba007a415aa8a1c708a0e2b86a1 \ > > + > > file://tools/npy_tempita/license.txt;md5=c66b85ddcd09296abff87601467724fd \ > > + > > file://numpy/core/src/multiarray/dragon4.c;startline=2;endline=20;md5=7f70862b43e17922c5adf18ec84fb720 > > + > > + > > +# > > > > +# Prepare > > +# > > > > + > > +PYTHON3_NUMPY_CONF_TOOL := python3 > > + > > +# > > > > +# Target-Install > > +# > > > > + > > +$(STATEDIR)/python3-numpy.targetinstall: > > + @$(call targetinfo) > > + > > + @$(call install_init, python3-numpy) > > + @$(call install_fixup, python3-numpy, PRIORITY, optional) > > + @$(call install_fixup, python3-numpy, SECTION, base) > > + @$(call install_fixup, python3-numpy, AUTHOR, "Guillermo Rodriguez > > ") > > + @$(call install_fixup, python3-numpy, DESCRIPTION, missing) > > + > > + @$(call install_glob, python3-numpy, 0, 0, -, \ > > + /usr/lib/python$(PYTHON3_MAJORMINOR)/site-packages/numpy,, > > *.py) > > + > > + @$(call install_finish, python3-numpy) > > + > > + @$(call touch) > > + > > +# vim: syntax=make > > -- > > 2.21.0 > > > > > > ___ > > ptxdist mailing list > > ptxdist@pengutronix.de > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > > ___ > ptxdist mailing list > ptxdist@pengutronix.de -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] python3-cffi: New package
El vie., 22 nov. 2019 a las 15:22, Michael Olbrich () escribió: > > On Thu, Nov 21, 2019 at 10:15:57AM +0100, Guillermo Rodríguez wrote: > > Foreign Function Interface for Python calling C code. > > > > Signed-off-by: Guillermo Rodriguez > > --- > > rules/python3-cffi.in | 8 ++ > > rules/python3-cffi.make | 56 + > > 2 files changed, 64 insertions(+) > > create mode 100644 rules/python3-cffi.in > > create mode 100644 rules/python3-cffi.make > > > > diff --git a/rules/python3-cffi.in b/rules/python3-cffi.in > > new file mode 100644 > > index 0..5b30de6d3 > > --- /dev/null > > +++ b/rules/python3-cffi.in > > @@ -0,0 +1,8 @@ > > +## SECTION=python3 > > + > > +config PYTHON3_CFFI > > + tristate > > + select PYTHON3 > > + prompt "python3-ccfi" > > + help > > + Foreign Function Interface for Python calling C code. > > diff --git a/rules/python3-cffi.make b/rules/python3-cffi.make > > new file mode 100644 > > index 0..5c6524d2c > > --- /dev/null > > +++ b/rules/python3-cffi.make > > @@ -0,0 +1,56 @@ > > +# -*-makefile-*- > > +# > > +# Copyright (C) 2019 by Guillermo Rodriguez > > +# > > +# For further information about the PTXdist project and license conditions > > +# see the README file. > > +# > > + > > +# > > +# We provide this package > > +# > > +PACKAGES-$(PTXCONF_PYTHON3_CFFI) += python3-cffi > > + > > +# > > +# Paths and names > > +# > > +PYTHON3_CFFI_VERSION := 1.13.2 > > +PYTHON3_CFFI_MD5 := 652203cf99faa254efff7fab23c2f3a2 > > +PYTHON3_CFFI := cffi-$(PYTHON3_CFFI_VERSION) > > +PYTHON3_CFFI_SUFFIX := tar.gz > > +PYTHON3_CFFI_URL := > > https://pypi.python.org/packages/source/c/cffi/$(PYTHON3_CFFI).$(PYTHON3_CFFI_SUFFIX) > > +PYTHON3_CFFI_SOURCE := $(SRCDIR)/$(PYTHON3_CFFI).$(PYTHON3_CFFI_SUFFIX) > > +PYTHON3_CFFI_DIR := $(BUILDDIR)/$(PYTHON3_CFFI) > > +PYTHON3_CFFI_LICENSE := MIT > > +PYTHON3_CFFI_LICENSE_FILES := \ > > + file://LICENSE;md5=5677e2fdbf7cdda61d6dd2b57df547bf > > Trailing Whitespace. > > > + > > +# > > > > +# Prepare > > +# > > > > + > > +PYTHON3_CFFI_CONF_TOOL := python3 > > + > > +# > > > > +# Target-Install > > +# > > > > + > > +$(STATEDIR)/python3-cffi.targetinstall: > > + @$(call targetinfo) > > + > > + @$(call install_init, python3-cffi) > > + @$(call install_fixup, python3-cffi, PRIORITY, optional) > > + @$(call install_fixup, python3-cffi, SECTION, base) > > + @$(call install_fixup, python3-cffi, AUTHOR, "Guillermo Rodriguez > > ") > > + @$(call install_fixup, python3-cffi, DESCRIPTION, missing) > > + > > + @$(call install_glob, python3-cffi, 0, 0, -, \ > > + /usr/lib/python$(PYTHON3_MAJORMINOR)/site-packages,, *.py *.h) > > I think this should be: > > /usr/lib/python$(PYTHON3_MAJORMINOR)/site-packages/cffi,, > *.py *.h) > > Otherwise the egg-info stuff is installed, and I'm pretty sure that's not > needed, right? Right. This is fixed in v2 already. Will take care of whitespace and resend. Guillermo > > > + > > Trailing Whitespace. > > Michael > > > + @$(call install_lib, python3-cffi, 0, 0, 0644, > > python$(PYTHON3_MAJORMINOR)/site-packages/_cffi_backend.cpython*) > > + > > + @$(call install_finish, python3-cffi) > > + > > + @$(call touch) > > + > > +# vim: syntax=make > > -- > > 2.21.0 > > > > > > ___ > > ptxdist mailing list > > ptxdist@pengutronix.de > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] python3-numpy: New package
El mar., 19 nov. 2019 a las 10:23, Michael Olbrich () escribió: > > Hi, > > On Tue, Nov 19, 2019 at 10:10:09AM +0100, Guillermo Rodriguez Garcia wrote: > > El vie., 15 nov. 2019 a las 21:11, Guillermo Rodriguez Garcia > > () escribió: > > > El viernes, 15 de noviembre de 2019, Michael Olbrich > > > escribió: > > >> On Fri, Nov 15, 2019 at 09:51:25AM +0100, Guillermo Rodríguez wrote: > > >> > NumPy is the fundamental package for scientific computing with Python. > > >> > > > >> > Signed-off-by: Guillermo Rodriguez > > >> > --- > > >> > v2: Switch to PyPi URL; this removes the dependency on Cython. > > >> > v3: Update LICENSE, add LICENSE_FILES > > >> > v4: Update LICENSE and LICENSE_FILES with additional licenses > > >> > v5: Removed "unknown" from LICENSE > > >> > v6: Updated to 1.17.4, added patch to fix cross compilation > > >> > > > >> > .../numpy-1.17.4/0001-remove-sse2-flag.patch | 21 +++ > > >> > patches/numpy-1.17.4/series | 1 + > > >> > rules/python3-numpy.in| 10 > > >> > rules/python3-numpy.make | 57 +++ > > >> > 4 files changed, 89 insertions(+) > > >> > create mode 100644 patches/numpy-1.17.4/0001-remove-sse2-flag.patch > > >> > create mode 100644 patches/numpy-1.17.4/series > > >> > create mode 100644 rules/python3-numpy.in > > >> > create mode 100644 rules/python3-numpy.make > > >> > > > >> > diff --git a/patches/numpy-1.17.4/0001-remove-sse2-flag.patch > > >> > b/patches/numpy-1.17.4/0001-remove-sse2-flag.patch > > >> > new file mode 100644 > > >> > index 0..e1cb0d878 > > >> > --- /dev/null > > >> > +++ b/patches/numpy-1.17.4/0001-remove-sse2-flag.patch > > >> > @@ -0,0 +1,21 @@ > > >> > +Fix cross-compilation for non-Intel targets. > > >> > +See: https://github.com/numpy/numpy/issues/14861 > > >> > + > > >> > +--- > > >> > > >> Please create a proper patch header. > > >> > > >> > > > > > > Can you please let me know what is wrong specifically? The patch was > > > generated by quilt and I just added the comment in the first two lines. > > > > > > I'd prefer to fix whatever is wrong in the patch header rather than > > > regenerate the patch using a different method. > > > > Waiting for feedback on this one in order to generate a new version > > that would fix the patch header and remove the explicit > > HOST_PYTHON3_SETUPTOOLS dependency. > > In general, I'd like to see the From:, Date:, Subject: headers created by > git. In this specific case, now that it is fixed upstream, I prefer the > exact patch from upstream The exact patch from upstream does not apply cleanly, that's why I regenerated it. > (including these headers) and with an added > comment, that it's ab backport from upstream. That helps when the packages > is updated to a new version. OK. Guillermo > > Michael > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > > ___ > ptxdist mailing list > ptxdist@pengutronix.de -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] python3-numpy: New package
Hi Michael, El vie., 15 nov. 2019 a las 21:11, Guillermo Rodriguez Garcia () escribió: > > Hi Michael, > > El viernes, 15 de noviembre de 2019, Michael Olbrich > escribió: >> >> On Fri, Nov 15, 2019 at 09:51:25AM +0100, Guillermo Rodríguez wrote: >> > NumPy is the fundamental package for scientific computing with Python. >> > >> > Signed-off-by: Guillermo Rodriguez >> > --- >> > v2: Switch to PyPi URL; this removes the dependency on Cython. >> > v3: Update LICENSE, add LICENSE_FILES >> > v4: Update LICENSE and LICENSE_FILES with additional licenses >> > v5: Removed "unknown" from LICENSE >> > v6: Updated to 1.17.4, added patch to fix cross compilation >> > >> > .../numpy-1.17.4/0001-remove-sse2-flag.patch | 21 +++ >> > patches/numpy-1.17.4/series | 1 + >> > rules/python3-numpy.in| 10 >> > rules/python3-numpy.make | 57 +++ >> > 4 files changed, 89 insertions(+) >> > create mode 100644 patches/numpy-1.17.4/0001-remove-sse2-flag.patch >> > create mode 100644 patches/numpy-1.17.4/series >> > create mode 100644 rules/python3-numpy.in >> > create mode 100644 rules/python3-numpy.make >> > >> > diff --git a/patches/numpy-1.17.4/0001-remove-sse2-flag.patch >> > b/patches/numpy-1.17.4/0001-remove-sse2-flag.patch >> > new file mode 100644 >> > index 0..e1cb0d878 >> > --- /dev/null >> > +++ b/patches/numpy-1.17.4/0001-remove-sse2-flag.patch >> > @@ -0,0 +1,21 @@ >> > +Fix cross-compilation for non-Intel targets. >> > +See: https://github.com/numpy/numpy/issues/14861 >> > + >> > +--- >> >> Please create a proper patch header. >> >> > > Can you please let me know what is wrong specifically? The patch was > generated by quilt and I just added the comment in the first two lines. > > I'd prefer to fix whatever is wrong in the patch header rather than > regenerate the patch using a different method. Waiting for feedback on this one in order to generate a new version that would fix the patch header and remove the explicit HOST_PYTHON3_SETUPTOOLS dependency. BR, Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] host-python3-cython: New package
Hi Michael, El vie., 15 nov. 2019 a las 14:46, Michael Olbrich (< m.olbr...@pengutronix.de>) escribió: > On Mon, Nov 11, 2019 at 04:11:59PM +0100, Guillermo Rodríguez wrote: > > Cython is an optimising static compiler for both the Python > > programming language and the extended Cython programming language > > (based on Pyrex). > > We already have host-cython3. I think that's the same, right? > Right. I had missed that. > So do a version bump instead? > Done. -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] python3-numpy: New package
_NUMPY_SUFFIX := zip > > +PYTHON3_NUMPY_URL:= https://pypi.python.org/ > packages/source/n/numpy/$(PYTHON3_NUMPY).$(PYTHON3_NUMPY_SUFFIX) > > +PYTHON3_NUMPY_SOURCE := $(SRCDIR)/$(PYTHON3_NUMPY).$( > PYTHON3_NUMPY_SUFFIX) > > +PYTHON3_NUMPY_DIR:= $(BUILDDIR)/$(PYTHON3_NUMPY) > > +PYTHON3_NUMPY_LICENSE:= BSD AND BSD-3-Clause AND MIT > > +PYTHON3_NUMPY_LICENSE_FILES := \ > > + file://LICENSE.txt;md5=1a32aba007a415aa8a1c708a0e2b86a1 \ > > + file://tools/npy_tempita/license.txt;md5= > c66b85ddcd09296abff87601467724fd \ > > + file://numpy/core/src/multiarray/dragon4.c; > startline=2;endline=20;md5=7f70862b43e17922c5adf18ec84fb720 > > + > > + > > +# > > > +# Prepare > > +# > > > + > > +PYTHON3_NUMPY_CONF_TOOL := python3 > > + > > +# > > > +# Target-Install > > +# > > > + > > +$(STATEDIR)/python3-numpy.targetinstall: > > + @$(call targetinfo) > > + > > + @$(call install_init, python3-numpy) > > + @$(call install_fixup, python3-numpy, PRIORITY, optional) > > + @$(call install_fixup, python3-numpy, SECTION, base) > > + @$(call install_fixup, python3-numpy, AUTHOR, "Guillermo Rodriguez > ") > > + @$(call install_fixup, python3-numpy, DESCRIPTION, missing) > > + > > + @$(call install_glob, python3-numpy, 0, 0, -, \ > > + /usr/lib/python$(PYTHON3_MAJORMINOR)/site-packages/numpy,, > *.py) > > + > > + @$(call install_finish, python3-numpy) > > + > > + @$(call touch) > > + > > +# vim: syntax=make > > -- > > 2.21.0 > > > > > > ___ > > ptxdist mailing list > > ptxdist@pengutronix.de > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v3] python3-numpy: New package
El jue., 14 nov. 2019 a las 12:18, Roland Hieber () escribió: > On Thu, Nov 14, 2019 at 11:07:16AM +0100, Guillermo Rodriguez Garcia wrote: > > El jue., 14 nov. 2019 a las 10:56, Roland Hieber () > > escribió: > > > > > > > numpy/core/src/multiarray/dragon4.c seems to be a license found > nowhere > > > > > else, so I would also add "AND UNKNOWN" to PYTHON3_NUMPY_LICENSE > and > > > add > > > > > its verbatim license text with startline and endline parameters in > > > > > PYTHON3_NUMPY_LICENSE_FILES. PTXdist extracts all those license > > > > > texts mentioned in that variable and adds them to the license > report, > > > > > so it doesn't get lost too :) > > > > > > > On re-reading this: The license in dragon4.c is just MIT. So while it is > OK > > to add it to LICENSE_FILES I think we should not add the "AND unknown" > bit. > > Oh. I just blindly believed LICENSE.txt. But now that you say it, my > license matcher identifies it as "Zlib", not as "MIT". > Uhm, doesn't look like Zlib to me; here's the license text extracted from dragon4.c: /* * Copyright (c) 2014 Ryan Juckett * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to * deal in the Software without restriction, including without limitation the * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or * sell copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS * IN THE SOFTWARE. */ And here are the MIT and Zlib licenses: https://spdx.org/licenses/MIT.html https://spdx.org/licenses/Zlib.html I would say that the license is indeed MIT, which is what LICENSE.txt says: Name: dragon4 Files: numpy/core/src/multiarray/dragon4.c License: MIT For license text, see numpy/core/src/multiarray/dragon4.c BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v3] python3-numpy: New package
El jue., 14 nov. 2019 a las 10:56, Roland Hieber () escribió: > On Thu, Nov 14, 2019 at 10:36:56AM +0100, Guillermo Rodriguez Garcia wrote: > > Hi Roland, > > > > El mié., 13 nov. 2019 a las 10:36, Roland Hieber () > > escribió: > > > > > On Tue, Nov 12, 2019 at 12:51:03PM +0100, Guillermo Rodríguez wrote: > > > > NumPy is the fundamental package for scientific computing with > Python. > > > > > > > > Signed-off-by: Guillermo Rodriguez > > > > --- > > > > v2: Switch to PyPi URL; this removes the dependency on Cython. > > > > v3: Update LICENSE, add LICENSE_FILES > > > > > > > > rules/python3-numpy.in | 10 > > > > rules/python3-numpy.make | 54 > > > > > 2 files changed, 64 insertions(+) > > > > create mode 100644 rules/python3-numpy.in > > > > create mode 100644 rules/python3-numpy.make > > > > > > > > diff --git a/rules/python3-numpy.in b/rules/python3-numpy.in > > > > new file mode 100644 > > > > index 0..1440e409a > > > > --- /dev/null > > > > +++ b/rules/python3-numpy.in > > > > @@ -0,0 +1,10 @@ > > > > +## SECTION=python3 > > > > + > > > > +config PYTHON3_NUMPY > > > > + tristate > > > > + select PYTHON3 > > > > + select HOST_PYTHON3_SETUPTOOLS > > > > + prompt "python3-numpy" > > > > + help > > > > + NumPy is the fundamental package for scientific computing > with > > > > + Python. > > > > diff --git a/rules/python3-numpy.make b/rules/python3-numpy.make > > > > new file mode 100644 > > > > index 0..40cc351d3 > > > > --- /dev/null > > > > +++ b/rules/python3-numpy.make > > > > @@ -0,0 +1,54 @@ > > > > +# -*-makefile-*- > > > > +# > > > > +# Copyright (C) 2019 by Guillermo Rodriguez < > guille.rodrig...@gmail.com > > > > > > > > +# > > > > +# For further information about the PTXdist project and license > > > conditions > > > > +# see the README file. > > > > +# > > > > + > > > > +# > > > > +# We provide this package > > > > +# > > > > +PACKAGES-$(PTXCONF_PYTHON3_NUMPY) += python3-numpy > > > > + > > > > +# > > > > +# Paths and names > > > > +# > > > > +PYTHON3_NUMPY_VERSION:= 1.16.1 > > > > +PYTHON3_NUMPY_MD5:= dafda51934f645d66f98424521ae > > > > +PYTHON3_NUMPY:= numpy-$(PYTHON3_NUMPY_VERSION) > > > > +PYTHON3_NUMPY_SUFFIX := zip > > > > +PYTHON3_NUMPY_URL:= > > > > https://pypi.python.org/packages/source/n/numpy/$(PYTHON3_NUMPY).$(PYTHON3_NUMPY_SUFFIX) > > > > +PYTHON3_NUMPY_SOURCE := > > > $(SRCDIR)/$(PYTHON3_NUMPY).$(PYTHON3_NUMPY_SUFFIX) > > > > +PYTHON3_NUMPY_DIR:= $(BUILDDIR)/$(PYTHON3_NUMPY) > > > > +PYTHON3_NUMPY_LICENSE:= BSD AND BSD-3-Clause AND MIT > > > > > > AND Apache-2.0, according to LICENSE.txt. > > > > > > I assume you mean LICENSES_bundled.txt and not LICENSE.txt > > I don't have a LICENSES_bundled.txt in the extracted zip file with that > MD5sum from that URL... > Right, sorry. The tarball combines the LICENSE.txt and LICENSES_bundled.txt files from the Github repo into one single LICENSE.txt file. I mixed them up. Guillermo > > > If I am reading that correctly, the Apache license only applies to the > > Sphinx theme. Since we are not bundling any documentation, I assume we > can > > ignore this one. > > OK. That was not clear to me. > > - Roland > > > > > > > > I would also add all the other > > > license files mentioned therein so we notice when they change or > vanish. > > > > > > The Python-2.0 license in doc/scipy-sphinx-theme/LICENSE.txt is > > > currently not available as an SPDX identifier, so I would leave this as > > > "AND UNKNOWN", and wait until the respective SPDX issue is resolved... > > > https://github.com/spdx/license-list-XML/issues/919 > > > > > > Same as above, this only applies to the Sphinx theme, so I assume we can > > ignore this. > > > > > > > > > > > > > numpy/core/src/multiarray/dragon4.c seems to be a license found nowhere > > > else, so I woul
Re: [ptxdist] [PATCH v3] python3-numpy: New package
Hi Roland, El mié., 13 nov. 2019 a las 10:36, Roland Hieber () escribió: > On Tue, Nov 12, 2019 at 12:51:03PM +0100, Guillermo Rodríguez wrote: > > NumPy is the fundamental package for scientific computing with Python. > > > > Signed-off-by: Guillermo Rodriguez > > --- > > v2: Switch to PyPi URL; this removes the dependency on Cython. > > v3: Update LICENSE, add LICENSE_FILES > > > > rules/python3-numpy.in | 10 > > rules/python3-numpy.make | 54 > > 2 files changed, 64 insertions(+) > > create mode 100644 rules/python3-numpy.in > > create mode 100644 rules/python3-numpy.make > > > > diff --git a/rules/python3-numpy.in b/rules/python3-numpy.in > > new file mode 100644 > > index 0..1440e409a > > --- /dev/null > > +++ b/rules/python3-numpy.in > > @@ -0,0 +1,10 @@ > > +## SECTION=python3 > > + > > +config PYTHON3_NUMPY > > + tristate > > + select PYTHON3 > > + select HOST_PYTHON3_SETUPTOOLS > > + prompt "python3-numpy" > > + help > > + NumPy is the fundamental package for scientific computing with > > + Python. > > diff --git a/rules/python3-numpy.make b/rules/python3-numpy.make > > new file mode 100644 > > index 0..40cc351d3 > > --- /dev/null > > +++ b/rules/python3-numpy.make > > @@ -0,0 +1,54 @@ > > +# -*-makefile-*- > > +# > > +# Copyright (C) 2019 by Guillermo Rodriguez > > > +# > > +# For further information about the PTXdist project and license > conditions > > +# see the README file. > > +# > > + > > +# > > +# We provide this package > > +# > > +PACKAGES-$(PTXCONF_PYTHON3_NUMPY) += python3-numpy > > + > > +# > > +# Paths and names > > +# > > +PYTHON3_NUMPY_VERSION:= 1.16.1 > > +PYTHON3_NUMPY_MD5:= dafda51934f645d66f98424521ae > > +PYTHON3_NUMPY:= numpy-$(PYTHON3_NUMPY_VERSION) > > +PYTHON3_NUMPY_SUFFIX := zip > > +PYTHON3_NUMPY_URL:= > https://pypi.python.org/packages/source/n/numpy/$(PYTHON3_NUMPY).$(PYTHON3_NUMPY_SUFFIX) > > +PYTHON3_NUMPY_SOURCE := > $(SRCDIR)/$(PYTHON3_NUMPY).$(PYTHON3_NUMPY_SUFFIX) > > +PYTHON3_NUMPY_DIR:= $(BUILDDIR)/$(PYTHON3_NUMPY) > > +PYTHON3_NUMPY_LICENSE:= BSD AND BSD-3-Clause AND MIT > > AND Apache-2.0, according to LICENSE.txt. I assume you mean LICENSES_bundled.txt and not LICENSE.txt If I am reading that correctly, the Apache license only applies to the Sphinx theme. Since we are not bundling any documentation, I assume we can ignore this one. > I would also add all the other > license files mentioned therein so we notice when they change or vanish. > > The Python-2.0 license in doc/scipy-sphinx-theme/LICENSE.txt is > currently not available as an SPDX identifier, so I would leave this as > "AND UNKNOWN", and wait until the respective SPDX issue is resolved... > https://github.com/spdx/license-list-XML/issues/919 Same as above, this only applies to the Sphinx theme, so I assume we can ignore this. > > > numpy/core/src/multiarray/dragon4.c seems to be a license found nowhere > else, so I would also add "AND UNKNOWN" to PYTHON3_NUMPY_LICENSE and add > its verbatim license text with startline and endline parameters in > PYTHON3_NUMPY_LICENSE_FILES. PTXdist extracts all those license > texts mentioned in that variable and adds them to the license report, > so it doesn't get lost too :) > OK. > > > +PYTHON3_NUMPY_LICENSE_FILES := \ > > + file://LICENSE.txt;md5=d26bde5432613cce2334b93985576231 > > > file://doc/sphinxext/LICENSE.txt;md5=dc37e8b18377b83250218fc557984e1a \ > > file://doc/scipy-sphinx-theme/LICENSE.txt;md5=ea17c9a65c9ae0ccdf3b0a7fd1ee4616 > \ > > file://tools/npy_tempita/license.txt;md5=c66b85ddcd09296abff87601467724fd \ > > file://numpy/core/src/multiarray/dragon4.c;startline=2;endline=22;md5=19537439573c5696a922ed7957c5b37e > \ > > (numpy/linalg/lapack_lite/LICENSE.txt is currently missing in the > tarball, see https://github.com/numpy/numpy/issues/13295) > > For reference, that last one can be generated with a > > sed -n 2,22p < inputfilename | md5sum > > Please check if all of this (especially the MD5s) make sense to you :) > Yes. Will double check and submit a new version of the patch. Thank you! Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] python3-numpy: New package
Hi Roland, El mar., 12 nov. 2019 a las 10:51, Roland Hieber () escribió: [...] > > +PYTHON3_NUMPY_VERSION:= 1.16.1 > > +PYTHON3_NUMPY_MD5:= bddcc682669b4be438db5eab61aa39b5 > > +PYTHON3_NUMPY:= Numpy-$(PYTHON3_NUMPY_VERSION) > > +PYTHON3_NUMPY_SUFFIX := tar.gz > > +PYTHON3_NUMPY_URL:= > https://github.com/numpy/numpy/archive/v$(PYTHON3_NUMPY_VERSION).$(PYTHON3_NUMPY_SUFFIX) > > +PYTHON3_NUMPY_SOURCE := > $(SRCDIR)/$(PYTHON3_NUMPY).$(PYTHON3_NUMPY_SUFFIX) > > +PYTHON3_NUMPY_DIR:= $(BUILDDIR)/$(PYTHON3_NUMPY) > > +PYTHON3_NUMPY_LICENSE:= BSD > > While you're at it, please add at least one file and MD5 sum to the > PYTHON3_NUMPY_LICENSE_FILES variable. And according to LICENSE.txt, > there are also files under different licenses in the source tree, these > licenses should be added here as well. > Not sure how this works, let me give it a try. BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] how to integrate python modules using find_library
Hi all, Some python packages (e.g. soundfile) rely on find_library (from ctypes.util) to resolve the name of a dynamic library at runtime in a platform-independent way. On Linux, the implementation of find_library [1] requires one of the following: - ldconfig - gcc + objdump - ld + objdump Neither of the above make much sense on an embedded target. Does anyone have advice or recommendations on how to deal with such packages, short of just patching the sources to avoid the use of find_library? [1]: https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/ctypes/util.py#L309 Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Ptxdist BSP for STM32MP15x SoC
Hi Robert, El lun., 2 sept. 2019 a las 23:26, Robert Schwebel (< r.schwe...@pengutronix.de>) escribió: > Hi, > > On Mon, Sep 02, 2019 at 07:35:25PM +0200, Guillermo Rodriguez Garcia wrote: > > Is someone using ptxdist with STM32MP15x based targets? ST only supports > Yocto > > for this SoC. > > > > Re. toolchain: Any recommended version of OSELAS.Toolchain? Any hints on > > settings to finetune for this CPU? This is a single or dual Cortex A7 > > (depending on the actual p/n), and has NEON + VFPv4. > > We made experiments with the MP1 recently, chances are good that we'll > get support for it soon in DistroKit. It should be part of the v7a > platform. > That's great news. Any chance to have a look at this in the meanwhile? I understand it is probably WIP. BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Ptxdist BSP for STM32MP15x SoC
Hi all, Is someone using ptxdist with STM32MP15x based targets? ST only supports Yocto for this SoC. Re. toolchain: Any recommended version of OSELAS.Toolchain? Any hints on settings to finetune for this CPU? This is a single or dual Cortex A7 (depending on the actual p/n), and has NEON + VFPv4. Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] fbset: Add option to install /etc/fb.modes
Hi, El mié., 7 ago. 2019 a las 14:26, Michael Olbrich () escribió: > On Mon, Aug 05, 2019 at 10:18:42AM +0200, Guillermo Rodríguez wrote: > > Signed-off-by: Guillermo Rodriguez > > --- > > rules/fbset.in | 14 -- > > rules/fbset.make | 4 +++- > > 2 files changed, 15 insertions(+), 3 deletions(-) > > > > diff --git a/rules/fbset.in b/rules/fbset.in > > index c2122c51b..64dd9ec55 100644 > > --- a/rules/fbset.in > > +++ b/rules/fbset.in > > @@ -1,11 +1,21 @@ > > ## SECTION=multimedia_framebuffer > > > > -config FBSET > > +menuconfig FBSET > > tristate > > - prompt "fbset" > > + prompt "fbset " > > select HOST_FLEX > > help > > fbset is a system utility to show or change the settings > > of the frame buffer device. The frame buffer device pro- > > vides a simple and unique interface to access different > > kinds of graphic displays. > > + > > +if FBSET > > + > > +config FBSET_FBMODES > > + bool > > + prompt "install /etc/fb.modes" > > + help > > + Install /etc/fb.modes file. > > + > > +endif > > diff --git a/rules/fbset.make b/rules/fbset.make > > index 0d34d8959..955480b21 100644 > > --- a/rules/fbset.make > > +++ b/rules/fbset.make > > @@ -45,7 +45,9 @@ $(STATEDIR)/fbset.targetinstall: > > @$(call install_fixup, fbset,DESCRIPTION,missing) > > > > @$(call install_copy, fbset, 0, 0, 0755, -, /usr/sbin/fbset) > > - > > +ifdef PTXCONF_FBSET_FBMODES > > + @$(call install_alternative, fbset, 0, 0, 0644, /etc/fb.modes) > > +endif > > Hmmm, I don't like options that are broken by default. > OK, although this is disabled by default. I assume that users that enable it have a valid fb.modes file that they want to include.. > Please add a default file in projectroot/. > fb modes (timings specifically) are hardware-specific. Is it OK if I add a default file with no modes defined? (I can e.g. add a comment saying that it is a placeholder) Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Copying kernel and uboot to /boot in target filesystem image
Hello, El vie., 21 dic. 2018 a las 15:16, Alexander Dahl () escribió: > > Hello, > > Am Freitag, 21. Dezember 2018, 14:27:12 CET schrieb Guillermo Rodriguez > Garcia: > > > PTXCONF_U_BOOT is in platformconfig, so I guess your .in file can only > > > depend on it, if it extends the platformconfig as well, not the normal > > > ptxconfig? > > I see. How can I have my .in file "extend" the platformconfig ? > > Just move it from the folder 'rules' to 'platforms' or maybe better to config/ > yourplatform/platforms. You call 'make platformconfig' then and find it > somewhere there. > > It's probably good to see some other platform packages in the ptxdist source > in 'platforms' or in DistroKit e.g. in 'configs/platform-v7a/platforms'. IIRC > the categories in the first line of the .in file differ. > > I'm not sure if all possibilities for the accompaning .make files apply, nor > if that topic is covered in the documentation, but it should give you a > starting point. This got me on the right track, although it looks like it doesn't matter whether the file is in rules, or platform or whatever -- what matters is actually the category in the first line of the .in file. In fact, I already have a modified u-boot.in in my BSP's rules directory, so I just added a new option there; if this option is enabled, any selected u-boot files will be installed to /boot in the target filesystem, in addition to copying them to the platform image directory. Thank you for the pointer! Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Copying kernel and uboot to /boot in target filesystem image
Hi Alexander, El vie., 21 dic. 2018 a las 14:02, Alexander Dahl () escribió: > > Hei hei, > > Am Freitag, 21. Dezember 2018, 13:17:52 CET schrieb Guillermo Rodriguez > Garcia: > > I want to have ptxdist copy the generated kernel and uboot binaries to > > the /boot directory in the target filesystem image. > > What about KERNEL_INSTALL in platformconfig? Do you have more files which are > not covered by that? I didn't know about that option. That's good -- it covers the kernel and dts file. But I also need to copy the SPL and uboot binaries. > > > For this I need to setup a package that would depend on the kernel and > > uboot packages, so that these are generated first. In the .in file I > > added the following: > > > > select U_BOOT if ROOTFS_EXTRA_COPY_UBOOT_FILES > > select KERNEL if ROOTFS_EXTRA_COPY_KERNEL_FILES > > > > But for u-boot I get the following: > > > > warning: 'select' used by config symbol 'ROOTFS_EXTRA' refers to > > undefined symbol 'U_BOOT' > > > > Why is this, and how can I solve it? > > PTXCONF_U_BOOT is in platformconfig, so I guess your .in file can only depend > on it, if it extends the platformconfig as well, not the normal ptxconfig? I see. How can I have my .in file "extend" the platformconfig ? Thanks, Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Copying kernel and uboot to /boot in target filesystem image
Hi all, I want to have ptxdist copy the generated kernel and uboot binaries to the /boot directory in the target filesystem image. For this I need to setup a package that would depend on the kernel and uboot packages, so that these are generated first. In the .in file I added the following: select U_BOOT if ROOTFS_EXTRA_COPY_UBOOT_FILES select KERNEL if ROOTFS_EXTRA_COPY_KERNEL_FILES But for u-boot I get the following: warning: 'select' used by config symbol 'ROOTFS_EXTRA' refers to undefined symbol 'U_BOOT' Why is this, and how can I solve it? Thank you, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] classpath: Fix for building with OpenJDK-1.8 (again)
El sáb., 17 nov. 2018 a las 14:50, Michael Olbrich () escribió: > > On Sat, Nov 17, 2018 at 01:33:19AM +0100, Guillermo Rodriguez Garcia wrote: > > El viernes, 16 de noviembre de 2018, Michael Olbrich < > > m.olbr...@pengutronix.de> escribió: > > > > > On Fri, Nov 16, 2018 at 12:20:18PM +0100, Guillermo Rodríguez wrote: > > > > Commit bbc978e623cafc added a patch intended to fix building > > > > with OpenJDK 1.8, however that commit was not complete. It is > > > > necessary to run autogen.sh so that the configure script is > > > > regenerated and the patched m4 macros are used. > > > > > > > > Signed-off-by: Guillermo Rodriguez > > > > > > Unfortunately it's not that simple. The */Makefile.am also need the > > > 1.5 -> 1.6 change. I tried that an then I get lots of errors like this: > > > > > > warning: as of release 9, '_' is a keyword, and may not be used as an > > > identifier > > > > > > Uhm, those are not errors, they are warnings (as long as we specify -target > > < 9, which is the case here). Anyway from these messages it looks like you > > are building with OpenJDK9? That is not supposed to work; the intent of the > > patch was to allow building with OpenJDK8... can you check the version of > > javac? > > Right, I missed the errors because of all those warnings: > [...]/classpath-0.99/java/util/regex/Matcher.java:623: error: unmappable > character (0xC2) for encoding US-ASCII >*??@since 1.5 > ^ > > There is some white-space there that does not match the selected encoding, > I think. If I replace this with a space, then building the package > succeeds. > So please add the Makefile.am changes to the first patch and create another > to fix this whitespace. Please let me have a look at this. However, can you confirm which javac are you using? I believe javac from OpenJDK 1.8 should not require any of this. Best, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] classpath: Fix for building with OpenJDK-1.8 (again)
El viernes, 16 de noviembre de 2018, Michael Olbrich < m.olbr...@pengutronix.de> escribió: > On Fri, Nov 16, 2018 at 12:20:18PM +0100, Guillermo Rodríguez wrote: > > Commit bbc978e623cafc added a patch intended to fix building > > with OpenJDK 1.8, however that commit was not complete. It is > > necessary to run autogen.sh so that the configure script is > > regenerated and the patched m4 macros are used. > > > > Signed-off-by: Guillermo Rodriguez > > Unfortunately it's not that simple. The */Makefile.am also need the > 1.5 -> 1.6 change. I tried that an then I get lots of errors like this: > > warning: as of release 9, '_' is a keyword, and may not be used as an > identifier Uhm, those are not errors, they are warnings (as long as we specify -target < 9, which is the case here). Anyway from these messages it looks like you are building with OpenJDK9? That is not supposed to work; the intent of the patch was to allow building with OpenJDK8... can you check the version of javac? Guillermo > > Michael > > > --- > > patches/classpath-0.99/autogen.sh | 2 ++ > > rules/classpath.in| 1 + > > 2 files changed, 3 insertions(+) > > create mode 100755 patches/classpath-0.99/autogen.sh > > > > diff --git a/patches/classpath-0.99/autogen.sh b/patches/classpath-0.99/ > autogen.sh > > new file mode 100755 > > index 000..9ca025f > > --- /dev/null > > +++ b/patches/classpath-0.99/autogen.sh > > @@ -0,0 +1,2 @@ > > +#!/bin/bash > > +exec ./autogen.sh > > diff --git a/rules/classpath.in b/rules/classpath.in > > index 16017b2..271a917 100644 > > --- a/rules/classpath.in > > +++ b/rules/classpath.in > > @@ -5,6 +5,7 @@ config CLASSPATH > > prompt "classpath" > > select GCCLIBS_GCC_S > > select HOST_SYSTEM_JDK > > + select HOST_GETTEXT > > help > > GNU Classpath, Essential Libraries for Java, is a GNU project to > create > > free core class libraries for use with virtual machines and > compilers > > -- > > 1.9.1 > > > > > > ___ > > ptxdist mailing list > > ptxdist@pengutronix.de > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > > ___ > ptxdist mailing list > ptxdist@pengutronix.de -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] classpath: Fix building with OpenJDK 1.8
Hi Michael, El vie., 16 nov. 2018 a las 9:08, Michael Olbrich () escribió: > > Hi, > On Thu, Nov 08, 2018 at 05:26:11PM +0100, Guillermo Rodriguez Garcia wrote: > > Any feedback on this one ? > > I was just waiting to get the release out of the door. I've applied this > now. It build on must of my test setups, so it gets enough test coverage to > notice if the build fails. > Note that on my Debian testing machine, configure fails with: > > configure:24594: checking if /usr/lib/jvm/default-java/bin/javac works > configure:24619: /usr/lib/jvm/default-java/bin/javac -source 1.5 -target 1.5 > Object.java > warning: [options] bootstrap class path not set in conjunction with -source 5 > error: Source option 5 is no longer supported. Use 6 or later. > error: Target option 1.5 is no longer supported. Use 1.6 or later. OK it seems that my patch was not complete. With my changes properly applied, the m4 macros should be using 1.6 and not 1.5. autogen.sh must be run so that the configure script is regenerated. I missed this when I submitted the patch. Sorry for that. I am sending a new patch to fix this. Best, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] u-boot: Add support for SPL for non-OMAP CPUs
Hello,
Any comments?
Thank you,
Guillermo
El mar., 23 oct. 2018 a las 16:32, Guillermo Rodríguez
() escribió:
>
> Add support for installing the SPL binary for non-OMAP CPUs.
>
> Also properly remove any files installed in the platform image
> directory in the clean stage.
>
> Signed-off-by: Guillermo Rodriguez
> ---
> platforms/u-boot.in | 14 +++---
> rules/u-boot.make | 4
> 2 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/platforms/u-boot.in b/platforms/u-boot.in
> index 38684a0..602de46 100644
> --- a/platforms/u-boot.in
> +++ b/platforms/u-boot.in
> @@ -49,6 +49,13 @@ config U_BOOT_INSTALL_ELF
> help
> Installing the U-Boot ELF binary into platform image directory.
>
> +config U_BOOT_INSTALL_SPL
> + prompt "install SPL"
> + bool
> + help
> + Installing the U-Boot SPL (Secondary Program Loader) binary into
> + platform image directory.
> +
> config U_BOOT_INSTALL_MLO
> prompt "install MLO"
> bool
> @@ -57,14 +64,14 @@ config U_BOOT_INSTALL_MLO
> Installing the U-Boot SPL ("MLO") binary needed for OMAP CPUs into
> platform
> image directory.
>
> -if U_BOOT_INSTALL_MLO
> +if U_BOOT_INSTALL_MLO || U_BOOT_INSTALL_SPL
>
> config U_BOOT_INSTALL_U_BOOT_IMG
> prompt "install u-boot.img"
> bool
> help
> Installing the u-boot image with header ("u-boot.img") which is
> executed
> - by u-boot SPL ("MLO") into platform image directory.
> + by u-boot SPL into platform image directory.
>
> endif
>
> @@ -73,7 +80,8 @@ config U_BOOT_INSTALL_U_BOOT_IMX
> bool
> help
> Installing the U-Boot image with imx header (u-boot.imx) into
> platform
> - image directory. Say yes if you are building for freescale i.MX SOC
> + image directory. Say yes if you are building for freescale i.MX SOCs
> + and are not using SPL.
>
> endif
>
> diff --git a/rules/u-boot.make b/rules/u-boot.make
> index 94aa774..9f69f9d 100644
> --- a/rules/u-boot.make
> +++ b/rules/u-boot.make
> @@ -69,6 +69,9 @@ endif
> ifdef PTXCONF_U_BOOT_INSTALL_ELF
> @install -D -m644 $(U_BOOT_DIR)/u-boot $(IMAGEDIR)/u-boot.elf
> endif
> +ifdef PTXCONF_U_BOOT_INSTALL_SPL
> + @install -D -m644 $(U_BOOT_DIR)/SPL $(IMAGEDIR)/SPL
> +endif
> ifdef PTXCONF_U_BOOT_INSTALL_MLO
> @install -D -m644 $(U_BOOT_DIR)/MLO $(IMAGEDIR)/MLO
> endif
> @@ -88,6 +91,7 @@ $(STATEDIR)/u-boot.clean:
> @$(call targetinfo)
> @$(call clean_pkg, U_BOOT)
> @rm -f $(IMAGEDIR)/u-boot.bin $(IMAGEDIR)/u-boot.srec
> $(IMAGEDIR)/u-boot.elf
> + @rm -f $(IMAGEDIR)/u-boot.img $(IMAGEDIR)/SPL $(IMAGEDIR)/MLO
> @rm -f $(IMAGEDIR)/u-boot.imx
>
> # vim: syntax=make
> --
> 1.9.1
>
--
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
ptxdist mailing list
ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] classpath: Fix building with OpenJDK 1.8
Hello all, Any feedback on this one ? Guillermo El mié., 31 oct. 2018 a las 16:12, Guillermo Rodríguez () escribió: > > Also move back from staging. > > Signed-off-by: Guillermo Rodriguez > --- > .../0001-Fix-building-with-OpenJDK-1.8.patch | 50 > ++ > patches/classpath-0.99/series | 1 + > rules/classpath.in | 7 +-- > 3 files changed, 52 insertions(+), 6 deletions(-) > create mode 100644 > patches/classpath-0.99/0001-Fix-building-with-OpenJDK-1.8.patch > create mode 100644 patches/classpath-0.99/series > > diff --git a/patches/classpath-0.99/0001-Fix-building-with-OpenJDK-1.8.patch > b/patches/classpath-0.99/0001-Fix-building-with-OpenJDK-1.8.patch > new file mode 100644 > index 000..fe7d3ba > --- /dev/null > +++ b/patches/classpath-0.99/0001-Fix-building-with-OpenJDK-1.8.patch > @@ -0,0 +1,50 @@ > +This patch makes it possible to build GNU Classpath using javac > +from OpenJDK 1.7 and 1.8. > + > +- From the javac docs: "Classes found through the classpath are > +subject to automatic recompilation if their sources are found." > +javac from OpenJDK 1.7+ will try (and fail) to recompile "standard" > +Java classes (e.g. java/lang/Object.java) when compiling the Java > +test class. Fix this by explicitly passing an empty -sourcepath. > + > +- Test for 1.6 instead of 1.5, as -source/-target 1.5 is deprecated > +in Java 8, and the Makefiles already use -source/-target 1.6 anyway. > + > +--- > + m4/ac_prog_java_works.m4 | 3 ++- > + m4/ac_prog_javac_works.m4 | 4 ++-- > + 2 files changed, 4 insertions(+), 3 deletions(-) > + > +diff --git a/m4/ac_prog_java_works.m4 b/m4/ac_prog_java_works.m4 > +index d3f2744..f36318b 100644 > +--- a/m4/ac_prog_java_works.m4 > b/m4/ac_prog_java_works.m4 > +@@ -62,7 +62,8 @@ EOF > + changequote([, ])dnl > + if test x$ac_cv_prog_uudecode_base64 != xyes; then > + AC_REQUIRE([AC_PROG_JAVAC_WORKS]) > +-if AC_TRY_COMMAND($JAVAC $JAVACFLAGS $JAVA_TEST) && test -s > $CLASS_TEST; then > ++ CMD="$JAVAC $JAVACFLAGS -sourcepath '' $JAVA_TEST" > ++if AC_TRY_COMMAND($CMD) && test -s $CLASS_TEST; then > + : > + else > + echo "configure: failed program was:" >_FD_CC > +diff --git a/m4/ac_prog_javac_works.m4 b/m4/ac_prog_javac_works.m4 > +index 7fb298d..fbe24ce 100644 > +--- a/m4/ac_prog_javac_works.m4 > b/m4/ac_prog_javac_works.m4 > +@@ -33,9 +33,9 @@ public class Object > + } > + EOF > + if test x$JAVAC_IS_GCJ = xyes; then > +- CMD="$JAVAC $JAVACFLAGS -fsource=1.5 -ftarget=1.5 $JAVA_TEST" > ++ CMD="$JAVAC $JAVACFLAGS -fsource=1.6 -ftarget=1.6 $JAVA_TEST" > + else > +- CMD="$JAVAC $JAVACFLAGS -source 1.5 -target 1.5 $JAVA_TEST" > ++ CMD="$JAVAC $JAVACFLAGS -sourcepath '' -source 1.6 -target 1.6 $JAVA_TEST" > + fi > + if AC_TRY_COMMAND($CMD) >/dev/null 2>&1; then > + ac_cv_prog_javac_works=yes > +-- > +1.9.1 > + > diff --git a/patches/classpath-0.99/series b/patches/classpath-0.99/series > new file mode 100644 > index 000..1fffdbd > --- /dev/null > +++ b/patches/classpath-0.99/series > @@ -0,0 +1 @@ > +0001-Fix-building-with-OpenJDK-1.8.patch > diff --git a/rules/classpath.in b/rules/classpath.in > index 67b5dca..16017b2 100644 > --- a/rules/classpath.in > +++ b/rules/classpath.in > @@ -1,6 +1,4 @@ > -## SECTION=staging > -## old section: > -### SECTION=bytecode_engines > +## SECTION=bytecode_engines > > config CLASSPATH > tristate > @@ -12,6 +10,3 @@ config CLASSPATH > free core class libraries for use with virtual machines and > compilers > for the java programming language. > > - STAGING: remove in ptxdist-2019.04.0 > - Old, obsolete package that fails to build with OpenJDK 9. > - > -- > 1.9.1 > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] GNU Classpath moved to staging
Hi all, El mar., 16 oct. 2018 a las 17:27, Guillermo Rodriguez Garcia () escribió: > > Hi all, > > In commit 6f058ada, GNU Classpath was moved to staging with the comment: > > "Old, obsolete package that fails to build with OpenJDK 9" > > I am using this on several BSPs on different platforms without > problems; I wouldn't say it is "obsolete" (for many use cases there is > no obvious replacement). > > Indeed it does not currently build with OpenJDK 9, however is that > really a requirement? OpenJDK 9 introduced some pretty disruptive > changes that break many existing Java applications / libraries, and > fixing this is not trivial. It does build just fine with OpenJDK 8, > though. I was wrong. GNU Classpath does not currently build with OpenJDK 8. I am looking into this now. Sorry for the noise. Best, Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v2] imx-kobs: New package
Hi Ladislav, El mar., 23 oct. 2018 a las 17:10, Ladislav Michl () escribió: > just a side note, changelog bellow is not part of commit log, so it > should be placed bellow "---". Noted, thank you! Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] imx-kobs: New package
Hi Alexander, El mar., 23 oct. 2018 a las 13:00, Alexander Dahl () escribió: > > Hei hei, > > this is strange, I was just working on a new package for the very same tool. > o.O :) > Am Dienstag, 23. Oktober 2018, 11:23:36 CEST schrieb Guillermo Rodríguez: > > The imx-kobs tool is used to create and write i.MX NAND boot > > related boot data structures to NAND flash. > > > > Signed-off-by: Guillermo Rodriguez > > --- > > rules/imx-kobs.in | 8 > > rules/imx-kobs.make | 53 > > + 2 files changed, 61 > > insertions(+) > > create mode 100644 rules/imx-kobs.in > > create mode 100644 rules/imx-kobs.make > > > > diff --git a/rules/imx-kobs.in b/rules/imx-kobs.in > > new file mode 100644 > > index 000..e00ca24 > > --- /dev/null > > +++ b/rules/imx-kobs.in > > @@ -0,0 +1,8 @@ > > +## SECTION=shell_and_console > > + > > +config IMX_KOBS > > + tristate > > + prompt "imx-kobs" > > + help > > + The imx-kobs tool is used to create and write i.MX NAND boot > > + related boot data structures to NAND flash. > > diff --git a/rules/imx-kobs.make b/rules/imx-kobs.make > > new file mode 100644 > > index 000..49380c2 > > --- /dev/null > > +++ b/rules/imx-kobs.make > > @@ -0,0 +1,53 @@ > > +# -*-makefile-*- > > +# > > +# Copyright (C) 2018 by Guillermo Rodriguez > > +# > > +# See CREDITS for details about who has contributed to this project. > > +# > > +# For further information about the PTXdist project and license conditions > > +# see the README file. > > +# > > + > > +# > > +# We provide this package > > +# > > +PACKAGES-$(PTXCONF_IMX_KOBS) += imx-kobs > > + > > +# > > +# Paths and names > > +# > > +IMX_KOBS_VERSION := 5.5 > > +IMX_KOBS_SUFFIX := tar.gz > > +IMX_KOBS_MD5 := 48ed9e69e9527d2e98b5cfcbf133d75b > > +IMX_KOBS := imx-kobs-$(IMX_KOBS_VERSION) > > +IMX_KOBS_URL := > > http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/$(IMX_KOBS).$(IMX_KOBS_SUFFI > > How did you find this? I would have taken the tool from GitHub: I have to admit I am not sure anymore where I found this. When cleaning up the .make file I considered switching to github, but at the end I chose not to do it as it had no tags and I thought that this would be cleaner than referencing a specific commit by its hash. > https://github.com/NXPmicro/imx-kobs > > That one is without tags however. > > > X) +IMX_KOBS_DIR := $(BUILDDIR)/$(IMX_KOBS) > > +IMX_KOBS_SOURCE := $(SRCDIR)/$(IMX_KOBS).$(IMX_KOBS_SUFFIX) > > +IMX_KOBS_LICENSE := GPLv2 > > GPL-2.0-or-later OK. > What about IMX_KOBS_LICENSE_FILES := file://COPYING;md5=… Never did this before, I thought it was only necessary for not-well-known licenses. Should I add it? Thanks, Guillermo ___ ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] GNU Classpath moved to staging
Hi all, In commit 6f058ada, GNU Classpath was moved to staging with the comment: "Old, obsolete package that fails to build with OpenJDK 9" I am using this on several BSPs on different platforms without problems; I wouldn't say it is "obsolete" (for many use cases there is no obvious replacement). Indeed it does not currently build with OpenJDK 9, however is that really a requirement? OpenJDK 9 introduced some pretty disruptive changes that break many existing Java applications / libraries, and fixing this is not trivial. It does build just fine with OpenJDK 8, though. Can we move this out of staging ? Regards, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] stm32flash: New package
El vie., 5 oct. 2018 a las 16:04, Michael Olbrich () escribió: > > On Fri, Oct 05, 2018 at 12:43:01PM +0200, Guillermo Rodriguez Garcia wrote: > > > > +# > > > > > > > > +# Prepare > > > > +# > > > > > > > > + > > > > +STM32FLASH_CONF_TOOL := NO > > > > +STM32FLASH_MAKE_ENV := $(CROSS_ENV) > > > > +STM32FLASH_INSTALL_OPT := PREFIX=/usr install > > > > > > For readability, keep these options on a single line each: > > > > > > STM32FLASH_INSTALL_OPT := \ > > > PREFIX=/usr \ > > > install > > > > > > Also most packages keep *_INSTALL_* variables under the Install section > > > header, and *_MAKE_* variables under the "Compile" section header. I > > > would suggest to do it here too to get a unified look over package > > > rules. > > > > Uhm, most of the existing packages I have checked define MAKE_ and > > INSTALL_ vars in the prepare stage. See for example bzip2 (this is the > > one I used as a reference), busybox, i2c-tools, openssl, zip ... > > I'd put it all in the prepare section if _only_ these variables are > defined and the other sections are skipped entirely. If the actual compile > / install target is defined as well, then the variable should be in the > corresponding section. Allright. That's exactly the case here, only these variables are defined and there is nothing else in the compile / install sections. I'll send v2 of the patch then. BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] stm32flash: New package
Hi, El vie., 5 oct. 2018 a las 12:30, Roland Hieber () escribió: > > Hi, > > On Fri, Oct 05, 2018 at 11:25:45AM +0200, Guillermo Rodriguez wrote: > > Open source cross platform flash program for the STM32 ARM > > microcontrollers using the built-in ST serial bootloader over UART > > or I2C. > > > > Signed-off-by: Guillermo Rodriguez > > --- > > rules/stm32flash.in | 9 > > rules/stm32flash.make | 57 > > +++ > > 2 files changed, 66 insertions(+) > > create mode 100644 rules/stm32flash.in > > create mode 100644 rules/stm32flash.make > > > > diff --git a/rules/stm32flash.in b/rules/stm32flash.in > > new file mode 100644 > > index 000..877eed3 > > --- /dev/null > > +++ b/rules/stm32flash.in > > @@ -0,0 +1,9 @@ > > +## SECTION=shell_and_console > > + > > +config STM32FLASH > > + tristate > > + prompt "stm32flash" > > + help > > + Open source cross platform flash program for the STM32 ARM > > + microcontrollers using the built-in ST serial bootloader over UART > > + or I2C. > > diff --git a/rules/stm32flash.make b/rules/stm32flash.make > > new file mode 100644 > > index 000..975d02e > > --- /dev/null > > +++ b/rules/stm32flash.make > > @@ -0,0 +1,57 @@ > > +# -*-makefile-*- > > +# > > +# Copyright (C) 2018 by Guillermo Rodriguez > > +# > > +# See CREDITS for details about who has contributed to this project. > > +# > > +# For further information about the PTXdist project and license conditions > > +# see the README file. > > +# > > + > > +# > > +# We provide this package > > +# > > +PACKAGES-$(PTXCONF_STM32FLASH) += stm32flash > > + > > +# > > +# Paths and names > > +# > > +STM32FLASH_VERSION := 0.5 > > +STM32FLASH_SUFFIX:= tar.gz > > +STM32FLASH_MD5 := 40f673502949f3bb655d2bcc539d7b6a > > +STM32FLASH := stm32flash-$(STM32FLASH_VERSION) > > +STM32FLASH_URL := > > https://sourceforge.net/projects/stm32flash/files/$(STM32FLASH).$(STM32FLASH_SUFFIX)/download > > Better use $(call ptx/mirror, SF, ...) here to get a list of SourceForge > mirrors. Have a look at other packages for how to use it. Will do. > > > +STM32FLASH_DIR := $(BUILDDIR)/$(STM32FLASH) > > +STM32FLASH_SOURCE:= $(SRCDIR)/$(STM32FLASH).$(STM32FLASH_SUFFIX) > > +STM32FLASH_LICENSE := GPLv2 > > + > > + > > +# > > > > +# Prepare > > +# > > > > + > > +STM32FLASH_CONF_TOOL := NO > > +STM32FLASH_MAKE_ENV := $(CROSS_ENV) > > +STM32FLASH_INSTALL_OPT := PREFIX=/usr install > > For readability, keep these options on a single line each: > > STM32FLASH_INSTALL_OPT := \ > PREFIX=/usr \ > install > > Also most packages keep *_INSTALL_* variables under the Install section > header, and *_MAKE_* variables under the "Compile" section header. I > would suggest to do it here too to get a unified look over package > rules. Uhm, most of the existing packages I have checked define MAKE_ and INSTALL_ vars in the prepare stage. See for example bzip2 (this is the one I used as a reference), busybox, i2c-tools, openssl, zip ... > > > + > > +# > > > > +# Target-Install > > +# > > > > + > > +$(STATEDIR)/stm32flash.targetinstall: > > + @$(call targetinfo) > > + > > + @$(call install_init, stm32flash) > > + @$(call install_fixup, stm32flash, PRIORITY,optional) > > + @$(call install_fixup, stm32flash, SECTION,base) > > + @$(call install_fixup, stm32flash, AUTHOR,"Guillermo Rodriguez > > ") > > + @$(call install_fixup, stm32flash, DESCRIPTION,missing) > > + > > + @$(call install_copy, stm32flash, 0, 0, 0755, -, /usr/bin/stm32flash) > > + > > + @$(call install_finish, stm32flash) > > + > > + @$(call touch) > > + > > While you're at it, no need for a double blank line here :) OK :) Guillermo > > - Roland > > > + > > +# vim: syntax=make > > -- > > 2.5.4 (Apple Git-61) > > > > > > ___ > > ptxdist mailing list > > ptxdist@pengutronix.de > > -- > Roland Hieber | r.hie...@pengutronix.de | > Pengutronix e.K. | https://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5086 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] fbv package removed
El vie., 5 oct. 2018 a las 12:22, Roland Hieber () escribió: > > On Fri, Oct 05, 2018 at 12:17:45PM +0200, Guillermo Rodriguez Garcia wrote: > > Hi all, > > > > I just noticed that the fbv package has been removed after one year in > > staging. I am using this on several BSPs and didn't realize it had > > been moved to staging. The reasons for removal are: > > > > "Old and obsolete, upstream gone. Fails to build with current libpng." > > > > However, the libpng problem had already been addressed in this patch: > > https://git.pengutronix.de/cgit/ptxdist/commit?id=4a0738ec264fcbf809863dd245aff012bee274e6 > > > > Also, upstream is alive: http://s-tech.elsat.net.pl/fbv/ > > > > Given the above, can we revert this and move this out of staging > > again? Should I send this as a patch? > > Yes, and yes. The only point of the staging area is to be a pool for > packages that don't build anymore and for which nobody seems to care. If > both those reasons are taken care of, no problem :) Perfect, thank you. Will prepare the patch and send it. Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] fbv package removed
Hi all, I just noticed that the fbv package has been removed after one year in staging. I am using this on several BSPs and didn't realize it had been moved to staging. The reasons for removal are: "Old and obsolete, upstream gone. Fails to build with current libpng." However, the libpng problem had already been addressed in this patch: https://git.pengutronix.de/cgit/ptxdist/commit?id=4a0738ec264fcbf809863dd245aff012bee274e6 Also, upstream is alive: http://s-tech.elsat.net.pl/fbv/ Given the above, can we revert this and move this out of staging again? Should I send this as a patch? Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] The second symbolic links are not copied to the target
Hi Michael, 2018-07-06 11:54 GMT+02:00 Michael Olbrich : > On Thu, Jul 05, 2018 at 02:50:13PM +0200, Guillermo Rodriguez Garcia wrote: >> 2018-07-05 14:22 GMT+02:00 Michael Olbrich : >> > On Thu, Jul 05, 2018 at 01:02:47PM +0200, Alejandro Vázquez wrote: >> >> Yes. At least it gives problems with Java applications. >> >> ... >> >> [Failed to open library /usr/lib/classpath/libjavanio.so: >> >> /usr/lib/classpath/libjavanio.so: cannot open shared object file: No such >> >> file or directory] >> >> [Failed to open library ./libjavanio.so: ./libjavanio.so: cannot open >> >> shared object file: No such file or directory] >> >> [Failed to open library /usr/lib/jni/libjavanio.so: >> >> /usr/lib/jni/libjavanio.so: cannot open shared object file: No such file >> >> or >> >> directory] >> >> .. >> >> >> >> It also happens with some Gstreamer plugins. >> >> >> >> (gst-plugin-scanner:252): GStreamer-WARNING **: Failed to load plugin >> >> '/usr/lib/gstreamer-1.0/libgstimxg2d.so': libGAL.so: cannot open shared >> >> object file: No such file or directory >> > >> > These libraries are broken. I expect they don't have a soname (you can >> > check that with 'readelf -d '). >> > >> > You need to create the link manually with 'install_link'. >> >> I can't talk about GStreamer but dynamic library loading in Java is a >> bit different. > > This has nothing to do with GStreamer. The problem is, that libGAL.so is > missing the correct 'soname'. As a result, libgstimxg2d.so is not linked > correctly. Yes, so libGAL.so is broken. You are right in that this is not something that ptxdist should try to "fix". However > >> There are no elf files involved. Java >> applications/libraries can request that a native library is loaded via >> the System.loadLibrary runtime API. This takes a "generic" (platform >> independent) library name, which is then "resolved" to a platform >> specific filename by the JVM. For Windows this is typically "foo" -> >> "foo.dll", and for Linux it is "foo" -> "libfoo.so". >> >> So it seems that removing the .so links breaks all Java applications.. >> >> Can this be reconsidered? > > No, install_lib is for proper versioned shared libraries. If you need extra > links, then you can add those with install_link. however, this is a different case. The problem with Java is not that the libraries themselves are not properly versioned. The problem is that due to the way native libraries are loaded in Java, the JVM must map a "generic" name such as foo to a platform-specific filename, which for Linux would be "libfoo.so", and then it tries to load that by filename. This assumes that the .so file is present and links to the appropriate libfoo.so.X. Guillermo > > Michael > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > > ___ > ptxdist mailing list > ptxdist@pengutronix.de -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] The second symbolic links are not copied to the target
2018-07-05 14:22 GMT+02:00 Michael Olbrich : > Hi, > > On Thu, Jul 05, 2018 at 01:02:47PM +0200, Alejandro Vázquez wrote: >> None of the two I think. This was changed in commit >> > f13787aca6bc51976cbc34be7262683ccd134474, log message was: >> > ptxd_install_shared: don't install last link >> > It's only needed at build time. >> >> >> Fine but in the ptxdist documentation >> <https://www.ptxdist.org/doc/ref_manual.html#install-lib> it indicates that >> the file *.so is copied. > > This is outdated. I need to fix that. > >> Is this causing any actual problems? > > These links should not be necessary at runtime. That's how library > versioning on Linux works. > If you check your desktop Linux, you'll notice, that the last link is in > the devel package: It's only needed at built time. Most of the time this is right, but there seem to be exceptions, see below. > >> Yes. At least it gives problems with Java applications. >> ... >> [Failed to open library /usr/lib/classpath/libjavanio.so: >> /usr/lib/classpath/libjavanio.so: cannot open shared object file: No such >> file or directory] >> [Failed to open library ./libjavanio.so: ./libjavanio.so: cannot open >> shared object file: No such file or directory] >> [Failed to open library /usr/lib/jni/libjavanio.so: >> /usr/lib/jni/libjavanio.so: cannot open shared object file: No such file or >> directory] >> .. >> >> It also happens with some Gstreamer plugins. >> >> (gst-plugin-scanner:252): GStreamer-WARNING **: Failed to load plugin >> '/usr/lib/gstreamer-1.0/libgstimxg2d.so': libGAL.so: cannot open shared >> object file: No such file or directory > > These libraries are broken. I expect they don't have a soname (you can > check that with 'readelf -d '). > > You need to create the link manually with 'install_link'. I can't talk about GStreamer but dynamic library loading in Java is a bit different. There are no elf files involved. Java applications/libraries can request that a native library is loaded via the System.loadLibrary runtime API. This takes a "generic" (platform independent) library name, which is then "resolved" to a platform specific filename by the JVM. For Windows this is typically "foo" -> "foo.dll", and for Linux it is "foo" -> "libfoo.so". So it seems that removing the .so links breaks all Java applications.. Can this be reconsidered? BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] The second symbolic links are not copied to the target
Hi there, 2018-07-01 6:28 GMT+02:00 Alejandro Vázquez : > Hi! > I've come across the following problem: > When installing classpath, the second symbolic links are not copied to the > target. > This should not happen as the library is installed as install_lib and you > should install the second symbol links. > I came from an older version of ptxdist and this didn't happen. > ptxdist --version: 2018.06.0 > > I'm not sure if it's a bug or a problem of mine. None of the two I think. This was changed in commit f13787aca6bc51976cbc34be7262683ccd134474, log message was: ptxd_install_shared: don't install last link It's only needed at build time. Is this causing any actual problems? BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ ptxdist mailing list ptxdist@pengutronix.de
