Re: [fedora-arm] u-boot plans for Fedora 22 ?
[...] Common / widely available dev-boards: Linksprite_pcDuino3_Nano Linksprite_pcDuino3 Linksprite_pcDuino Marsboard_A10 Orangepi (*) Orangepi_mini (*) [...] Hans *) The Orangepi's do not have a dts upstream yet, but we do need to enable them eventually, might just as well do so now. Afaik the orange pi dts is similar to the banana pi one (that is: I have always used the banana pi ones on orange pi for my testing and never noticed an issue). Does this version also already support H3-based devices? (I have an orange pi pro with a H3; can test if needed) Frans ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
Hi, On 05/01/2015 03:56 PM, Dennis Gilmore wrote: Hi, snip I have to take this back, it seems that this build is appending: console=ttyS0,115200 To the kernel cmdline, I've just double-checked and this is not upstream behavior, is this being done by Fedora specific patches ? This breaks kernel output and systemd status messages output on tty0 / the hdmi output, resulting in a blackscreen until gdm starts. As discussed a while back, the proper way to do is set stdout-path in the devicetree to the serial console, then the kernel will automatically make it a second console, next to tty0 and output messages on both, and systemd will output messages and spawn gettys on both too. This in my testing is not working unless i add console=ttySO,115200 to the bootargs I get nothing out at all on the serial port, though in u-boot it had stdin as serial and stdout as vga. what are all the possible options and how should things just work? the current patch is not a regression for Fedora. I want to make things just work for all. Upstream u-boot is already setting stdout-path for all sunxi devices, so from a sunxi pov the appending of console=ttyS0,115200 is a regression. If this is done for some other boards, it would be better to either patch those boards dts files to set stdout-path, or u-boot to set stdout-path rather then appending console=ttyS0,115200 and breaking video output. If you can tell me which specific boards need work here I can whip up a patch (for others to test). We should patch all boards to be the same. but it needs to work. The sunxi boards have a line like this in their upstream include/configs/board.h file: #define OF_STDOUT_PATH /soc/serial@0700:115200 With the correct version of that present and using a 4.0 kernel you should get output on both the serial console and a vga/hdmi out without needing to specify any console= argument. Regards, Hans ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
On 03/21/2015 02:49 PM, Dennis Gilmore wrote: On Saturday, March 21, 2015 03:40:20 PM Hans de Goede wrote: Hi, On 21-03-15 15:21, Hans de Goede wrote: Hi, On 06-03-15 23:50, Peter Robinson wrote: I assume that we will be rebasing u-boot to the just released v2015.01 for F-22? But I was wondering if there is any chance we can jump to v2015.04 ? The reason I'm asking is that things are progressing quite rapidly on the u-boot side, at least with Allwinner SoC support, I've just send a pull-req for v2015.04 with the following highlights: 1) Improved sun6i (A31) support, including support for the A31s variant and automatic assignment of a SoC serial based MAC address for ethernet 2) Full sun8i (A23) support including DRAM controller init and SPL, so now people can boot these boards using a full FOSS solution 3) Many improvement to the graphical console support, automatic selection of the native mode for HDMI/DVI monitors via DDC + EDID, LCD panel support, VGA output support 4) Preparation work for OTG controller support, together with 3) this allows using u-boot on tablets effortlessly. The rest of the OTG support is going upstream through the usb tree And if possible I would like to see this end up in Fedora 22 :) An initial build of 2015.04rc3 will be in rawhide tomorrow, so please test, I've enabled a few extra new devices and I'll be reviewing the rest of the new devices over the next week or so. Please test, once it's settled down and we're fairly certain all the usual suspects haven't regressed we'll move it into F-22 before beta starts to get locked down. I noticed that -rc4 has also been build, so I've given that a test-run on sunxi instead: http://koji.fedoraproject.org/koji/buildinfo?buildID=622061 From a sunxi pov this build looks good. I have to take this back, it seems that this build is appending: console=ttyS0,115200 To the kernel cmdline, I've just double-checked and this is not upstream behavior, is this being done by Fedora specific patches ? This breaks kernel output and systemd status messages output on tty0 / the hdmi output, resulting in a blackscreen until gdm starts. As discussed a while back, the proper way to do is set stdout-path in the devicetree to the serial console, then the kernel will automatically make it a second console, next to tty0 and output messages on both, and systemd will output messages and spawn gettys on both too. Upstream u-boot is already setting stdout-path for all sunxi devices, so from a sunxi pov the appending of console=ttyS0,115200 is a regression. If this is done for some other boards, it would be better to either patch those boards dts files to set stdout-path, or u-boot to set stdout-path rather then appending console=ttyS0,115200 and breaking video output. If you can tell me which specific boards need work here I can whip up a patch (for others to test). I suspect that no other boards are doing so, I was not aware that you had gotten that upstream yet. we will need to drop the patch that automatically adds the console from u-boot. every other system will need to be looked at. This sounds like the behaviour I reported a while back on my Cubies. That is the HDMI blanks out and it is some time before anything appears. All messages only appear on the serial console. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
Hi, On 03/21/2015 02:49 PM, Dennis Gilmore wrote: On Saturday, March 21, 2015 03:40:20 PM Hans de Goede wrote: Hi, On 21-03-15 15:21, Hans de Goede wrote: Hi, On 06-03-15 23:50, Peter Robinson wrote: I assume that we will be rebasing u-boot to the just released v2015.01 for F-22? But I was wondering if there is any chance we can jump to v2015.04 ? The reason I'm asking is that things are progressing quite rapidly on the u-boot side, at least with Allwinner SoC support, I've just send a pull-req for v2015.04 with the following highlights: 1) Improved sun6i (A31) support, including support for the A31s variant and automatic assignment of a SoC serial based MAC address for ethernet 2) Full sun8i (A23) support including DRAM controller init and SPL, so now people can boot these boards using a full FOSS solution 3) Many improvement to the graphical console support, automatic selection of the native mode for HDMI/DVI monitors via DDC + EDID, LCD panel support, VGA output support 4) Preparation work for OTG controller support, together with 3) this allows using u-boot on tablets effortlessly. The rest of the OTG support is going upstream through the usb tree And if possible I would like to see this end up in Fedora 22 :) An initial build of 2015.04rc3 will be in rawhide tomorrow, so please test, I've enabled a few extra new devices and I'll be reviewing the rest of the new devices over the next week or so. Please test, once it's settled down and we're fairly certain all the usual suspects haven't regressed we'll move it into F-22 before beta starts to get locked down. I noticed that -rc4 has also been build, so I've given that a test-run on sunxi instead: http://koji.fedoraproject.org/koji/buildinfo?buildID=622061 From a sunxi pov this build looks good. I have to take this back, it seems that this build is appending: console=ttyS0,115200 To the kernel cmdline, I've just double-checked and this is not upstream behavior, is this being done by Fedora specific patches ? This breaks kernel output and systemd status messages output on tty0 / the hdmi output, resulting in a blackscreen until gdm starts. As discussed a while back, the proper way to do is set stdout-path in the devicetree to the serial console, then the kernel will automatically make it a second console, next to tty0 and output messages on both, and systemd will output messages and spawn gettys on both too. Upstream u-boot is already setting stdout-path for all sunxi devices, so from a sunxi pov the appending of console=ttyS0,115200 is a regression. If this is done for some other boards, it would be better to either patch those boards dts files to set stdout-path, or u-boot to set stdout-path rather then appending console=ttyS0,115200 and breaking video output. If you can tell me which specific boards need work here I can whip up a patch (for others to test). I suspect that no other boards are doing so, I was not aware that you had gotten that upstream yet. For sunxi I've added a patch to u-boot which patches it into the dts as u-boot loads the dts, u-boot already has infrastructure / code for this, so it is just setting a single #define in include/configs/board.h, see: http://git.denx.de/?p=u-boot.git;a=commitdiff;h=f3133962f469a8b6b9ba237ba670f0ca7c88a02e And there are also plans for sunxi to just outright add it to the dts files as shipped with the kernel, so that it will also work with older u-boot versions. we will need to drop the patch that automatically adds the console from u-boot. every other system will need to be looked at. Or wrap it in in #ifndef CONFIG_ARCH_SUNXI as an interim workaround, TBH I was a bit surprised that we're carrying such a patch as what to exactly put on the cmdline differs per board (the ttyS0 name is not the same everywhere), or are you using the 'console' env variable for this ? Anyways at a minimum please wrap the patch automatically adding the console= argument in #ifndef CONFIG_ARCH_SUNXI Note that using stdout-path on devices which have hdmi (or similar video) out is better because it gives a kernel console on both the hdmi and the serial port, either way let me know if you need any help with this. Regards, Hans ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
I assume that we will be rebasing u-boot to the just released v2015.01 for F-22? But I was wondering if there is any chance we can jump to v2015.04 ? The reason I'm asking is that things are progressing quite rapidly on the u-boot side, at least with Allwinner SoC support, I've just send a pull-req for v2015.04 with the following highlights: 1) Improved sun6i (A31) support, including support for the A31s variant and automatic assignment of a SoC serial based MAC address for ethernet 2) Full sun8i (A23) support including DRAM controller init and SPL, so now people can boot these boards using a full FOSS solution 3) Many improvement to the graphical console support, automatic selection of the native mode for HDMI/DVI monitors via DDC + EDID, LCD panel support, VGA output support 4) Preparation work for OTG controller support, together with 3) this allows using u-boot on tablets effortlessly. The rest of the OTG support is going upstream through the usb tree And if possible I would like to see this end up in Fedora 22 :) An initial build of 2015.04rc3 will be in rawhide tomorrow, so please test, I've enabled a few extra new devices and I'll be reviewing the rest of the new devices over the next week or so. Please test, once it's settled down and we're fairly certain all the usual suspects haven't regressed we'll move it into F-22 before beta starts to get locked down. I noticed that -rc4 has also been build, so I've given that a test-run on sunxi instead: http://koji.fedoraproject.org/koji/buildinfo?buildID=622061 It's not headed to F-22 just yet as there's an issues with distro boot for a few devices (likely I've screwed up the patch rebase for i.MX6/TI devices. Once that's confirmed as fixed I'll pull it back for F-22 too. From a sunxi pov this build looks good. Talking about enabling extra boards, from a sunxi pov I would like to see the following enabled: Most of those were on my todo list :) Common / widely available dev-boards: Linksprite_pcDuino3_Nano Linksprite_pcDuino3 Linksprite_pcDuino Marsboard_A10 Orangepi (*) Orangepi_mini (*) Common / widely used top set boxes: CSQ_CS908 Mele_I7 Mele_M5 Mele_M9 ba10_tv_box i12-tvbox Common / widely used hdmi sticks: mk802_a10s mk802 mk802ii This leaves some special dev boards (official allwinner devkits mostly), some uncommon top set boxes / hdmi sticks, and a bunch of tablets. I would like to eventually enable tablets, but atm without otg support being upstream they are not really usable yet. Once we have the tablets usable, we should probably just do a grep in configs/_defconfig for SUNXI and just enable all of them to avoid having to manually keep a list. I'm fine with switching to such a grep right away. Got a patch for me to look at? Regards, Hans *) The Orangepi's do not have a dts upstream yet, but we do need to enable them eventually, might just as well do so now. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
Hi, On 21-03-15 15:32, Peter Robinson wrote: I assume that we will be rebasing u-boot to the just released v2015.01 for F-22? But I was wondering if there is any chance we can jump to v2015.04 ? The reason I'm asking is that things are progressing quite rapidly on the u-boot side, at least with Allwinner SoC support, I've just send a pull-req for v2015.04 with the following highlights: 1) Improved sun6i (A31) support, including support for the A31s variant and automatic assignment of a SoC serial based MAC address for ethernet 2) Full sun8i (A23) support including DRAM controller init and SPL, so now people can boot these boards using a full FOSS solution 3) Many improvement to the graphical console support, automatic selection of the native mode for HDMI/DVI monitors via DDC + EDID, LCD panel support, VGA output support 4) Preparation work for OTG controller support, together with 3) this allows using u-boot on tablets effortlessly. The rest of the OTG support is going upstream through the usb tree And if possible I would like to see this end up in Fedora 22 :) An initial build of 2015.04rc3 will be in rawhide tomorrow, so please test, I've enabled a few extra new devices and I'll be reviewing the rest of the new devices over the next week or so. Please test, once it's settled down and we're fairly certain all the usual suspects haven't regressed we'll move it into F-22 before beta starts to get locked down. I noticed that -rc4 has also been build, so I've given that a test-run on sunxi instead: http://koji.fedoraproject.org/koji/buildinfo?buildID=622061 It's not headed to F-22 just yet as there's an issues with distro boot for a few devices (likely I've screwed up the patch rebase for i.MX6/TI devices. Once that's confirmed as fixed I'll pull it back for F-22 too. From a sunxi pov this build looks good. Talking about enabling extra boards, from a sunxi pov I would like to see the following enabled: Most of those were on my todo list :) Common / widely available dev-boards: Linksprite_pcDuino3_Nano Linksprite_pcDuino3 Linksprite_pcDuino Marsboard_A10 Orangepi (*) Orangepi_mini (*) Common / widely used top set boxes: CSQ_CS908 Mele_I7 Mele_M5 Mele_M9 ba10_tv_box i12-tvbox Common / widely used hdmi sticks: mk802_a10s mk802 mk802ii This leaves some special dev boards (official allwinner devkits mostly), some uncommon top set boxes / hdmi sticks, and a bunch of tablets. I would like to eventually enable tablets, but atm without otg support being upstream they are not really usable yet. Once we have the tablets usable, we should probably just do a grep in configs/_defconfig for SUNXI and just enable all of them to avoid having to manually keep a list. I'm fine with switching to such a grep right away. Got a patch for me to look at? Nope I've not looked at the Fedora u-boot specfile at all, but generating the list is simple, this command will output all the sunxi defconfig files: grep -rl ARCH_SUNXI configs Regards, Hans ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
Hi, On 06-03-15 23:50, Peter Robinson wrote: I assume that we will be rebasing u-boot to the just released v2015.01 for F-22? But I was wondering if there is any chance we can jump to v2015.04 ? The reason I'm asking is that things are progressing quite rapidly on the u-boot side, at least with Allwinner SoC support, I've just send a pull-req for v2015.04 with the following highlights: 1) Improved sun6i (A31) support, including support for the A31s variant and automatic assignment of a SoC serial based MAC address for ethernet 2) Full sun8i (A23) support including DRAM controller init and SPL, so now people can boot these boards using a full FOSS solution 3) Many improvement to the graphical console support, automatic selection of the native mode for HDMI/DVI monitors via DDC + EDID, LCD panel support, VGA output support 4) Preparation work for OTG controller support, together with 3) this allows using u-boot on tablets effortlessly. The rest of the OTG support is going upstream through the usb tree And if possible I would like to see this end up in Fedora 22 :) An initial build of 2015.04rc3 will be in rawhide tomorrow, so please test, I've enabled a few extra new devices and I'll be reviewing the rest of the new devices over the next week or so. Please test, once it's settled down and we're fairly certain all the usual suspects haven't regressed we'll move it into F-22 before beta starts to get locked down. I noticed that -rc4 has also been build, so I've given that a test-run on sunxi instead: http://koji.fedoraproject.org/koji/buildinfo?buildID=622061 From a sunxi pov this build looks good. Talking about enabling extra boards, from a sunxi pov I would like to see the following enabled: Common / widely available dev-boards: Linksprite_pcDuino3_Nano Linksprite_pcDuino3 Linksprite_pcDuino Marsboard_A10 Orangepi (*) Orangepi_mini (*) Common / widely used top set boxes: CSQ_CS908 Mele_I7 Mele_M5 Mele_M9 ba10_tv_box i12-tvbox Common / widely used hdmi sticks: mk802_a10s mk802 mk802ii This leaves some special dev boards (official allwinner devkits mostly), some uncommon top set boxes / hdmi sticks, and a bunch of tablets. I would like to eventually enable tablets, but atm without otg support being upstream they are not really usable yet. Once we have the tablets usable, we should probably just do a grep in configs/_defconfig for SUNXI and just enable all of them to avoid having to manually keep a list. I'm fine with switching to such a grep right away. Regards, Hans *) The Orangepi's do not have a dts upstream yet, but we do need to enable them eventually, might just as well do so now. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
Hi, On 21-03-15 15:21, Hans de Goede wrote: Hi, On 06-03-15 23:50, Peter Robinson wrote: I assume that we will be rebasing u-boot to the just released v2015.01 for F-22? But I was wondering if there is any chance we can jump to v2015.04 ? The reason I'm asking is that things are progressing quite rapidly on the u-boot side, at least with Allwinner SoC support, I've just send a pull-req for v2015.04 with the following highlights: 1) Improved sun6i (A31) support, including support for the A31s variant and automatic assignment of a SoC serial based MAC address for ethernet 2) Full sun8i (A23) support including DRAM controller init and SPL, so now people can boot these boards using a full FOSS solution 3) Many improvement to the graphical console support, automatic selection of the native mode for HDMI/DVI monitors via DDC + EDID, LCD panel support, VGA output support 4) Preparation work for OTG controller support, together with 3) this allows using u-boot on tablets effortlessly. The rest of the OTG support is going upstream through the usb tree And if possible I would like to see this end up in Fedora 22 :) An initial build of 2015.04rc3 will be in rawhide tomorrow, so please test, I've enabled a few extra new devices and I'll be reviewing the rest of the new devices over the next week or so. Please test, once it's settled down and we're fairly certain all the usual suspects haven't regressed we'll move it into F-22 before beta starts to get locked down. I noticed that -rc4 has also been build, so I've given that a test-run on sunxi instead: http://koji.fedoraproject.org/koji/buildinfo?buildID=622061 From a sunxi pov this build looks good. I have to take this back, it seems that this build is appending: console=ttyS0,115200 To the kernel cmdline, I've just double-checked and this is not upstream behavior, is this being done by Fedora specific patches ? This breaks kernel output and systemd status messages output on tty0 / the hdmi output, resulting in a blackscreen until gdm starts. As discussed a while back, the proper way to do is set stdout-path in the devicetree to the serial console, then the kernel will automatically make it a second console, next to tty0 and output messages on both, and systemd will output messages and spawn gettys on both too. Upstream u-boot is already setting stdout-path for all sunxi devices, so from a sunxi pov the appending of console=ttyS0,115200 is a regression. If this is done for some other boards, it would be better to either patch those boards dts files to set stdout-path, or u-boot to set stdout-path rather then appending console=ttyS0,115200 and breaking video output. If you can tell me which specific boards need work here I can whip up a patch (for others to test). Regards, Hans ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
On Saturday, March 21, 2015 03:40:20 PM Hans de Goede wrote: Hi, On 21-03-15 15:21, Hans de Goede wrote: Hi, On 06-03-15 23:50, Peter Robinson wrote: I assume that we will be rebasing u-boot to the just released v2015.01 for F-22? But I was wondering if there is any chance we can jump to v2015.04 ? The reason I'm asking is that things are progressing quite rapidly on the u-boot side, at least with Allwinner SoC support, I've just send a pull-req for v2015.04 with the following highlights: 1) Improved sun6i (A31) support, including support for the A31s variant and automatic assignment of a SoC serial based MAC address for ethernet 2) Full sun8i (A23) support including DRAM controller init and SPL, so now people can boot these boards using a full FOSS solution 3) Many improvement to the graphical console support, automatic selection of the native mode for HDMI/DVI monitors via DDC + EDID, LCD panel support, VGA output support 4) Preparation work for OTG controller support, together with 3) this allows using u-boot on tablets effortlessly. The rest of the OTG support is going upstream through the usb tree And if possible I would like to see this end up in Fedora 22 :) An initial build of 2015.04rc3 will be in rawhide tomorrow, so please test, I've enabled a few extra new devices and I'll be reviewing the rest of the new devices over the next week or so. Please test, once it's settled down and we're fairly certain all the usual suspects haven't regressed we'll move it into F-22 before beta starts to get locked down. I noticed that -rc4 has also been build, so I've given that a test-run on sunxi instead: http://koji.fedoraproject.org/koji/buildinfo?buildID=622061 From a sunxi pov this build looks good. I have to take this back, it seems that this build is appending: console=ttyS0,115200 To the kernel cmdline, I've just double-checked and this is not upstream behavior, is this being done by Fedora specific patches ? This breaks kernel output and systemd status messages output on tty0 / the hdmi output, resulting in a blackscreen until gdm starts. As discussed a while back, the proper way to do is set stdout-path in the devicetree to the serial console, then the kernel will automatically make it a second console, next to tty0 and output messages on both, and systemd will output messages and spawn gettys on both too. Upstream u-boot is already setting stdout-path for all sunxi devices, so from a sunxi pov the appending of console=ttyS0,115200 is a regression. If this is done for some other boards, it would be better to either patch those boards dts files to set stdout-path, or u-boot to set stdout-path rather then appending console=ttyS0,115200 and breaking video output. If you can tell me which specific boards need work here I can whip up a patch (for others to test). I suspect that no other boards are doing so, I was not aware that you had gotten that upstream yet. we will need to drop the patch that automatically adds the console from u-boot. every other system will need to be looked at. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
I assume that we will be rebasing u-boot to the just released v2015.01 for F-22? But I was wondering if there is any chance we can jump to v2015.04 ? The reason I'm asking is that things are progressing quite rapidly on the u-boot side, at least with Allwinner SoC support, I've just send a pull-req for v2015.04 with the following highlights: 1) Improved sun6i (A31) support, including support for the A31s variant and automatic assignment of a SoC serial based MAC address for ethernet 2) Full sun8i (A23) support including DRAM controller init and SPL, so now people can boot these boards using a full FOSS solution 3) Many improvement to the graphical console support, automatic selection of the native mode for HDMI/DVI monitors via DDC + EDID, LCD panel support, VGA output support 4) Preparation work for OTG controller support, together with 3) this allows using u-boot on tablets effortlessly. The rest of the OTG support is going upstream through the usb tree And if possible I would like to see this end up in Fedora 22 :) An initial build of 2015.04rc3 will be in rawhide tomorrow, so please test, I've enabled a few extra new devices and I'll be reviewing the rest of the new devices over the next week or so. Please test, once it's settled down and we're fairly certain all the usual suspects haven't regressed we'll move it into F-22 before beta starts to get locked down. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
I assume that we will be rebasing u-boot to the just released v2015.01 for F-22? But I was wondering if there is any chance we can jump to v2015.04 ? The reason I'm asking is that things are progressing quite rapidly on the u-boot side, at least with Allwinner SoC support, I've just send a pull-req for v2015.04 with the following highlights: Given 2015.01 is already built for F-22 I think that would be a safe bet ;-). 2015.04 is a possibility and not certain yet, will be much easier to tell once that make it to rc1, I've been watching the mailing list and we're aware of things being proposed. It depends on how much other fall out there is between now and release candidate stage. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 13 Nov 2014 09:14:19 -0500 Adam Goode a...@spicenitz.org wrote: Works great for me! Thanks. Does anyone have a beaglebone white? I'm still worried that this fix will break that board. Adam I tested on my beaglebone white before i submitted the update. it works fine. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUZp1UAAoJEH7ltONmPFDRhYgQAKPpoPMK6WykAtL0afBTe4BR LWdCFwks9AH6EZDzwKmdvD57FfYbNdCx1dkwzzDEDdzm8eBMJmoaaX8FztZupNCc IAWj2QT08rwoYbBg2EXiHApesR4nDMhYEb6O7HUMW4Ok3E2J8/E7jKEi+XxO7qCa 7Vi/8tWqPgicVQaJaVjecY6IR162cSGYYw+rTdW7MRnAFaNwYqvDRpQhFxclQv9w Y+eUxbB4EyIlUL3kyF8PJaVJ4EKDMqALB/dd9b9Kr47pHOW79coEoS41jJs28fGN M53owMb0AgUpBrFm9MrlAcm0WUv2e/gRggLJl6o4P7o+YKa4TODRjUnzPLsFSeM8 FQMHuFPph76lBK0FZ9liYb9lK5WY/LU7q89IOT53665UlLY07SPxiIqfNS8QpHcW cWW7Sf6m/894dGiXBX3iXJUbaCvwqJCxo7L/mXe0lpdvTr1iADXOjmX/lsYyZDwH Y/faVXLVJpU2Rkb8vzfimlFnrzu5YbsWnyK0QHHgPknbNfLTHXvy7t7/ZYbUZ57D YIg5vx4aJSMGgkdtrJddTCaGgnFro/Taxtb0wo/G2C1XpJLU3b4yHDTEWymyjxnF TGGuTxZHIjWSCJm9w/vdWJO5/R449I6gKhLnhjeVJUtcSgqjTSrHX0mOSPMZBPH3 IJwbFZisk79ewvcqS6aB =/2R2 -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
Hi Adam, Problem should now be fixed with -5 Can you test and provide karma so we can get it in GA. https://admin.fedoraproject.org/updates/FEDORA-2014-14716/uboot-tools-2014.10-5.fc21 On Tue, Oct 28, 2014 at 12:37 AM, Adam Goode a...@spicenitz.org wrote: This is still present with -3. It looks like this version of U-Boot is not capable of booting from the internal eMMC on beaglebone black. U-Boot SPL 2014.10-g4647503-dirty (Oct 24 2014 - 16:47:41) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### I found at least another thread about this issue, from version 2014.07: https://www.mail-archive.com/meta-ti@yoctoproject.org/msg04279.html Adam On Fri, Oct 24, 2014 at 1:21 PM, Peter Robinson pbrobin...@gmail.com wrote: A minor bug and is fixed in uboot-tools-2014.10-3.fc21 Peter On Sat, Oct 18, 2014 at 9:04 PM, Adam Goode a...@spicenitz.org wrote: Hopefully I did something wrong, but it's not working at all for me on the beaglebone black: Here is what I get when I try to boot from eMMC: U-Boot SPL 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### Here is what I get when I make a new SD card from the latest minimal image: U-Boot 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) Watchdog enabled I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Error - No Valid Environment Area found *** Warning - bad CRC, using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Card did not respond to voltage select! Booting from nand ... no devices available no devices available Bad Linux ARM zImage magic! When I am in the uboot command processor, I cannot select the internal eMMC at all: U-Boot# mmc dev 1 Card did not respond to voltage select! Previously, I was booting with no problems from either eMMC or SD with F21. Thanks, Adam On Wed, Oct 15, 2014 at 6:34 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Just a heads up that the u-boot 2014.10 GA is on it's way to Fedora 21. https://admin.fedoraproject.org/updates/uboot-tools-2014.10-1.fc21 This release contains numerous fixes and improvements over the currently shipping release including, but by no means limited to: * Upstream generic distro support (huge thanks to Dennis Gilmore and Steven Warren for their tireless work to get this upstream * AllWinner suppport for A10*/A13/A20 devices (huge thanks to Hans for this tireless work on this) * Numerous other improvements too long to name. New devices that we now enable in this release, in no particular order, include: AllWinner: A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino_MICRO Bananapi Cubieboard Cubieboard2 Cubietruck Mele_A1000 Mele_A1000G Mini-X Mini-X-1Gb Tegra: jetson-tk1 i.MX6 cm_fx6 (Utilite) riotboard It's not yet in nightly builds but I'm going to request it for the next Beta TC compose. Known issues: * Panda is not yet ported to generic distro support Please test and provide feedback. Peter ___ 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
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
Works great for me! Thanks. Does anyone have a beaglebone white? I'm still worried that this fix will break that board. Adam On Thu, Nov 13, 2014 at 7:13 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi Adam, Problem should now be fixed with -5 Can you test and provide karma so we can get it in GA. https://admin.fedoraproject.org/updates/FEDORA-2014-14716/uboot-tools-2014.10-5.fc21 On Tue, Oct 28, 2014 at 12:37 AM, Adam Goode a...@spicenitz.org wrote: This is still present with -3. It looks like this version of U-Boot is not capable of booting from the internal eMMC on beaglebone black. U-Boot SPL 2014.10-g4647503-dirty (Oct 24 2014 - 16:47:41) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### I found at least another thread about this issue, from version 2014.07: https://www.mail-archive.com/meta-ti@yoctoproject.org/msg04279.html Adam On Fri, Oct 24, 2014 at 1:21 PM, Peter Robinson pbrobin...@gmail.com wrote: A minor bug and is fixed in uboot-tools-2014.10-3.fc21 Peter On Sat, Oct 18, 2014 at 9:04 PM, Adam Goode a...@spicenitz.org wrote: Hopefully I did something wrong, but it's not working at all for me on the beaglebone black: Here is what I get when I try to boot from eMMC: U-Boot SPL 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### Here is what I get when I make a new SD card from the latest minimal image: U-Boot 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) Watchdog enabled I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Error - No Valid Environment Area found *** Warning - bad CRC, using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Card did not respond to voltage select! Booting from nand ... no devices available no devices available Bad Linux ARM zImage magic! When I am in the uboot command processor, I cannot select the internal eMMC at all: U-Boot# mmc dev 1 Card did not respond to voltage select! Previously, I was booting with no problems from either eMMC or SD with F21. Thanks, Adam On Wed, Oct 15, 2014 at 6:34 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Just a heads up that the u-boot 2014.10 GA is on it's way to Fedora 21. https://admin.fedoraproject.org/updates/uboot-tools-2014.10-1.fc21 This release contains numerous fixes and improvements over the currently shipping release including, but by no means limited to: * Upstream generic distro support (huge thanks to Dennis Gilmore and Steven Warren for their tireless work to get this upstream * AllWinner suppport for A10*/A13/A20 devices (huge thanks to Hans for this tireless work on this) * Numerous other improvements too long to name. New devices that we now enable in this release, in no particular order, include: AllWinner: A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino_MICRO Bananapi Cubieboard Cubieboard2 Cubietruck Mele_A1000 Mele_A1000G Mini-X Mini-X-1Gb Tegra: jetson-tk1 i.MX6 cm_fx6 (Utilite) riotboard It's not yet in nightly builds but I'm going to request it for the next Beta TC compose. Known issues: * Panda is not yet ported to generic distro support Please test and provide feedback. Peter ___ 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
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
W dniu 13.11.2014 o 15:14, Adam Goode pisze: Works great for me! Thanks. Does anyone have a beaglebone white? I'm still worried that this fix will break that board. I did not followed thread but have working BBW somewhere. can you point me to SD card image which I can use to test? ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
If you follow these instructions, you can make an SD card: https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#Scripted Adam On Thu, Nov 13, 2014 at 11:08 AM, Marcin Juszkiewicz mjuszkiew...@redhat.com wrote: W dniu 13.11.2014 o 15:14, Adam Goode pisze: Works great for me! Thanks. Does anyone have a beaglebone white? I'm still worried that this fix will break that board. I did not followed thread but have working BBW somewhere. can you point me to SD card image which I can use to test? ___ 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
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
- Original Message - Works great for me! Thanks. Does anyone have a beaglebone white? I'm still worried that this fix will break that board. Works okay on the Beaglebone White using the F21 TC1 Minimal image. Hit a couple of errors at the beginning, but the system came up fine. U-Boot SPL 2014.10 (Nov 11 2014 - 07:35:06) No AC power, disabling frequency switch MMC: block number 0x100 exceeds max(0x0) MMC: block number 0x200 exceeds max(0x0) *** Error - No Valid Environment Area found Using default environment ... Paul Adam On Thu, Nov 13, 2014 at 7:13 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi Adam, Problem should now be fixed with -5 Can you test and provide karma so we can get it in GA. https://admin.fedoraproject.org/updates/FEDORA-2014-14716/uboot-tools-2014.10-5.fc21 On Tue, Oct 28, 2014 at 12:37 AM, Adam Goode a...@spicenitz.org wrote: This is still present with -3. It looks like this version of U-Boot is not capable of booting from the internal eMMC on beaglebone black. U-Boot SPL 2014.10-g4647503-dirty (Oct 24 2014 - 16:47:41) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### I found at least another thread about this issue, from version 2014.07: https://www.mail-archive.com/meta-ti@yoctoproject.org/msg04279.html Adam On Fri, Oct 24, 2014 at 1:21 PM, Peter Robinson pbrobin...@gmail.com wrote: A minor bug and is fixed in uboot-tools-2014.10-3.fc21 Peter On Sat, Oct 18, 2014 at 9:04 PM, Adam Goode a...@spicenitz.org wrote: Hopefully I did something wrong, but it's not working at all for me on the beaglebone black: Here is what I get when I try to boot from eMMC: U-Boot SPL 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### Here is what I get when I make a new SD card from the latest minimal image: U-Boot 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) Watchdog enabled I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Error - No Valid Environment Area found *** Warning - bad CRC, using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Card did not respond to voltage select! Booting from nand ... no devices available no devices available Bad Linux ARM zImage magic! When I am in the uboot command processor, I cannot select the internal eMMC at all: U-Boot# mmc dev 1 Card did not respond to voltage select! Previously, I was booting with no problems from either eMMC or SD with F21. Thanks, Adam On Wed, Oct 15, 2014 at 6:34 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Just a heads up that the u-boot 2014.10 GA is on it's way to Fedora 21. https://admin.fedoraproject.org/updates/uboot-tools-2014.10-1.fc21 This release contains numerous fixes and improvements over the currently shipping release including, but by no means limited to: * Upstream generic distro support (huge thanks to Dennis Gilmore and Steven Warren for their tireless work to get this upstream * AllWinner suppport for A10*/A13/A20 devices (huge thanks to Hans for this tireless work on this) * Numerous other improvements too long to name. New devices that we now enable in this release, in no particular order, include: AllWinner: A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino_MICRO Bananapi Cubieboard Cubieboard2 Cubietruck Mele_A1000 Mele_A1000G Mini-X Mini-X-1Gb Tegra: jetson-tk1 i.MX6 cm_fx6 (Utilite) riotboard It's not yet in nightly builds but I'm going to request it for the next Beta TC compose. Known issues: * Panda is not yet ported to generic distro support Please test and provide feedback. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
This is still present with -3. It looks like this version of U-Boot is not capable of booting from the internal eMMC on beaglebone black. U-Boot SPL 2014.10-g4647503-dirty (Oct 24 2014 - 16:47:41) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### I found at least another thread about this issue, from version 2014.07: https://www.mail-archive.com/meta-ti@yoctoproject.org/msg04279.html Adam On Fri, Oct 24, 2014 at 1:21 PM, Peter Robinson pbrobin...@gmail.com wrote: A minor bug and is fixed in uboot-tools-2014.10-3.fc21 Peter On Sat, Oct 18, 2014 at 9:04 PM, Adam Goode a...@spicenitz.org wrote: Hopefully I did something wrong, but it's not working at all for me on the beaglebone black: Here is what I get when I try to boot from eMMC: U-Boot SPL 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### Here is what I get when I make a new SD card from the latest minimal image: U-Boot 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) Watchdog enabled I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Error - No Valid Environment Area found *** Warning - bad CRC, using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Card did not respond to voltage select! Booting from nand ... no devices available no devices available Bad Linux ARM zImage magic! When I am in the uboot command processor, I cannot select the internal eMMC at all: U-Boot# mmc dev 1 Card did not respond to voltage select! Previously, I was booting with no problems from either eMMC or SD with F21. Thanks, Adam On Wed, Oct 15, 2014 at 6:34 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Just a heads up that the u-boot 2014.10 GA is on it's way to Fedora 21. https://admin.fedoraproject.org/updates/uboot-tools-2014.10-1.fc21 This release contains numerous fixes and improvements over the currently shipping release including, but by no means limited to: * Upstream generic distro support (huge thanks to Dennis Gilmore and Steven Warren for their tireless work to get this upstream * AllWinner suppport for A10*/A13/A20 devices (huge thanks to Hans for this tireless work on this) * Numerous other improvements too long to name. New devices that we now enable in this release, in no particular order, include: AllWinner: A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino_MICRO Bananapi Cubieboard Cubieboard2 Cubietruck Mele_A1000 Mele_A1000G Mini-X Mini-X-1Gb Tegra: jetson-tk1 i.MX6 cm_fx6 (Utilite) riotboard It's not yet in nightly builds but I'm going to request it for the next Beta TC compose. Known issues: * Panda is not yet ported to generic distro support Please test and provide feedback. Peter ___ 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
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
On Mon, Oct 27, 2014 at 7:37 PM, Adam Goode a...@spicenitz.org wrote: This is still present with -3. It looks like this version of U-Boot is not capable of booting from the internal eMMC on beaglebone black. U-Boot SPL 2014.10-g4647503-dirty (Oct 24 2014 - 16:47:41) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### Which config did you guys build against for 2014.10, i had to do this small change to get the eMMC to also work: https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.10/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L40 diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index 2e5aeaa..4cc7e19 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -1,5 +1,4 @@ CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS=NAND -CONFIG_CONS_INDEX=1 +CONFIG_SYS_EXTRA_OPTIONS=SERIAL1,CONS_INDEX=1 +S:CONFIG_ARM=y +S:CONFIG_TARGET_AM335X_EVM=y Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
A minor bug and is fixed in uboot-tools-2014.10-3.fc21 Peter On Sat, Oct 18, 2014 at 9:04 PM, Adam Goode a...@spicenitz.org wrote: Hopefully I did something wrong, but it's not working at all for me on the beaglebone black: Here is what I get when I try to boot from eMMC: U-Boot SPL 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### Here is what I get when I make a new SD card from the latest minimal image: U-Boot 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) Watchdog enabled I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Error - No Valid Environment Area found *** Warning - bad CRC, using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Card did not respond to voltage select! Booting from nand ... no devices available no devices available Bad Linux ARM zImage magic! When I am in the uboot command processor, I cannot select the internal eMMC at all: U-Boot# mmc dev 1 Card did not respond to voltage select! Previously, I was booting with no problems from either eMMC or SD with F21. Thanks, Adam On Wed, Oct 15, 2014 at 6:34 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Just a heads up that the u-boot 2014.10 GA is on it's way to Fedora 21. https://admin.fedoraproject.org/updates/uboot-tools-2014.10-1.fc21 This release contains numerous fixes and improvements over the currently shipping release including, but by no means limited to: * Upstream generic distro support (huge thanks to Dennis Gilmore and Steven Warren for their tireless work to get this upstream * AllWinner suppport for A10*/A13/A20 devices (huge thanks to Hans for this tireless work on this) * Numerous other improvements too long to name. New devices that we now enable in this release, in no particular order, include: AllWinner: A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino_MICRO Bananapi Cubieboard Cubieboard2 Cubietruck Mele_A1000 Mele_A1000G Mini-X Mini-X-1Gb Tegra: jetson-tk1 i.MX6 cm_fx6 (Utilite) riotboard It's not yet in nightly builds but I'm going to request it for the next Beta TC compose. Known issues: * Panda is not yet ported to generic distro support Please test and provide feedback. Peter ___ 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
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
On 2014-10-24 12:21, Peter Robinson wrote: A minor bug and is fixed in uboot-tools-2014.10-3.fc21 Does this also fix booting on the Pandaboard? http://fpaste.org/144729/ -- Yaakov Selkowitz Associate Software Engineer, ARM Red Hat, Inc. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
On Fri, Oct 24, 2014 at 6:31 PM, Yaakov Selkowitz yselk...@redhat.com wrote: On 2014-10-24 12:21, Peter Robinson wrote: A minor bug and is fixed in uboot-tools-2014.10-3.fc21 Does this also fix booting on the Pandaboard? Not yet ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
Hopefully I did something wrong, but it's not working at all for me on the beaglebone black: Here is what I get when I try to boot from eMMC: U-Boot SPL 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### Here is what I get when I make a new SD card from the latest minimal image: U-Boot 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) Watchdog enabled I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Error - No Valid Environment Area found *** Warning - bad CRC, using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Card did not respond to voltage select! Booting from nand ... no devices available no devices available Bad Linux ARM zImage magic! When I am in the uboot command processor, I cannot select the internal eMMC at all: U-Boot# mmc dev 1 Card did not respond to voltage select! Previously, I was booting with no problems from either eMMC or SD with F21. Thanks, Adam On Wed, Oct 15, 2014 at 6:34 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Just a heads up that the u-boot 2014.10 GA is on it's way to Fedora 21. https://admin.fedoraproject.org/updates/uboot-tools-2014.10-1.fc21 This release contains numerous fixes and improvements over the currently shipping release including, but by no means limited to: * Upstream generic distro support (huge thanks to Dennis Gilmore and Steven Warren for their tireless work to get this upstream * AllWinner suppport for A10*/A13/A20 devices (huge thanks to Hans for this tireless work on this) * Numerous other improvements too long to name. New devices that we now enable in this release, in no particular order, include: AllWinner: A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino_MICRO Bananapi Cubieboard Cubieboard2 Cubietruck Mele_A1000 Mele_A1000G Mini-X Mini-X-1Gb Tegra: jetson-tk1 i.MX6 cm_fx6 (Utilite) riotboard It's not yet in nightly builds but I'm going to request it for the next Beta TC compose. Known issues: * Panda is not yet ported to generic distro support Please test and provide feedback. Peter ___ 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
Re: [fedora-arm] U-boot plan for F-21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 30 May 2014 15:41:55 +0200 Hans de Goede hdego...@redhat.com wrote: Hi All, Are we going to stay with 2014.04, or are we going to move to 2014.07 ? The main reason I'm asking is because of Allwinner support. Currently we (the linux sunxi community) are making good progress on getting sunxi support into 2014.07, so if we're going to go with that then I'm going to focus on that. But if we're going to stick with 2014.04 then I'll try to prep a patchset on top of what we already have to add support for more boards. We will move to 2014.07 quite possibly also 2014.10 I am just way behind on u-boot work right now. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTiJBlAAoJEH7ltONmPFDRVfkP/2Ru3IeUXIk20tfy1CeW9mN1 KhrkUCsz22iEIh5x9lLtKL9Y82he/K3VmtegADdmlZjC/MzS6tlg30Vdlf9Pqnbw zQP4XwuAqfwJh5R+BBU0d26Ov9AFNlpndOn/7sJOOf9GjKrwwRrlfahSwhrlbba3 O5UcH3uOQccukUW4OwbUx1UwkE/QdS/HN31KhB9H0lEvtpbbNIgolPk9uAO/RKUt vORM99+ivX5xogQ7aN/Be0t6p5EkrvtxsLDR3iU3wh/+bHUnLmMoXKm+3ceA8kjT 0buk7ESo4gHQRgURw1tV/Kb2RQrqVHd2QFl8wce/5O674Cio8IWuljQz0hsI7AGr /uIP0oOtG63dlcw1QewR4+8szK2z6Enje/ehsSv//k9K9aqmsifWebotjqvuH5h8 62xuH957TXlWW83BM3Tkiv3ToilFj085eMZqZSIsm24Clo2a3qqb5kaPum/JSOuO OzOt2jTAFtFNXuqhb+Iz0V+0klomJr5d99Wi9Q3EdweTs6A41L/VVt/1jCYdeRA3 JhRZTEwnnb1O17BUPXNdteNRu/+O9AtSfCNl0TdXITIJKuDbAneV5xucz1izJpY/ gx3n8cXOwPRkSFjrODcNifkVbZtaOEVL5K1wJZIc3BayzmJoB4OMVBdmPlvfJhup fkTKIrNY40L4l/iyMe20 =rlDU -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot update testing
2013/10/21 Dennis Gilmore den...@ausil.us -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I have proposed https://admin.fedoraproject.org/updates/uboot-tools-2013.10-2.fc20 as a blocker for beta I would appreciate as many people testing it as possible and providing karma in bodhi, thanks. Do you have a minimal image to test on Wandboard quad with this updated u-boot? So something closer to Beta than TC2 since TC5 isn't booting for me. Just to share a reference http://fedoraproject.org/wiki/User:Mrunge/Wandboard_quad I've tested the previous build on my AC100 and it worked (despite it's still missing keyboard support in uboot upstream). Thx Nicolas (kwizart) ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
Hi, I'm working on kernel package for ARM devices. It's my bachelor thesis. I have dreamplug, so now im trying to get build dreamplug kernel subpackage. Currently i have problems with configuration, but i'm working on it. After that i'll probably work on beagle board subpackage.. If anybody has any suggestions for me I'll be glad to hear them. Any advice is appreciated. Peter On Fri, Oct 14, 2011 at 11:06 PM, rihowa...@gmail.com rihowa...@gmail.comwrote: On Oct 14, 2011, at 1:07 PM, David A. Marlin wrote: Gordan Bobic wrote: On 10/14/2011 07:05 PM, Brendan Conoboy wrote: On 10/14/2011 10:54 AM, Chris Tyler wrote: Note that the GuruPlug ships with a broken uboot, which uses the wrong machine identifier. To use a mainline kernel, you must munge the kernel machine ID or update the GuruPlug's uboot. The guruplug comes with a very old kernel, as do most if not all of the kirkwood boards, and does a lot of things differently from the mainline kernel. All you have to do is change a couple of uboot parameters to use a mainline kernel and it is well documented. setenv mainlineLinux yes setenv arcNumber where can be found at http://www.arm.linux.org.uk/developer/machines/ for the particular board. The mainline uboot from http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary has support for number of kirkwood boards and more are being added. It is for most people non-trivial to update but there is documentation supplied by the board manufacturers that explains how to do it. I wonder if it would be possible to get the board suppliers to refresh the image they are installing in new items? Ooh, good to know. The phrase the kernel we're working with caught my eye. Which kernel are we talking about? I'm specifically thinking of David Marlin's kernel as referenced here: http://fedoraproject.org/wiki/Architectures/Fedora_ARM_Kernels (I've heard but have not verified that the Kirkwood and OMAP patch sets used to be pretty much mutually-exclusive; I haven't tried to build a unified kernel and hope this has been fixed). Yuck. I know David has been endeavoring to make his changes mesh easily with additional parties adding their own pet board to the SRPM. Most of our systems are omap and tegra based so we haven't seriously looked into kirkwood support. If somebody wants to add kirkwood support they should bear in mind your warning about the broken uboot. I'm pretty sure that Kirkwood support required for the SheevaPlug has been in mainline since at least 2.6.35, possibly earlier. Whether OMAP patches break this, I don't know. Krkwood support for multiple boards is available in the mainline code. The following is what is supported in 3.0.3 :- CONFIG_MACH_DB88F6281_BP=y CONFIG_MACH_RD88F6192_NAS=y CONFIG_MACH_RD88F6281=y CONFIG_MACH_MV88F6281GTW_GE=y CONFIG_MACH_SHEEVAPLUG=y CONFIG_MACH_ESATA_SHEEVAPLUG=y CONFIG_MACH_GURUPLUG=y CONFIG_MACH_TS219=y CONFIG_MACH_TS41X=y CONFIG_MACH_DOCKSTAR=y CONFIG_MACH_OPENRD=y CONFIG_MACH_OPENRD_BASE=y CONFIG_MACH_OPENRD_CLIENT=y CONFIG_MACH_OPENRD_ULTIMATE=y CONFIG_MACH_NETSPACE_V2=y CONFIG_MACH_INETSPACE_V2=y CONFIG_MACH_NETSPACE_MAX_V2=y CONFIG_MACH_D2NET_V2=y CONFIG_MACH_NET2BIG_V2=y CONFIG_MACH_NET5BIG_V2=y CONFIG_MACH_T5325=y I have noticed that some changes to OMAP continue to go into the mainline ARM kernel source tree and tegra is very active at the moment. There has been some work to add support for additional kirkwood boards. See http://lists.infradead.org/mailman/listinfo/linux-arm-kernel In fact, Kirkwood is one of the few SoCs that has complete support for all of the extras, too, in the mainline kernel, too (e.g. crypto engine). Someone built a 2.6.39 kernel for kirkwood (Dreamplug) by adding a couple of patches to one of my earlier kernel SRPMs (which was also tested on Panda/OMAP), but when we tried it on a 2.6.40 (3.0-based) kernel SRPM the resultant image failed to boot. I can probably dig up those packages if anyone who has a kirkwood system wants to work on it. d.marlin = ___ 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 -- :wq ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On Sun, Oct 16, 2011 at 9:33 AM, peter kotvan peter.kot...@gmail.com wrote: Hi, I'm working on kernel package for ARM devices. It's my bachelor thesis. I have dreamplug, so now im trying to get build dreamplug kernel subpackage. Currently i have problems with configuration, but i'm working on it. After that i'll probably work on beagle board subpackage.. There is already support for OMAP (including the beagle board) and tegra upstream in the mainline fedora kernels http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=29653 If anybody has any suggestions for me I'll be glad to hear them. Any advice is appreciated. I suggest cloning the fedora kernel package git and checking out dgilmore's patches that added omap and tegra kernels and base your patches on that. Like the omap patch we should be able to get a single kernel to support all the Marvell based plug computers. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
DJ Delorie d...@redhat.com writes: 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 ;-) Do we have a list of popular (and easy to support) ARM platform? Would this include e.g. the SheevaPlug, GuruPlug, and/or DreamPlug kirkwood-based devices? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On 10/14/2011 07:20 AM, Derek Atkins wrote: Do we have a list of popular (and easy to support) ARM platform? Would this include e.g. the SheevaPlug, GuruPlug, and/or DreamPlug kirkwood-based devices? In the context of the discussion, it appears the Dreamplug (And presumably earlier plugs) keep their uboot in flash, so they are a non-issue for uboot inclusion. They're certainly popular devices and if somebody wants to add kirkwood support to the kernel we're working with that would be a wonderful addition. -- 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 Fri, 2011-10-14 at 10:15 -0700, Brendan Conoboy wrote: On 10/14/2011 07:20 AM, Derek Atkins wrote: Do we have a list of popular (and easy to support) ARM platform? Would this include e.g. the SheevaPlug, GuruPlug, and/or DreamPlug kirkwood-based devices? In the context of the discussion, it appears the Dreamplug (And presumably earlier plugs) keep their uboot in flash, so they are a non-issue for uboot inclusion. Note that the GuruPlug ships with a broken uboot, which uses the wrong machine identifier. To use a mainline kernel, you must munge the kernel machine ID or update the GuruPlug's uboot. They're certainly popular devices and if somebody wants to add kirkwood support to the kernel we're working with that would be a wonderful addition. The phrase the kernel we're working with caught my eye. Which kernel are we talking about? (I've heard but have not verified that the Kirkwood and OMAP patch sets used to be pretty much mutually-exclusive; I haven't tried to build a unified kernel and hope this has been fixed). -Chris ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On 10/14/2011 10:54 AM, Chris Tyler wrote: Note that the GuruPlug ships with a broken uboot, which uses the wrong machine identifier. To use a mainline kernel, you must munge the kernel machine ID or update the GuruPlug's uboot. Ooh, good to know. The phrase the kernel we're working with caught my eye. Which kernel are we talking about? I'm specifically thinking of David Marlin's kernel as referenced here: http://fedoraproject.org/wiki/Architectures/Fedora_ARM_Kernels (I've heard but have not verified that the Kirkwood and OMAP patch sets used to be pretty much mutually-exclusive; I haven't tried to build a unified kernel and hope this has been fixed). Yuck. I know David has been endeavoring to make his changes mesh easily with additional parties adding their own pet board to the SRPM. Most of our systems are omap and tegra based so we haven't seriously looked into kirkwood support. If somebody wants to add kirkwood support they should bear in mind your warning about the broken uboot. -- 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 10/14/2011 07:05 PM, Brendan Conoboy wrote: On 10/14/2011 10:54 AM, Chris Tyler wrote: Note that the GuruPlug ships with a broken uboot, which uses the wrong machine identifier. To use a mainline kernel, you must munge the kernel machine ID or update the GuruPlug's uboot. Ooh, good to know. The phrase the kernel we're working with caught my eye. Which kernel are we talking about? I'm specifically thinking of David Marlin's kernel as referenced here: http://fedoraproject.org/wiki/Architectures/Fedora_ARM_Kernels (I've heard but have not verified that the Kirkwood and OMAP patch sets used to be pretty much mutually-exclusive; I haven't tried to build a unified kernel and hope this has been fixed). Yuck. I know David has been endeavoring to make his changes mesh easily with additional parties adding their own pet board to the SRPM. Most of our systems are omap and tegra based so we haven't seriously looked into kirkwood support. If somebody wants to add kirkwood support they should bear in mind your warning about the broken uboot. I'm pretty sure that Kirkwood support required for the SheevaPlug has been in mainline since at least 2.6.35, possibly earlier. Whether OMAP patches break this, I don't know. In fact, Kirkwood is one of the few SoCs that has complete support for all of the extras, too, in the mainline kernel, too (e.g. crypto engine). Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
Gordan Bobic wrote: On 10/14/2011 07:05 PM, Brendan Conoboy wrote: On 10/14/2011 10:54 AM, Chris Tyler wrote: Note that the GuruPlug ships with a broken uboot, which uses the wrong machine identifier. To use a mainline kernel, you must munge the kernel machine ID or update the GuruPlug's uboot. Ooh, good to know. The phrase the kernel we're working with caught my eye. Which kernel are we talking about? I'm specifically thinking of David Marlin's kernel as referenced here: http://fedoraproject.org/wiki/Architectures/Fedora_ARM_Kernels (I've heard but have not verified that the Kirkwood and OMAP patch sets used to be pretty much mutually-exclusive; I haven't tried to build a unified kernel and hope this has been fixed). Yuck. I know David has been endeavoring to make his changes mesh easily with additional parties adding their own pet board to the SRPM. Most of our systems are omap and tegra based so we haven't seriously looked into kirkwood support. If somebody wants to add kirkwood support they should bear in mind your warning about the broken uboot. I'm pretty sure that Kirkwood support required for the SheevaPlug has been in mainline since at least 2.6.35, possibly earlier. Whether OMAP patches break this, I don't know. In fact, Kirkwood is one of the few SoCs that has complete support for all of the extras, too, in the mainline kernel, too (e.g. crypto engine). Someone built a 2.6.39 kernel for kirkwood (Dreamplug) by adding a couple of patches to one of my earlier kernel SRPMs (which was also tested on Panda/OMAP), but when we tried it on a 2.6.40 (3.0-based) kernel SRPM the resultant image failed to boot. I can probably dig up those packages if anyone who has a kirkwood system wants to work on it. d.marlin = ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
On Oct 14, 2011, at 1:07 PM, David A. Marlin wrote: Gordan Bobic wrote: On 10/14/2011 07:05 PM, Brendan Conoboy wrote: On 10/14/2011 10:54 AM, Chris Tyler wrote: Note that the GuruPlug ships with a broken uboot, which uses the wrong machine identifier. To use a mainline kernel, you must munge the kernel machine ID or update the GuruPlug's uboot. The guruplug comes with a very old kernel, as do most if not all of the kirkwood boards, and does a lot of things differently from the mainline kernel. All you have to do is change a couple of uboot parameters to use a mainline kernel and it is well documented. setenv mainlineLinux yes setenv arcNumber where can be found at http://www.arm.linux.org.uk/developer/machines/ for the particular board. The mainline uboot from http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary has support for number of kirkwood boards and more are being added. It is for most people non-trivial to update but there is documentation supplied by the board manufacturers that explains how to do it. I wonder if it would be possible to get the board suppliers to refresh the image they are installing in new items? Ooh, good to know. The phrase the kernel we're working with caught my eye. Which kernel are we talking about? I'm specifically thinking of David Marlin's kernel as referenced here: http://fedoraproject.org/wiki/Architectures/Fedora_ARM_Kernels (I've heard but have not verified that the Kirkwood and OMAP patch sets used to be pretty much mutually-exclusive; I haven't tried to build a unified kernel and hope this has been fixed). Yuck. I know David has been endeavoring to make his changes mesh easily with additional parties adding their own pet board to the SRPM. Most of our systems are omap and tegra based so we haven't seriously looked into kirkwood support. If somebody wants to add kirkwood support they should bear in mind your warning about the broken uboot. I'm pretty sure that Kirkwood support required for the SheevaPlug has been in mainline since at least 2.6.35, possibly earlier. Whether OMAP patches break this, I don't know. Krkwood support for multiple boards is available in the mainline code. The following is what is supported in 3.0.3 :- CONFIG_MACH_DB88F6281_BP=y CONFIG_MACH_RD88F6192_NAS=y CONFIG_MACH_RD88F6281=y CONFIG_MACH_MV88F6281GTW_GE=y CONFIG_MACH_SHEEVAPLUG=y CONFIG_MACH_ESATA_SHEEVAPLUG=y CONFIG_MACH_GURUPLUG=y CONFIG_MACH_TS219=y CONFIG_MACH_TS41X=y CONFIG_MACH_DOCKSTAR=y CONFIG_MACH_OPENRD=y CONFIG_MACH_OPENRD_BASE=y CONFIG_MACH_OPENRD_CLIENT=y CONFIG_MACH_OPENRD_ULTIMATE=y CONFIG_MACH_NETSPACE_V2=y CONFIG_MACH_INETSPACE_V2=y CONFIG_MACH_NETSPACE_MAX_V2=y CONFIG_MACH_D2NET_V2=y CONFIG_MACH_NET2BIG_V2=y CONFIG_MACH_NET5BIG_V2=y CONFIG_MACH_T5325=y I have noticed that some changes to OMAP continue to go into the mainline ARM kernel source tree and tegra is very active at the moment. There has been some work to add support for additional kirkwood boards. See http://lists.infradead.org/mailman/listinfo/linux-arm-kernel In fact, Kirkwood is one of the few SoCs that has complete support for all of the extras, too, in the mainline kernel, too (e.g. crypto engine). Someone built a 2.6.39 kernel for kirkwood (Dreamplug) by adding a couple of patches to one of my earlier kernel SRPMs (which was also tested on Panda/OMAP), but when we tried it on a 2.6.40 (3.0-based) kernel SRPM the resultant image failed to boot. I can probably dig up those packages if anyone who has a kirkwood system wants to work on it. d.marlin = ___ 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
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 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?
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?
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
