Re: [fedora-arm] arv7hl SRPM status updates
tor 2011-10-13 klockan 02:25 -0400 skrev Jon Masters: > Henrik, what do you think? Do we have enough of these packages under > control that a VFAD is overkill? Or is there benefit in having one? I > would love to get to next week with basically everything done on v7 :) What worries me mostly for koji timeplan is the toolchain. It's pretty core to getting things running and there is currently no eta on when thechanges in these will get cleaned up and/or merged mainline. There is also a slight worry that there may be regressions in gcc updates. gcc, glibc, java-*, ecj. Then there is rpm & yum, but dgilmore should be ontop of those I think. Most of the other stuff are pretty trivial, but still requires some effort to get done. plus that there quite likely still is F15 packages that is needed for release but still failing to build. But those can be addressed after moving to koji I think. What's currently left in the armv7hl repository are: (There is bug reports on more packages, but bugzilla currently down for maintenance) stage3-only: allegro ecj firebird gdm graphviz gtkmm24 (Bug #740790) libdc1394 (probably Bug #715762) libgphoto2 (Bug #745081, supposed to be mainline but F15 build failed) libvpx perl-Coro perl-Tk rrdtool (now in build queue) u-boot (new package, do not exists in F15) w3m stage4: anaconda gcc glibc gypsy java-1.6.0-openjdk java-1.5.0-gcj mysql ocaml python-pyblock pyxf86config rpm xulrunner yum pl haskell/ghc: ghc-* alex bluetile cabal-install cln cpphs haddock happy kaya xmonad The haskell/ghc changes are not blocking koji and are all trivial armv7hl arch additions. Mainly waiting for armv5tel to catch up a little making it meaningful to attempt to bootstrap ghc there, and the koji builds can start just fine without ghc I think. Regards Henrik ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arv7hl SRPM status updates
tor 2011-10-13 klockan 15:57 +0200 skrev Henrik Nordström: > tor 2011-10-13 klockan 02:25 -0400 skrev Jon Masters: > > > Henrik, what do you think? Do we have enough of these packages under > > control that a VFAD is overkill? Or is there benefit in having one? I > > would love to get to next week with basically everything done on v7 :) > > What worries me mostly for koji timeplan is the toolchain. It's pretty > core to getting things running and there is currently no eta on when > thechanges in these will get cleaned up and/or merged mainline. There is > also a slight worry that there may be regressions in gcc updates. > > gcc, glibc, java-*, ecj. > > Then there is rpm & yum, but dgilmore should be ontop of those I think. > > > Most of the other stuff are pretty trivial, but still requires some > effort to get done. > > plus that there quite likely still is F15 packages that is needed for > release but still failing to build. But those can be addressed after > moving to koji I think. > > > What's currently left in the armv7hl repository are: > > (There is bug reports on more packages, but bugzilla currently down for > maintenance) > > stage3-only: > > allegro > ecj > firebird > gdm > graphviz > gtkmm24 (Bug #740790) > libdc1394 (probably Bug #715762) > libgphoto2 (Bug #745081, supposed to be mainline but F15 build failed) > libvpx > perl-Coro > perl-Tk > rrdtool (now in build queue) > u-boot (new package, do not exists in F15) > w3m > > stage4: > > anaconda > gcc > glibc > gypsy > java-1.6.0-openjdk > java-1.5.0-gcj > mysql > ocaml > python-pyblock > pyxf86config > rpm > xulrunner > yum > pl cln belongs here (was accidently listed as haskell/ghc) > haskell/ghc: > > ghc-* > alex > bluetile > cabal-install > cpphs > haddock > happy > kaya > xmonad > > The haskell/ghc changes are not blocking koji and are all trivial > armv7hl arch additions. Mainly waiting for armv5tel to catch up a little > making it meaningful to attempt to bootstrap ghc there, and the koji > builds can start just fine without ghc I think. > > Regards > Henrik > > ___ > arm mailing list > arm@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] U-Boot?
Been a rather intense discussion regarding U-Boot on IRC today, and time for some reflections and a little decision to be taken. In stage3 we do have an u-boot package which provides uboot images for pandaboard, trimslice, beagleboard and some more. The pandaboard requires u-boot on the boot media, while on trimslice the vendor provided u-boot is in reality quite sufficient and stored separately in a nor flash chip. Several (myself included) thinks it would be good if Fedora fully supported some boards, with both kernel & up to date bootloader (u-boot). But u-boot is not a fedora package today and will require both willing maintainers and package review to happen. So time for some questions. Should Fedora for ARM officially support for some well known boards? Do you think Fedora should provide the bootloader for well known boards where the required board support is merged mainline? Do you know anyone who would be willing to help maintain u-boot within Fedora? Should u-boot images then also be provided for boards without a trivial recovery mechanism in case an u-boot update fails? Where there is a risk of creating bricks if the user do not have jtag access to their board. Note: Supporting u-boot on boards without mainline u-boot support is not an option. Regards Henrik ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
> Should Fedora for ARM officially support for some well known boards? I think it's important to have some easy-to-use installer for a few popular (and easy to support) ARM platforms. The rest of the questions are harder to answer ;-) ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On Thu, Oct 13, 2011 at 09:22:51PM +0200, Henrik Nordström wrote: > Been a rather intense discussion regarding U-Boot on IRC today, and time > for some reflections and a little decision to be taken. > > In stage3 we do have an u-boot package which provides uboot images for > pandaboard, trimslice, beagleboard and some more. The pandaboard > requires u-boot on the boot media, while on trimslice the vendor > provided u-boot is in reality quite sufficient and stored separately in > a nor flash chip. > > Several (myself included) thinks it would be good if Fedora fully > supported some boards, with both kernel & up to date bootloader > (u-boot). But u-boot is not a fedora package today and will require both > willing maintainers and package review to happen. > > So time for some questions. > > Should Fedora for ARM officially support for some well known boards? I think that makes sense, it will create a lower entry level for people who want to run Fedora on their ARM device. > Do you think Fedora should provide the bootloader for well known boards > where the required board support is merged mainline? This would be the ultimate goal. But a very clear definition of which boards (and possibly variants) is a must. If a board differs in only one component, the boadloader image may not work (as expected). > Do you know anyone who would be willing to help maintain u-boot within > Fedora? I'm interested and would be able to help, at least for some boards. > Should u-boot images then also be provided for boards without a trivial > recovery mechanism in case an u-boot update fails? Where there is a risk > of creating bricks if the user do not have jtag access to their board. Some way of recovery should be thought about. Maybe chain-load 'our' u-boot image (if possible) and only install it on the flash if it passes some tests. - But that's thinking out loud... > Note: Supporting u-boot on boards without mainline u-boot support is not > an option. Of course not :) Only support what it merged, if we write patches, make sure that upstream accepts them before including them in the package. What about systems that use OpenFirmware or any of the other bootloaders? u-boot is likely the one used most, but we need to keep an eye on other solutions as well, not? Cheers, Niels > > > Regards > Henrik > > ___ > arm mailing list > arm@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F15 ARMv5 Pre-Req's
Hey everyone, If you are participating with moji for the F15v5.0 build, there are some things you should verify first. One requirement for the new glibc.arm0 is the availability of extended attributes on the local file systems. One can test this by running the following commands: # yum install -y acl # mount -o remount,acl / # touch /tmp/asdf # setfacl -m u:mock:rw /tmp/asdf # getfacl /tmp/asdf ... user:mock:rw- ... If this is not available with your given kernel, I have compiled a Linux kernel for the panda board which is (2.6.35, ipv6, ext3 acl/cap) and it is located with the below link: http://scotland.proximity.on.ca/fedora-arm/kernel/panda/uImage Remember to set the acl option in the /etc/fstab file for the root partition. Thanks for working with me in getting moji up and running everyone! Jon. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On 10/13/2011 12:22 PM, Henrik Nordström wrote: > Should Fedora for ARM officially support for some well known boards? I would like to see Fedora ARM installable on popular ARM boards by conventional installation mechanisms (IE, anaconda) without any additional steps necessary. > Do you think Fedora should provide the bootloader for well known boards > where the required board support is merged mainline? If the bootloader is in flash, lets use the bootloader that is provided. If the bootloader needs to come from the OS install, the OS install should provide it. As an example using today's hardware that would mean using the Trimslice's built-in uboot, but providing a uboot for the Pandaboard during install-time. This will hopefully increase Fedora ARM adoption. Assuming somebody is willing to take this maintainership role, is there any objection to the above? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On Thu, 2011-10-13 at 21:22 +0200, Henrik Nordström wrote: > Been a rather intense discussion regarding U-Boot on IRC today, and time > for some reflections and a little decision to be taken. Well, maybe ;) > In stage3 we do have an u-boot package which provides uboot images for > pandaboard, trimslice, beagleboard and some more. The pandaboard > requires u-boot on the boot media, while on trimslice the vendor > provided u-boot is in reality quite sufficient and stored separately in > a nor flash chip. > > Several (myself included) thinks it would be good if Fedora fully > supported some boards, with both kernel & up to date bootloader > (u-boot). But u-boot is not a fedora package today and will require both > willing maintainers and package review to happen. The question is not about supporting "u-boot", it's about supporting "u-boot build for board X". So the package (if indeed it is a package) would be for MLO (x-loader) and u-boot for a specific e.g. TI board because the image has to contain the bootloader. Really, I would rather we find a way to compose images for boards without getting into the u-boot business at all. Hopefully, we can just pull in some plumbing gunk into our image compose and tried it like prebuilt firmware. I don't want us to be in the business of shipping what should be in the firmware just because on some current generation systems we don't really have an alternative. In the future, many systems will boot using UEFI and not have U-Boot, even in the embedded case (this is a *good* thing - U-Boot is lovely and we all have fond memories, but it is a moving target with a million different forks), and we will use GRUB2. That will be a joyous day, but until then, we just need an interim hack solution. > Should Fedora for ARM officially support for some well known boards? Thanks for asking it. I thought we'd already pretty much decided to "support" TrimSlice and PandaBoard/BeagleBoard for example. > Do you think Fedora should provide the bootloader for well known boards > where the required board support is merged mainline? I think we should provide a bootloader, but not firmware. Once the two are (correctly) separated, this will be awesome. Until then, we can provide a pre-built u-boot for specific boards by pulling it in as "firmware". I really don't see the difference between this and pulling in WiFi firmware that is Open Source (but not recompiled). Hopefully we can work with Dennis and others to find a solution that will let us pull in bits during image composes. Perhaps we have a misc. bits package containing pre-built binary u-boot bits for various boards, all appropriately named. We should not have a "u-boot" package. > Do you know anyone who would be willing to help maintain u-boot within > Fedora? I would be willing to help maintain specific board support, not a general u-boot. I would be quite against us shipping "u-boot" :) > Should u-boot images then also be provided for boards without a trivial > recovery mechanism in case an u-boot update fails? Where there is a risk > of creating bricks if the user do not have jtag access to their board. Like I said, I don't think we should be in the business of providing u-boot at all, other than where it is necessary. Otherwise users will think we're going to upgrade the NAND on their perfectly working board to give them a newer u-boot we don't need to give them, and all because there happens to be a newer version available. > Note: Supporting u-boot on boards without mainline u-boot support is not > an option. Again, I don't think we should be in the business of shipping firmware. We should ship some u-boot (or whatever - might be a different firmware) bits for specific targets, preferably pre-built and treated as firmware. I don't really care if it's upstream or not, I care about supporting specific targets if that is what we want to do :) Thanks, Jon. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
tor 2011-10-13 klockan 17:32 -0400 skrev Jon Masters: > The question is not about supporting "u-boot", it's about supporting > "u-boot build for board X". So the package (if indeed it is a package) > would be for MLO (x-loader) and u-boot for a specific e.g. TI board > because the image has to contain the bootloader. Really, I would rather > we find a way to compose images for boards without getting into the > u-boot business at all. Hopefully, we can just pull in some plumbing > gunk into our image compose and tried it like prebuilt firmware. By default Fedora policy we can't distribute boot firmware blobs built by others. It may be possible to get an exception for this, but do not feel right. What we can provide is scripts which enables the user to pull the image together from the needed pieces (even downloading them as needed). > > Should Fedora for ARM officially support for some well known boards? > > Thanks for asking it. I thought we'd already pretty much decided to > "support" TrimSlice and PandaBoard/BeagleBoard for example. Agreed. GuruBox, OpenRD etc should probably be in the list as well, if there is contributors willing to provide the needed details. > I think we should provide a bootloader, but not firmware. Once the two > are (correctly) separated, this will be awesome. Until then, we can > provide a pre-built u-boot for specific boards by pulling it in as > "firmware". I really don't see the difference between this and pulling > in WiFi firmware that is Open Source (but not recompiled). There is a very big difference in which CPU executes the firmware. See the debate around qemu & system firmwares which have left Fedora qemu without support for several targets at the moment even with all the firmwares completely open source. In most cases simply because Fedora lacks the needed cross-compilers for compiling the target system firmware. > > Do you know anyone who would be willing to help maintain u-boot within > > Fedora? > > I would be willing to help maintain specific board support, not a > general u-boot. I would be quite against us shipping "u-boot" :) Ofcoures it won't be a single u-boot for them all, but some u-boot- pacakges. Preferably built from the same master package if possible. Regards Henirk ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On 10/13/2011 02:32 PM, Jon Masters wrote: > Thanks for asking it. I thought we'd already pretty much decided to > "support" TrimSlice and PandaBoard/BeagleBoard for example. That's certainly what we've done with the kernel so far. Let me precede the following by saying I don't think anybody is advocating updating the uboot in flash, so the following is exclusively with regard to systems which store their uboot where Anaconda will want to overwrite. Let's break down the possibilities for how to handle that: 1. Provide no uboot under any circumstances as part of the install. 2. Provide a mechanism that pulls uboot images from a non-Fedora location during install-time if needed for the intended installation target. 3. Provide a mechanism that pulls uboot images from a non-Fedora location during installer image composition, if needed for the intended installation target. 4. Provide certain u-boots as a piece of some firmware package that get put in place at install time, if needed. 5. Provide uboot-panda (etc) rpms that get put in place at install time, if needed. Any of 2-5 are an improvement. What do people favor? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On Thu, Oct 13, 2011 at 5:25 PM, Brendan Conoboy wrote: > On 10/13/2011 02:32 PM, Jon Masters wrote: >> Thanks for asking it. I thought we'd already pretty much decided to >> "support" TrimSlice and PandaBoard/BeagleBoard for example. > > That's certainly what we've done with the kernel so far. > > Let me precede the following by saying I don't think anybody is > advocating updating the uboot in flash, so the following is exclusively > with regard to systems which store their uboot where Anaconda will want > to overwrite. Let's break down the possibilities for how to handle that: > > 1. Provide no uboot under any circumstances as part of the install. > > 2. Provide a mechanism that pulls uboot images from a non-Fedora > location during install-time if needed for the intended installation target. > > 3. Provide a mechanism that pulls uboot images from a non-Fedora > location during installer image composition, if needed for the intended > installation target. adding my 2cents.. I've had good luck with something like 2/3 with my setup_sdcard.sh scripts that i've hosted for the last year.. At sd card generation time, i ping my server at: http://rcn-ee.net/deb/tools/latest/bootloader which contains a list of board -> bootloader files.. So far supporting 4 omap and 2 freescale targets.. and can be updated later in the field.. You might have to define a "board/system" manager to make sure what ever board boot files are posted are valid/work/etc by 3rd parties.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] binutils ld setting the sh_addr field in sections
Hi all, I was revisiting a bug on ARM where systemtap cannot probe kernel modules (http://sourceware.org/bugzilla/show_bug.cgi?id=13022). The linker is setting the sh_addr field for some of the sections. The values for the sh_addr fields look rather odd. I saw this both with fedora ARM fc13 and fc14 binutils ( binutils-2.20.51.0.2-23.fc13.armv5tel and binutils-2.20.51.0.7-8.fc14.armv5tel). I was wondering if there was a reason that ld was setting the sh_addr field for the sections. I looked at the x86_64 and i386 files modules and didn't see the sh_addr set on those. Is ld on ARM doing the right thing here? It seems sh_addr seems to mess up the binary search systemtap uses to find out which section an address is in. -Will ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
El jue, 13-10-2011 a las 23:56 +0200, Henrik Nordström escribió: > tor 2011-10-13 klockan 17:32 -0400 skrev Jon Masters: > > > The question is not about supporting "u-boot", it's about supporting > > "u-boot build for board X". So the package (if indeed it is a package) > > would be for MLO (x-loader) and u-boot for a specific e.g. TI board > > because the image has to contain the bootloader. Really, I would rather > > we find a way to compose images for boards without getting into the > > u-boot business at all. Hopefully, we can just pull in some plumbing > > gunk into our image compose and tried it like prebuilt firmware. > > By default Fedora policy we can't distribute boot firmware blobs built > by others. It may be possible to get an exception for this, but do not > feel right. > > What we can provide is scripts which enables the user to pull the image > together from the needed pieces (even downloading them as needed). > > > > Should Fedora for ARM officially support for some well known boards? > > > > Thanks for asking it. I thought we'd already pretty much decided to > > "support" TrimSlice and PandaBoard/BeagleBoard for example. > > Agreed. > > GuruBox, OpenRD etc should probably be in the list as well, if there is > contributors willing to provide the needed details. > > > I think we should provide a bootloader, but not firmware. Once the two > > are (correctly) separated, this will be awesome. Until then, we can > > provide a pre-built u-boot for specific boards by pulling it in as > > "firmware". I really don't see the difference between this and pulling > > in WiFi firmware that is Open Source (but not recompiled). > > There is a very big difference in which CPU executes the firmware. See > the debate around qemu & system firmwares which have left Fedora qemu > without support for several targets at the moment even with all the > firmwares completely open source. In most cases simply because Fedora > lacks the needed cross-compilers for compiling the target system > firmware. completely different issue we dont support sparc and ppc because the qemu system implementations do not work correctly and don't emulate hardware actually supported by fedora. anyway its been discussed to death already. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
