Team,
For people working with the AM5728 EVM, where can they find a valid package repository?
If the information at the post below is up to date (3 months old), can you tell us if there's a plan to create a repository?
Thanks,
Darren
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Team,
For people working with the AM5728 EVM, where can they find a valid package repository?
If the information at the post below is up to date (3 months old), can you tell us if there's a plan to create a repository?
Thanks,
Darren
I would note that both the repositories specified in the 02.00.02.11 and 03.00.00.04 Linux Processor SDK's are no longer reachable
i.e. /etc/opkg/base-feeds.conf for the v2 we have: (This one used to work but no longer does)
src/gz all gtautoftp.gt.design.ti.com/.../all
src/gz any gtautoftp.gt.design.ti.com/.../any
src/gz noarch gtautoftp.gt.design.ti.com/.../noarch
src/gz armv5hf-vfp gtautoftp.gt.design.ti.com/.../armv5hf-vfp
src/gz armv5thf-vfp gtautoftp.gt.design.ti.com/.../armv5thf-vfp
src/gz armv5ehf-vfp gtautoftp.gt.design.ti.com/.../armv5ehf-vfp
src/gz armv5tehf-vfp gtautoftp.gt.design.ti.com/.../armv5tehf-vfp
src/gz armv6hf-vfp gtautoftp.gt.design.ti.com/.../armv6hf-vfp
src/gz armv6thf-vfp gtautoftp.gt.design.ti.com/.../armv6thf-vfp
src/gz armv7ahf-vfp gtautoftp.gt.design.ti.com/.../armv7ahf-vfp
src/gz armv7at2hf-vfp gtautoftp.gt.design.ti.com/.../armv7at2hf-vfp
src/gz armv7ahf-vfp-neon gtautoftp.gt.design.ti.com/.../armv7ahf-vfp-neon
src/gz armv7at2hf-vfp-neon gtautoftp.gt.design.ti.com/.../armv7at2hf-vfp-neon
src/gz cortexa15hf-vfp gtautoftp.gt.design.ti.com/.../cortexa15hf-vfp
src/gz cortexa15hf-vfp-neon gtautoftp.gt.design.ti.com/.../cortexa15hf-vfp-neon
src/gz cortexa15t2hf-vfp gtautoftp.gt.design.ti.com/.../cortexa15t2hf-vfp
src/gz cortexa15t2hf-vfp-neon gtautoftp.gt.design.ti.com/.../cortexa15t2hf-vfp-neon
src/gz am57xx_evm gtautoftp.gt.design.ti.com/.../am57xx_evm
The one included in the v3 Linux SDK (\etc\opkg\base-feeds.conf) looks like its aimed at a personal site
src/gz all gtjenkins.itg.ti.com/.../all
src/gz any gtjenkins.itg.ti.com/.../any
src/gz noarch gtjenkins.itg.ti.com/.../noarch
src/gz armv5hf-vfp gtjenkins.itg.ti.com/.../armv5hf-vfp
src/gz armv5thf-vfp gtjenkins.itg.ti.com/.../armv5thf-vfp
src/gz armv5ehf-vfp gtjenkins.itg.ti.com/.../armv5ehf-vfp
src/gz armv5tehf-vfp gtjenkins.itg.ti.com/.../armv5tehf-vfp
src/gz armv6hf-vfp gtjenkins.itg.ti.com/.../armv6hf-vfp
src/gz armv6thf-vfp gtjenkins.itg.ti.com/.../armv6thf-vfp
src/gz armv7vehf-vfp gtjenkins.itg.ti.com/.../armv7vehf-vfp
src/gz armv7vet2hf-vfp gtjenkins.itg.ti.com/.../armv7vet2hf-vfp
src/gz armv7vehf-neon gtjenkins.itg.ti.com/.../armv7vehf-neon
src/gz armv7vet2hf-neon gtjenkins.itg.ti.com/.../armv7vet2hf-neon
src/gz cortexa15hf-vfp gtjenkins.itg.ti.com/.../cortexa15hf-vfp
src/gz cortexa15hf-neon gtjenkins.itg.ti.com/.../cortexa15hf-neon
src/gz cortexa15t2hf-vfp gtjenkins.itg.ti.com/.../cortexa15t2hf-vfp
src/gz cortexa15t2hf-neon gtjenkins.itg.ti.com/.../cortexa15t2hf-neon
src/gz am57xx_evm gtjenkins.itg.ti.com/.../am57xx_evm
This renders the opkg pretty much useless and the installed packages have some version issues (in particular the aclocal/autom4te versions expect a newer version of m4 and so will fail with a --gnu unknown option. Rebuilding m4 requires a whole mess of other packages be installed first so this is all big pain just to get the autoconf tools working. As noted elsewhere the arago server package list appears to be circa 2009. Please provide us a usable package source.
Yes of course I understand that I can build all this, but frankly I was hoping I didn't have to as that's the point of you shipping a pre-built SDK i.e. so we all didn't have to go through all steps and time to compile all the standard Linux libraries and tools so we can focus instead on building our own apps and porting things TI didn't provide. (for example I'm porting Mono to the AM5728 and discovered all this when I went to port libgdiplus - now I'll be spending the next few days building all the precursor libraries and tools.
My points were:
(a) The 3.0 SDK that you are shipping has a version mismatch in the autotools chain - specifically the M4 version is older than the autom4te app and so trying to port anything locally on the AM57xx filesystem. i.e. NOT cross compiling but building natively - will fail on a ./configure call. (autom4te calls m4 with a --gnu option which the m4 version doesn't recognize).
(b) When I went to check for an updated autotools / m4 package, I discovered that the opkg system is useless for anything other than removing existing stuff on the SDK filesystem because you are shipping it with the aforementioned inaccessible repositories. The Yocto server has nothing even remotely current (circa 2008!) so there is effectively no public opkg repository if we don't make one ourselves (i.e. a local repository.) at which point the usefulness of the opkg tool and the whole idea of shared, stable public resources is greatly reduced.
For example if you had a working public opkg system, TI (or I if you took submissions) could fix the tools prior to the next SDK release, and could contain multiple different versions in case someone needed the an older set of tools (which happens). "Wait for the next SDK" for a fix is a pretty annoying response as no one out here doing product development can possibly wait that long. And build (and maintain) your own SDK filesystem is annoying too - because I shouldn't have to as it's needless duplication of effort and you have a tool (opkg) that if used correctly would remove the need.
It's great to know I can compile everything from scratch but it's really something to be avoided if possible since it doesn't add any value and just sucks (unplanned for) time from my development schedule.
(c) If your argument for dismissing (a) and (b) are that "no one compiles natively and that I should be cross compiling everything myself" then why are you (TI)including ANY native build tools in the SDK filesystem including the compiler?
At a minimum, in the interest in not wasting anyone else's time, if there is no public repository and TI's policy is to not support one, the contents of /etc/opgk/base-feeds.conf should be scrubbed and it should be documented somewhere (even if only in this E2E exchange) that opkg is only useful for removing existing apps (i.e. to purge GNU copyleft apps prior to shipping) to not bother with it for anything else.