[opensuse-arm] Network interface not coming up at boot time on CuBox
One thing I've been noticing on the CuBox is that, at each reboot, the network interface is not brought up. Strangely, the system tries to set up ethX where X increments by one at each reboot. For example, I now see the following in /var/log/boot.log: network[398]: Setting up (localfs) network interfaces: network[398]: lo network[398]: lo IP address: 127.0.0.1/8 network[398]: ..done eth4 network[398]: No configuration found for eth4 network[398]: ..unusedWaiting for mandatory devices: eth0 network[398]: 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 [...] network[398]: eth0 No interface found network[398]: ..failed The last time, eth3 was involved; before that eth2. Next time it will be eth5. In yast (network settings), there were two interfaces - eth0 and eth4 (not configured). I deleted eth0 and configured eth4 (basically just set it to dhcp rather than static). After saving, the network was back up again. Any idea what is causing this? Ciaran -- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26.11.2012, at 17:20, Ciaran Farrell wrote:
One thing I've been noticing on the CuBox is that, at each reboot, the network interface is not brought up. Strangely, the system tries to set up ethX where X increments by one at each reboot. For example, I now see the following in /var/log/boot.log:
network[398]: Setting up (localfs) network interfaces: network[398]: lo network[398]: lo IP address: 127.0.0.1/8 network[398]: ..done eth4 network[398]: No configuration found for eth4 network[398]: ..unusedWaiting for mandatory devices: eth0 network[398]: 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 [...] network[398]: eth0 No interface found network[398]: ..failed
The last time, eth3 was involved; before that eth2. Next time it will be eth5.
In yast (network settings), there were two interfaces - eth0 and eth4 (not configured). I deleted eth0 and configured eth4 (basically just set it to dhcp rather than static). After saving, the network was back up again.
Any idea what is causing this?
Is the mac address changing across reboots? Alex
Ciaran
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26/11/12 17:20, Alexander Graf wrote:
On 26.11.2012, at 17:20, Ciaran Farrell wrote:
One thing I've been noticing on the CuBox is that, at each reboot, the network interface is not brought up. Strangely, the system tries to set up ethX where X increments by one at each reboot. For example, I now see the following in /var/log/boot.log:
network[398]: Setting up (localfs) network interfaces: network[398]: lo network[398]: lo IP address: 127.0.0.1/8 network[398]: ..done eth4 network[398]: No configuration found for eth4 network[398]: ..unusedWaiting for mandatory devices: eth0 network[398]: 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 [...] network[398]: eth0 No interface found network[398]: ..failed
The last time, eth3 was involved; before that eth2. Next time it will be eth5.
In yast (network settings), there were two interfaces - eth0 and eth4 (not configured). I deleted eth0 and configured eth4 (basically just set it to dhcp rather than static). After saving, the network was back up again.
Any idea what is causing this? Is the mac address changing across reboots? Yes - you nailed it. Just checked now and: 00:50:43:5C:17:04 (before reboot) 00:50:43:e2:36:17 (after reboot)
What is causing this? Seems like a strange configuration option to have -or is it a bug? Ciaran
Alex
Ciaran
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
El 26/11/12 13:28, Ciaran Farrell escribió:
On 26/11/12 17:20, Alexander Graf wrote:
On 26.11.2012, at 17:20, Ciaran Farrell wrote:
Any idea what is causing this?
https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
El 26/11/12 13:54, Cristian Rodríguez escribió:
El 26/11/12 13:28, Ciaran Farrell escribió:
On 26/11/12 17:20, Alexander Graf wrote:
On 26.11.2012, at 17:20, Ciaran Farrell wrote:
Any idea what is causing this?
https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219...
In short you need to have the latest u-boot from solidrun, dated Oct 3. http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon, 26 Nov 2012 16:15:33 -0300 "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote:
El 26/11/12 13:54, Cristian Rodríguez escribió:
El 26/11/12 13:28, Ciaran Farrell escribió:
On 26/11/12 17:20, Alexander Graf wrote:
On 26.11.2012, at 17:20, Ciaran Farrell wrote:
Any idea what is causing this?
https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219...
In short you need to have the latest u-boot from solidrun, dated Oct 3.
http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc...
During the initial boot, the one where the initrd resizes the partitions, it modifies u-boot environment variables and then tries to save them. Something goes wrong. On subsequent boots u-boot finds a bad checksum in the saved environment variables and uses default values. That causes it to generate a random MAC address for the ethernet adapter. Udev, finding a new MAC address, assigns it a new device name. The immediate solution is to enter a "saveenv" command to u-boot. It will then have a good checksum and won't create a new MAC address every time. Then you have to fix your udev rules in /etc/udev/rules.d/70-persistent-net.rules Somebody smarter then me will have to figure out what goes wrong during that fix boot. Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26/11/12 20:51, Bill Merriam wrote:
On Mon, 26 Nov 2012 16:15:33 -0300 "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote:
El 26/11/12 13:54, Cristian Rodríguez escribió:
El 26/11/12 13:28, Ciaran Farrell escribió:
On 26/11/12 17:20, Alexander Graf wrote:
On 26.11.2012, at 17:20, Ciaran Farrell wrote:
Any idea what is causing this? https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219...
In short you need to have the latest u-boot from solidrun, dated Oct 3.
http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc...
During the initial boot, the one where the initrd resizes the partitions, it modifies u-boot environment variables and then tries to save them. Something goes wrong. On subsequent boots u-boot finds a bad checksum in the saved environment variables and uses default values. That causes it to generate a random MAC address for the ethernet adapter. Udev, finding a new MAC address, assigns it a new device name.
The immediate solution is to enter a "saveenv" command to u-boot. It will then have a good checksum and won't create a new MAC address every time. Then you have to fix your udev rules in /etc/udev/rules.d/70-persistent-net.rules Could the resetenv in the uboot-setup script be causing this? I put it in there because it appeared to have helped me boot at all at first, but now I'm beginning to think it nukes the MAC address as well...
Ciaran
Somebody smarter then me will have to figure out what goes wrong during that fix boot.
Bill
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26.11.2012, at 21:17, Ciaran Farrell wrote:
On 26/11/12 20:51, Bill Merriam wrote:
On Mon, 26 Nov 2012 16:15:33 -0300 "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote:
El 26/11/12 13:54, Cristian Rodríguez escribió:
El 26/11/12 13:28, Ciaran Farrell escribió:
On 26/11/12 17:20, Alexander Graf wrote:
On 26.11.2012, at 17:20, Ciaran Farrell wrote:
> Any idea what is causing this? https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219...
In short you need to have the latest u-boot from solidrun, dated Oct 3.
http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc...
During the initial boot, the one where the initrd resizes the partitions, it modifies u-boot environment variables and then tries to save them. Something goes wrong. On subsequent boots u-boot finds a bad checksum in the saved environment variables and uses default values. That causes it to generate a random MAC address for the ethernet adapter. Udev, finding a new MAC address, assigns it a new device name.
The immediate solution is to enter a "saveenv" command to u-boot. It will then have a good checksum and won't create a new MAC address every time. Then you have to fix your udev rules in /etc/udev/rules.d/70-persistent-net.rules Could the resetenv in the uboot-setup script be causing this? I put it in there because it appeared to have helped me boot at all at first, but now I'm beginning to think it nukes the MAC address as well...
I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :) Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26/11/12 21:21, Alexander Graf wrote:
On 26.11.2012, at 21:17, Ciaran Farrell wrote:
On 26/11/12 20:51, Bill Merriam wrote:
On Mon, 26 Nov 2012 16:15:33 -0300 "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote:
El 26/11/12 13:54, Cristian Rodríguez escribió:
El 26/11/12 13:28, Ciaran Farrell escribió:
On 26/11/12 17:20, Alexander Graf wrote: > On 26.11.2012, at 17:20, Ciaran Farrell wrote: > >> Any idea what is causing this? https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219...
In short you need to have the latest u-boot from solidrun, dated Oct 3.
http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc...
During the initial boot, the one where the initrd resizes the partitions, it modifies u-boot environment variables and then tries to save them. Something goes wrong. On subsequent boots u-boot finds a bad checksum in the saved environment variables and uses default values. That causes it to generate a random MAC address for the ethernet adapter. Udev, finding a new MAC address, assigns it a new device name.
The immediate solution is to enter a "saveenv" command to u-boot. It will then have a good checksum and won't create a new MAC address every time. Then you have to fix your udev rules in /etc/udev/rules.d/70-persistent-net.rules Could the resetenv in the uboot-setup script be causing this? I put it in there because it appeared to have helped me boot at all at first, but now I'm beginning to think it nukes the MAC address as well... I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :)
Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling. What would prevent me from taking your version (it boots into yast2-firstboot, by the way - I'm still configuring there, so I'll still need to see what happens after the first reboot), removing the resetenv and sr'ing?
Ciaran
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26.11.2012, at 21:23, Ciaran Farrell wrote:
On 26/11/12 21:21, Alexander Graf wrote:
On 26.11.2012, at 21:17, Ciaran Farrell wrote:
On 26/11/12 20:51, Bill Merriam wrote:
On Mon, 26 Nov 2012 16:15:33 -0300 "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote:
El 26/11/12 13:54, Cristian Rodríguez escribió:
El 26/11/12 13:28, Ciaran Farrell escribió: > On 26/11/12 17:20, Alexander Graf wrote: >> On 26.11.2012, at 17:20, Ciaran Farrell wrote: >> >>> Any idea what is causing this? https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219...
In short you need to have the latest u-boot from solidrun, dated Oct 3.
http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc...
During the initial boot, the one where the initrd resizes the partitions, it modifies u-boot environment variables and then tries to save them. Something goes wrong. On subsequent boots u-boot finds a bad checksum in the saved environment variables and uses default values. That causes it to generate a random MAC address for the ethernet adapter. Udev, finding a new MAC address, assigns it a new device name.
The immediate solution is to enter a "saveenv" command to u-boot. It will then have a good checksum and won't create a new MAC address every time. Then you have to fix your udev rules in /etc/udev/rules.d/70-persistent-net.rules Could the resetenv in the uboot-setup script be causing this? I put it in there because it appeared to have helped me boot at all at first, but now I'm beginning to think it nukes the MAC address as well... I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :)
Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling. What would prevent me from taking your version (it boots into yast2-firstboot, by the way - I'm still configuring there, so I'll still need to see what happens after the first reboot), removing the resetenv and sr'ing?
That would work too, but the former version was tested on a lot of boards and known to work, while the "short script" that's there now is not. So chances are higher more things break again later. However, I consider contrib machines responsibilities of the respective contrib maintainers, so in this case that would be Max's call. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26/11/12 21:26, Alexander Graf wrote:
On 26.11.2012, at 21:23, Ciaran Farrell wrote:
On 26/11/12 21:21, Alexander Graf wrote:
On 26.11.2012, at 21:17, Ciaran Farrell wrote:
On 26/11/12 20:51, Bill Merriam wrote:
On Mon, 26 Nov 2012 16:15:33 -0300 "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote:
El 26/11/12 13:54, Cristian Rodríguez escribió: > El 26/11/12 13:28, Ciaran Farrell escribió: >> On 26/11/12 17:20, Alexander Graf wrote: >>> On 26.11.2012, at 17:20, Ciaran Farrell wrote: >>> >>>> Any idea what is causing this? > https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219... > > > In short you need to have the latest u-boot from solidrun, dated Oct 3.
http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc...
During the initial boot, the one where the initrd resizes the partitions, it modifies u-boot environment variables and then tries to save them. Something goes wrong. On subsequent boots u-boot finds a bad checksum in the saved environment variables and uses default values. That causes it to generate a random MAC address for the ethernet adapter. Udev, finding a new MAC address, assigns it a new device name.
The immediate solution is to enter a "saveenv" command to u-boot. It will then have a good checksum and won't create a new MAC address every time. Then you have to fix your udev rules in /etc/udev/rules.d/70-persistent-net.rules Could the resetenv in the uboot-setup script be causing this? I put it in there because it appeared to have helped me boot at all at first, but now I'm beginning to think it nukes the MAC address as well... I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :)
Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling. What would prevent me from taking your version (it boots into yast2-firstboot, by the way - I'm still configuring there, so I'll still need to see what happens after the first reboot), removing the resetenv and sr'ing? That would work too, but the former version was tested on a lot of boards and known to work, while the "short script" that's there now is not. So chances are higher more things break again later.
However, I consider contrib machines responsibilities of the respective contrib maintainers, so in this case that would be Max's call. Ok, understood. I'll try to mess around based on the original version and see what happens. I still haven't updated uboot on my CuBox - I'll hold off doing that for awhile to see if we can get the original generic code working.
Ciaran
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26.11.2012, at 21:28, Ciaran Farrell wrote:
On 26/11/12 21:26, Alexander Graf wrote:
On 26.11.2012, at 21:23, Ciaran Farrell wrote:
On 26/11/12 21:21, Alexander Graf wrote:
On 26.11.2012, at 21:17, Ciaran Farrell wrote:
On 26/11/12 20:51, Bill Merriam wrote:
On Mon, 26 Nov 2012 16:15:33 -0300 "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote:
> El 26/11/12 13:54, Cristian Rodríguez escribió: >> El 26/11/12 13:28, Ciaran Farrell escribió: >>> On 26/11/12 17:20, Alexander Graf wrote: >>>> On 26.11.2012, at 17:20, Ciaran Farrell wrote: >>>> >>>>> Any idea what is causing this? >> https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219... >> >> >> > In short you need to have the latest u-boot from solidrun, dated Oct > 3. > > http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc... > During the initial boot, the one where the initrd resizes the partitions, it modifies u-boot environment variables and then tries to save them. Something goes wrong. On subsequent boots u-boot finds a bad checksum in the saved environment variables and uses default values. That causes it to generate a random MAC address for the ethernet adapter. Udev, finding a new MAC address, assigns it a new device name.
The immediate solution is to enter a "saveenv" command to u-boot. It will then have a good checksum and won't create a new MAC address every time. Then you have to fix your udev rules in /etc/udev/rules.d/70-persistent-net.rules Could the resetenv in the uboot-setup script be causing this? I put it in there because it appeared to have helped me boot at all at first, but now I'm beginning to think it nukes the MAC address as well... I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :)
Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling. What would prevent me from taking your version (it boots into yast2-firstboot, by the way - I'm still configuring there, so I'll still need to see what happens after the first reboot), removing the resetenv and sr'ing? That would work too, but the former version was tested on a lot of boards and known to work, while the "short script" that's there now is not. So chances are higher more things break again later.
However, I consider contrib machines responsibilities of the respective contrib maintainers, so in this case that would be Max's call. Ok, understood. I'll try to mess around based on the original version and see what happens. I still haven't updated uboot on my CuBox - I'll hold off doing that for awhile to see if we can get the original generic code working.
Another benefit of the original code was that it was almost identical to the one we use for generic platforms in Factory and 12.2. That means integration into the main project becomes easier later on :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26/11/12 21:29, Alexander Graf wrote:
On 26.11.2012, at 21:28, Ciaran Farrell wrote:
On 26/11/12 21:26, Alexander Graf wrote:
On 26.11.2012, at 21:23, Ciaran Farrell wrote:
On 26/11/12 21:21, Alexander Graf wrote:
On 26.11.2012, at 21:17, Ciaran Farrell wrote:
On 26/11/12 20:51, Bill Merriam wrote: > On Mon, 26 Nov 2012 16:15:33 -0300 > "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote: > >> El 26/11/12 13:54, Cristian Rodríguez escribió: >>> El 26/11/12 13:28, Ciaran Farrell escribió: >>>> On 26/11/12 17:20, Alexander Graf wrote: >>>>> On 26.11.2012, at 17:20, Ciaran Farrell wrote: >>>>> >>>>>> Any idea what is causing this? >>> https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219... >>> >>> >>> >> In short you need to have the latest u-boot from solidrun, dated Oct >> 3. >> >> http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc... >> > During the initial boot, the one where the initrd resizes the > partitions, it modifies u-boot environment variables and then tries to > save them. Something goes wrong. On subsequent boots u-boot finds a > bad checksum in the saved environment variables and uses default > values. That causes it to generate a random MAC address for the > ethernet adapter. Udev, finding a new MAC address, assigns it a new > device name. > > The immediate solution is to enter a "saveenv" command to u-boot. It > will then have a good checksum and won't create a new MAC address every > time. Then you have to fix your udev rules > in /etc/udev/rules.d/70-persistent-net.rules Could the resetenv in the uboot-setup script be causing this? I put it in there because it appeared to have helped me boot at all at first, but now I'm beginning to think it nukes the MAC address as well... I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :)
Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling. What would prevent me from taking your version (it boots into yast2-firstboot, by the way - I'm still configuring there, so I'll still need to see what happens after the first reboot), removing the resetenv and sr'ing? That would work too, but the former version was tested on a lot of boards and known to work, while the "short script" that's there now is not. So chances are higher more things break again later.
However, I consider contrib machines responsibilities of the respective contrib maintainers, so in this case that would be Max's call. Ok, understood. I'll try to mess around based on the original version and see what happens. I still haven't updated uboot on my CuBox - I'll hold off doing that for awhile to see if we can get the original generic code working. Another benefit of the original code was that it was almost identical to the one we use for generic platforms in Factory and 12.2. That means integration into the main project becomes easier later on :). I created sr#142958 to revert to revision 11. If somebody with the appropriate permission could check and approve that, it would be great.
Ciaran
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26.11.2012, at 21:34, Ciaran Farrell wrote:
On 26/11/12 21:29, Alexander Graf wrote:
On 26.11.2012, at 21:28, Ciaran Farrell wrote:
On 26/11/12 21:26, Alexander Graf wrote:
On 26.11.2012, at 21:23, Ciaran Farrell wrote:
On 26/11/12 21:21, Alexander Graf wrote:
On 26.11.2012, at 21:17, Ciaran Farrell wrote:
> On 26/11/12 20:51, Bill Merriam wrote: >> On Mon, 26 Nov 2012 16:15:33 -0300 >> "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote: >> >>> El 26/11/12 13:54, Cristian Rodríguez escribió: >>>> El 26/11/12 13:28, Ciaran Farrell escribió: >>>>> On 26/11/12 17:20, Alexander Graf wrote: >>>>>> On 26.11.2012, at 17:20, Ciaran Farrell wrote: >>>>>> >>>>>>> Any idea what is causing this? >>>> https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219... >>>> >>>> >>>> >>> In short you need to have the latest u-boot from solidrun, dated Oct >>> 3. >>> >>> http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc... >>> >> During the initial boot, the one where the initrd resizes the >> partitions, it modifies u-boot environment variables and then tries to >> save them. Something goes wrong. On subsequent boots u-boot finds a >> bad checksum in the saved environment variables and uses default >> values. That causes it to generate a random MAC address for the >> ethernet adapter. Udev, finding a new MAC address, assigns it a new >> device name. >> >> The immediate solution is to enter a "saveenv" command to u-boot. It >> will then have a good checksum and won't create a new MAC address every >> time. Then you have to fix your udev rules >> in /etc/udev/rules.d/70-persistent-net.rules > Could the resetenv in the uboot-setup script be causing this? I put it > in there because it appeared to have helped me boot at all at first, but > now I'm beginning to think it nukes the MAC address as well... I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :)
Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling. What would prevent me from taking your version (it boots into yast2-firstboot, by the way - I'm still configuring there, so I'll still need to see what happens after the first reboot), removing the resetenv and sr'ing? That would work too, but the former version was tested on a lot of boards and known to work, while the "short script" that's there now is not. So chances are higher more things break again later.
However, I consider contrib machines responsibilities of the respective contrib maintainers, so in this case that would be Max's call. Ok, understood. I'll try to mess around based on the original version and see what happens. I still haven't updated uboot on my CuBox - I'll hold off doing that for awhile to see if we can get the original generic code working. Another benefit of the original code was that it was almost identical to the one we use for generic platforms in Factory and 12.2. That means integration into the main project becomes easier later on :). I created sr#142958 to revert to revision 11. If somebody with the appropriate permission could check and approve that, it would be great.
Could you please create an sr that reverts to 11 plus changes the ramdisk load address to 0x500... in both uboot-image-setup and uboot-setup.tgz/setupUBoot.sh? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26/11/12 21:35, Alexander Graf wrote:
On 26.11.2012, at 21:34, Ciaran Farrell wrote:
On 26/11/12 21:29, Alexander Graf wrote:
On 26.11.2012, at 21:28, Ciaran Farrell wrote:
On 26/11/12 21:26, Alexander Graf wrote:
On 26.11.2012, at 21:23, Ciaran Farrell wrote:
On 26/11/12 21:21, Alexander Graf wrote: > On 26.11.2012, at 21:17, Ciaran Farrell wrote: > >> On 26/11/12 20:51, Bill Merriam wrote: >>> On Mon, 26 Nov 2012 16:15:33 -0300 >>> "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote: >>> >>>> El 26/11/12 13:54, Cristian Rodríguez escribió: >>>>> El 26/11/12 13:28, Ciaran Farrell escribió: >>>>>> On 26/11/12 17:20, Alexander Graf wrote: >>>>>>> On 26.11.2012, at 17:20, Ciaran Farrell wrote: >>>>>>> >>>>>>>> Any idea what is causing this? >>>>> https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219... >>>>> >>>>> >>>>> >>>> In short you need to have the latest u-boot from solidrun, dated Oct >>>> 3. >>>> >>>> http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc... >>>> >>> During the initial boot, the one where the initrd resizes the >>> partitions, it modifies u-boot environment variables and then tries to >>> save them. Something goes wrong. On subsequent boots u-boot finds a >>> bad checksum in the saved environment variables and uses default >>> values. That causes it to generate a random MAC address for the >>> ethernet adapter. Udev, finding a new MAC address, assigns it a new >>> device name. >>> >>> The immediate solution is to enter a "saveenv" command to u-boot. It >>> will then have a good checksum and won't create a new MAC address every >>> time. Then you have to fix your udev rules >>> in /etc/udev/rules.d/70-persistent-net.rules >> Could the resetenv in the uboot-setup script be causing this? I put it >> in there because it appeared to have helped me boot at all at first, but >> now I'm beginning to think it nukes the MAC address as well... > I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :) > > Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling. What would prevent me from taking your version (it boots into yast2-firstboot, by the way - I'm still configuring there, so I'll still need to see what happens after the first reboot), removing the resetenv and sr'ing? That would work too, but the former version was tested on a lot of boards and known to work, while the "short script" that's there now is not. So chances are higher more things break again later.
However, I consider contrib machines responsibilities of the respective contrib maintainers, so in this case that would be Max's call. Ok, understood. I'll try to mess around based on the original version and see what happens. I still haven't updated uboot on my CuBox - I'll hold off doing that for awhile to see if we can get the original generic code working. Another benefit of the original code was that it was almost identical to the one we use for generic platforms in Factory and 12.2. That means integration into the main project becomes easier later on :). I created sr#142958 to revert to revision 11. If somebody with the appropriate permission could check and approve that, it would be great. Could you please create an sr that reverts to 11 plus changes the ramdisk load address to 0x500... in both uboot-image-setup and uboot-setup.tgz/setupUBoot.sh? I just reverted to revision 11 and updated the ramdisk load adderss to 0x500 - now I have the exact same issue as before:
6547890 bytes read ## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux-3.6.0-1.2-cubox Created: 2012-10-18 11:13:02 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3927856 Bytes = 3.7 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 05000000 ... Image Name: Initrd Created: 2012-11-26 21:06:55 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 26547826 Bytes = 25.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. And there it hangs... Ciaran
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
El 26/11/12 18:32, Ciaran Farrell escribió:
6547890 bytes read ## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux-3.6.0-1.2-cubox Created: 2012-10-18 11:13:02 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3927856 Bytes = 3.7 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 05000000 ... Image Name: Initrd Created: 2012-11-26 21:06:55 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 26547826 Bytes = 25.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
And there it hangs...
Now I have the same issue.. wow.. what is going on here.. maybe something else is needed to actually load this monster initrd.. I wonder why it is so big... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27/11/12 19:06, Cristian Rodríguez wrote:
El 26/11/12 18:32, Ciaran Farrell escribió:
6547890 bytes read ## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux-3.6.0-1.2-cubox Created: 2012-10-18 11:13:02 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3927856 Bytes = 3.7 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 05000000 ... Image Name: Initrd Created: 2012-11-26 21:06:55 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 26547826 Bytes = 25.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
And there it hangs...
Now I have the same issue.. wow.. what is going on here.. maybe something else is needed to actually load this monster initrd.. I wonder why it is so big...
This works for me: #!/bin/bash set -x file=boot/boot.script echo 'if itest 1$arcNumber == 13905; then' >> $file echo ' setenv kerneladdr 0x2000000' >> $file echo ' setenv ramdiskaddr 0x5000000' >> $file echo 'fi' >> $file echo 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx' >> $file echo 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot' >> $file echo -n 'setenv bootargs "' >> $file echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file echo 'bootm ${kerneladdr} ${ramdiskaddr}' >> $file echo 'boot' >> $file mkopts="-A arm -O linux -a 0 -e 0 -T script -C none"; inputf="boot/boot.script"; result="boot/boot.scr"; if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then echo "Failed to create uboot script image" exit 1 fi Though methinks agraf will want to belt me on the head for setenv bootargs line. In fairness though, at least the cubox specific stuff is back in its own if box... Ciaran -- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27.11.2012, at 21:30, Ciaran Farrell wrote:
On 27/11/12 19:06, Cristian Rodríguez wrote:
El 26/11/12 18:32, Ciaran Farrell escribió:
6547890 bytes read ## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux-3.6.0-1.2-cubox Created: 2012-10-18 11:13:02 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3927856 Bytes = 3.7 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 05000000 ... Image Name: Initrd Created: 2012-11-26 21:06:55 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 26547826 Bytes = 25.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
And there it hangs...
Now I have the same issue.. wow.. what is going on here.. maybe something else is needed to actually load this monster initrd.. I wonder why it is so big...
This works for me:
#!/bin/bash
set -x
file=boot/boot.script
echo 'if itest 1$arcNumber == 13905; then' >> $file echo ' setenv kerneladdr 0x2000000' >> $file echo ' setenv ramdiskaddr 0x5000000' >> $file echo 'fi' >> $file echo 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx' >> $file echo 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot' >> $file echo -n 'setenv bootargs "' >> $file echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file echo 'bootm ${kerneladdr} ${ramdiskaddr}' >> $file echo 'boot' >> $file mkopts="-A arm -O linux -a 0 -e 0 -T script -C none"; inputf="boot/boot.script"; result="boot/boot.scr"; if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then echo "Failed to create uboot script image" exit 1 fi
Though methinks agraf will want to belt me on the head for setenv bootargs line. In fairness though, at least the cubox specific stuff is back in its own if box...
The setenv gets imported from the .kiwi file. Maybe something's bogus there? What does the actually built boot.script look like? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27/11/12 21:42, Alexander Graf wrote:
On 27.11.2012, at 21:30, Ciaran Farrell wrote:
On 27/11/12 19:06, Cristian Rodríguez wrote:
El 26/11/12 18:32, Ciaran Farrell escribió:
6547890 bytes read ## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux-3.6.0-1.2-cubox Created: 2012-10-18 11:13:02 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3927856 Bytes = 3.7 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 05000000 ... Image Name: Initrd Created: 2012-11-26 21:06:55 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 26547826 Bytes = 25.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
And there it hangs... Now I have the same issue.. wow.. what is going on here.. maybe something else is needed to actually load this monster initrd.. I wonder why it is so big...
This works for me:
#!/bin/bash
set -x
file=boot/boot.script
echo 'if itest 1$arcNumber == 13905; then' >> $file echo ' setenv kerneladdr 0x2000000' >> $file echo ' setenv ramdiskaddr 0x5000000' >> $file echo 'fi' >> $file echo 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx' >> $file echo 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot' >> $file echo -n 'setenv bootargs "' >> $file echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file echo 'bootm ${kerneladdr} ${ramdiskaddr}' >> $file echo 'boot' >> $file mkopts="-A arm -O linux -a 0 -e 0 -T script -C none"; inputf="boot/boot.script"; result="boot/boot.scr"; if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then echo "Failed to create uboot script image" exit 1 fi
Though methinks agraf will want to belt me on the head for setenv bootargs line. In fairness though, at least the cubox specific stuff is back in its own if box... The setenv gets imported from the .kiwi file. Maybe something's bogus there? What does the actually built boot.script look like?
I spoke too soon - it does get past the loading kernel stage where I was bogged down all the time. However, it runs into another problem when booting: [ 22.782759] sdhci-pltfm: SDHCI platform and OF driver helper [ 22.788442] mmc0: no vmmc regulator found [ 22.792729] ata1: SATA link down (SStatus 0 SControl F300) [ 22.831999] mmc0: SDHCI controller on sdhci-dove.0 [sdhci-dove.0] using DMA [ 22.838965] mmc1: no vmmc regulator found [ 22.881992] mmc1: SDHCI controller on sdhci-dove.1 [sdhci-dove.1] using DMA [ 22.888988] zram: num_devices not specified. Using default: 1 [ 22.894721] zram: Creating 1 devices ... [ 22.899705] TCP: cubic registered [ 22.903062] NET: Registered protocol family 10 [ 22.908219] Key type dns_resolver registered [ 22.912543] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 [ 22.920176] ThumbEE CPU extension supported. [ 22.924437] PJ4 iWMMXt coprocessor enabled. [ 22.929047] registered taskstats version 1 [ 22.933353] rtc-mv rtc-mv: setting system clock to 2012-11-27 20:44:00 UTC (1354049040) [ 22.941765] Freeing init memory: 264K [ 22.976707] mmc0: new high speed SDHC card at address aaaa [ 22.985304] mmcblk0: mmc0:aaaa SU04G 3.69 GiB [ 22.998024] mmcblk0: p1 p2 setterm: cannot (un)set powersave mode: Invalid argument /usr/sbin/klogconsole [ 0.831911] Including oem partition info file [ 0.926862] Searching for boot device... [ 18.296347] Failed to find boot device ! [ 18.305829] rebootException: reboot in 120 sec... The boot.script in the /boot section looks like this: setenv ramdisk boot/initrd.uboot setenv kernel boot/linux.vmx setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs loader=uboot console=ttyS0,115200n8 showopts ${append} if itest 1$arcNumber == 13905; then setenv kerneladdr 0x2000000 setenv ramdiskaddr 0x5000000 fi ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p2" bootm ${kerneladdr} ${ramdiskaddr} boot
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27.11.2012, at 21:45, Ciaran Farrell wrote:
On 27/11/12 21:42, Alexander Graf wrote:
On 27.11.2012, at 21:30, Ciaran Farrell wrote:
On 27/11/12 19:06, Cristian Rodríguez wrote:
El 26/11/12 18:32, Ciaran Farrell escribió:
6547890 bytes read ## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux-3.6.0-1.2-cubox Created: 2012-10-18 11:13:02 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3927856 Bytes = 3.7 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 05000000 ... Image Name: Initrd Created: 2012-11-26 21:06:55 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 26547826 Bytes = 25.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
And there it hangs... Now I have the same issue.. wow.. what is going on here.. maybe something else is needed to actually load this monster initrd.. I wonder why it is so big...
This works for me:
#!/bin/bash
set -x
file=boot/boot.script
echo 'if itest 1$arcNumber == 13905; then' >> $file echo ' setenv kerneladdr 0x2000000' >> $file echo ' setenv ramdiskaddr 0x5000000' >> $file echo 'fi' >> $file echo 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx' >> $file echo 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot' >> $file echo -n 'setenv bootargs "' >> $file echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file echo 'bootm ${kerneladdr} ${ramdiskaddr}' >> $file echo 'boot' >> $file mkopts="-A arm -O linux -a 0 -e 0 -T script -C none"; inputf="boot/boot.script"; result="boot/boot.scr"; if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then echo "Failed to create uboot script image" exit 1 fi
Though methinks agraf will want to belt me on the head for setenv bootargs line. In fairness though, at least the cubox specific stuff is back in its own if box... The setenv gets imported from the .kiwi file. Maybe something's bogus there? What does the actually built boot.script look like?
I spoke too soon - it does get past the loading kernel stage where I was bogged down all the time. However, it runs into another problem when booting:
[ 22.782759] sdhci-pltfm: SDHCI platform and OF driver helper [ 22.788442] mmc0: no vmmc regulator found [ 22.792729] ata1: SATA link down (SStatus 0 SControl F300) [ 22.831999] mmc0: SDHCI controller on sdhci-dove.0 [sdhci-dove.0] using DMA [ 22.838965] mmc1: no vmmc regulator found [ 22.881992] mmc1: SDHCI controller on sdhci-dove.1 [sdhci-dove.1] using DMA [ 22.888988] zram: num_devices not specified. Using default: 1 [ 22.894721] zram: Creating 1 devices ... [ 22.899705] TCP: cubic registered [ 22.903062] NET: Registered protocol family 10 [ 22.908219] Key type dns_resolver registered [ 22.912543] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 [ 22.920176] ThumbEE CPU extension supported. [ 22.924437] PJ4 iWMMXt coprocessor enabled. [ 22.929047] registered taskstats version 1 [ 22.933353] rtc-mv rtc-mv: setting system clock to 2012-11-27 20:44:00 UTC (1354049040) [ 22.941765] Freeing init memory: 264K [ 22.976707] mmc0: new high speed SDHC card at address aaaa [ 22.985304] mmcblk0: mmc0:aaaa SU04G 3.69 GiB [ 22.998024] mmcblk0: p1 p2 setterm: cannot (un)set powersave mode: Invalid argument /usr/sbin/klogconsole [ 0.831911] Including oem partition info file [ 0.926862] Searching for boot device... [ 18.296347] Failed to find boot device !
That means the MBR signature that the kiwi initrd searches for does not match the MBR signature of the SD card you have. Have you booted this system before with the kiwi initrd?
[ 18.305829] rebootException: reboot in 120 sec...
The boot.script in the /boot section looks like this:
setenv ramdisk boot/initrd.uboot setenv kernel boot/linux.vmx setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs loader=uboot console=ttyS0,115200n8 showopts ${append}
looks good, no? Is $append set? Alex
if itest 1$arcNumber == 13905; then setenv kerneladdr 0x2000000 setenv ramdiskaddr 0x5000000 fi ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p2" bootm ${kerneladdr} ${ramdiskaddr} boot
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27.11.2012, at 21:45, Ciaran Farrell wrote:
On 27/11/12 21:42, Alexander Graf wrote:
On 27.11.2012, at 21:30, Ciaran Farrell wrote:
On 27/11/12 19:06, Cristian Rodríguez wrote:
El 26/11/12 18:32, Ciaran Farrell escribió:
6547890 bytes read ## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux-3.6.0-1.2-cubox Created: 2012-10-18 11:13:02 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3927856 Bytes = 3.7 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 05000000 ... Image Name: Initrd Created: 2012-11-26 21:06:55 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 26547826 Bytes = 25.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
And there it hangs... Now I have the same issue.. wow.. what is going on here.. maybe something else is needed to actually load this monster initrd.. I wonder why it is so big...
This works for me:
#!/bin/bash
set -x
file=boot/boot.script
echo 'if itest 1$arcNumber == 13905; then' >> $file echo ' setenv kerneladdr 0x2000000' >> $file echo ' setenv ramdiskaddr 0x5000000' >> $file echo 'fi' >> $file echo 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx' >> $file echo 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot' >> $file echo -n 'setenv bootargs "' >> $file echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file echo 'bootm ${kerneladdr} ${ramdiskaddr}' >> $file echo 'boot' >> $file mkopts="-A arm -O linux -a 0 -e 0 -T script -C none"; inputf="boot/boot.script"; result="boot/boot.scr"; if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then echo "Failed to create uboot script image" exit 1 fi
Though methinks agraf will want to belt me on the head for setenv bootargs line. In fairness though, at least the cubox specific stuff is back in its own if box... The setenv gets imported from the .kiwi file. Maybe something's bogus there? What does the actually built boot.script look like? I spoke too soon - it does get past the loading kernel stage where I was bogged down all the time. However, it runs into another problem when booting:
[ 22.782759] sdhci-pltfm: SDHCI platform and OF driver helper [ 22.788442] mmc0: no vmmc regulator found [ 22.792729] ata1: SATA link down (SStatus 0 SControl F300) [ 22.831999] mmc0: SDHCI controller on sdhci-dove.0 [sdhci-dove.0] using DMA [ 22.838965] mmc1: no vmmc regulator found [ 22.881992] mmc1: SDHCI controller on sdhci-dove.1 [sdhci-dove.1] using DMA [ 22.888988] zram: num_devices not specified. Using default: 1 [ 22.894721] zram: Creating 1 devices ... [ 22.899705] TCP: cubic registered [ 22.903062] NET: Registered protocol family 10 [ 22.908219] Key type dns_resolver registered [ 22.912543] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 [ 22.920176] ThumbEE CPU extension supported. [ 22.924437] PJ4 iWMMXt coprocessor enabled. [ 22.929047] registered taskstats version 1 [ 22.933353] rtc-mv rtc-mv: setting system clock to 2012-11-27 20:44:00 UTC (1354049040) [ 22.941765] Freeing init memory: 264K [ 22.976707] mmc0: new high speed SDHC card at address aaaa [ 22.985304] mmcblk0: mmc0:aaaa SU04G 3.69 GiB [ 22.998024] mmcblk0: p1 p2 setterm: cannot (un)set powersave mode: Invalid argument /usr/sbin/klogconsole [ 0.831911] Including oem partition info file [ 0.926862] Searching for boot device... [ 18.296347] Failed to find boot device ! That means the MBR signature that the kiwi initrd searches for does not match the MBR signature of the SD card you have. Have you booted this system before with the kiwi initrd?
[ 18.305829] rebootException: reboot in 120 sec...
The boot.script in the /boot section looks like this:
setenv ramdisk boot/initrd.uboot setenv kernel boot/linux.vmx setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs loader=uboot console=ttyS0,115200n8 showopts ${append} looks good, no? Is $append set? I'll try building the image again without the uboot-image-setup bootargs
On 27/11/12 21:50, Alexander Graf wrote: line. It does seem to be duplicated. Stay tuned. Ciaran
Alex
if itest 1$arcNumber == 13905; then setenv kerneladdr 0x2000000 setenv ramdiskaddr 0x5000000 fi ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p2" bootm ${kerneladdr} ${ramdiskaddr} boot
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27/11/12 21:50, Alexander Graf wrote:
On 27.11.2012, at 21:45, Ciaran Farrell wrote:
On 27/11/12 21:42, Alexander Graf wrote:
On 27.11.2012, at 21:30, Ciaran Farrell wrote:
On 27/11/12 19:06, Cristian Rodríguez wrote:
El 26/11/12 18:32, Ciaran Farrell escribió:
6547890 bytes read ## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux-3.6.0-1.2-cubox Created: 2012-10-18 11:13:02 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3927856 Bytes = 3.7 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 05000000 ... Image Name: Initrd Created: 2012-11-26 21:06:55 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 26547826 Bytes = 25.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
And there it hangs... Now I have the same issue.. wow.. what is going on here.. maybe something else is needed to actually load this monster initrd.. I wonder why it is so big...
This works for me:
#!/bin/bash
set -x
file=boot/boot.script
echo 'if itest 1$arcNumber == 13905; then' >> $file echo ' setenv kerneladdr 0x2000000' >> $file echo ' setenv ramdiskaddr 0x5000000' >> $file echo 'fi' >> $file echo 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx' >> $file echo 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot' >> $file echo -n 'setenv bootargs "' >> $file echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file echo 'bootm ${kerneladdr} ${ramdiskaddr}' >> $file echo 'boot' >> $file mkopts="-A arm -O linux -a 0 -e 0 -T script -C none"; inputf="boot/boot.script"; result="boot/boot.scr"; if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then echo "Failed to create uboot script image" exit 1 fi
Though methinks agraf will want to belt me on the head for setenv bootargs line. In fairness though, at least the cubox specific stuff is back in its own if box... The setenv gets imported from the .kiwi file. Maybe something's bogus there? What does the actually built boot.script look like? I spoke too soon - it does get past the loading kernel stage where I was bogged down all the time. However, it runs into another problem when booting:
[ 22.782759] sdhci-pltfm: SDHCI platform and OF driver helper [ 22.788442] mmc0: no vmmc regulator found [ 22.792729] ata1: SATA link down (SStatus 0 SControl F300) [ 22.831999] mmc0: SDHCI controller on sdhci-dove.0 [sdhci-dove.0] using DMA [ 22.838965] mmc1: no vmmc regulator found [ 22.881992] mmc1: SDHCI controller on sdhci-dove.1 [sdhci-dove.1] using DMA [ 22.888988] zram: num_devices not specified. Using default: 1 [ 22.894721] zram: Creating 1 devices ... [ 22.899705] TCP: cubic registered [ 22.903062] NET: Registered protocol family 10 [ 22.908219] Key type dns_resolver registered [ 22.912543] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 [ 22.920176] ThumbEE CPU extension supported. [ 22.924437] PJ4 iWMMXt coprocessor enabled. [ 22.929047] registered taskstats version 1 [ 22.933353] rtc-mv rtc-mv: setting system clock to 2012-11-27 20:44:00 UTC (1354049040) [ 22.941765] Freeing init memory: 264K [ 22.976707] mmc0: new high speed SDHC card at address aaaa [ 22.985304] mmcblk0: mmc0:aaaa SU04G 3.69 GiB [ 22.998024] mmcblk0: p1 p2 setterm: cannot (un)set powersave mode: Invalid argument /usr/sbin/klogconsole [ 0.831911] Including oem partition info file [ 0.926862] Searching for boot device... [ 18.296347] Failed to find boot device ! That means the MBR signature that the kiwi initrd searches for does not match the MBR signature of the SD card you have. Have you booted this system before with the kiwi initrd?
[ 18.305829] rebootException: reboot in 120 sec...
The boot.script in the /boot section looks like this:
setenv ramdisk boot/initrd.uboot setenv kernel boot/linux.vmx setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs loader=uboot console=ttyS0,115200n8 showopts ${append} looks good, no? Is $append set?
Now this is a bit crazy. The _only_ difference this time round is that I removed the setenv in uboot-image-setup. Now it hangs at "booting the kernel" again. There must be some difference in the setenv command that I was adding to uboot-image-setup and whatever it is that the kiwi file is doing Ciaran
Alex
if itest 1$arcNumber == 13905; then setenv kerneladdr 0x2000000 setenv ramdiskaddr 0x5000000 fi ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p2" bootm ${kerneladdr} ${ramdiskaddr} boot
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27.11.2012, at 21:45, Ciaran Farrell wrote:
On 27/11/12 21:42, Alexander Graf wrote:
On 27.11.2012, at 21:30, Ciaran Farrell wrote:
On 27/11/12 19:06, Cristian Rodríguez wrote:
El 26/11/12 18:32, Ciaran Farrell escribió:
6547890 bytes read ## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux-3.6.0-1.2-cubox Created: 2012-10-18 11:13:02 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3927856 Bytes = 3.7 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 05000000 ... Image Name: Initrd Created: 2012-11-26 21:06:55 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 26547826 Bytes = 25.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
And there it hangs... Now I have the same issue.. wow.. what is going on here.. maybe something else is needed to actually load this monster initrd.. I wonder why it is so big...
This works for me:
#!/bin/bash
set -x
file=boot/boot.script
echo 'if itest 1$arcNumber == 13905; then' >> $file echo ' setenv kerneladdr 0x2000000' >> $file echo ' setenv ramdiskaddr 0x5000000' >> $file echo 'fi' >> $file echo 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx' >> $file echo 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot' >> $file echo -n 'setenv bootargs "' >> $file echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file echo 'bootm ${kerneladdr} ${ramdiskaddr}' >> $file echo 'boot' >> $file mkopts="-A arm -O linux -a 0 -e 0 -T script -C none"; inputf="boot/boot.script"; result="boot/boot.scr"; if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then echo "Failed to create uboot script image" exit 1 fi
Though methinks agraf will want to belt me on the head for setenv bootargs line. In fairness though, at least the cubox specific stuff is back in its own if box... The setenv gets imported from the .kiwi file. Maybe something's bogus there? What does the actually built boot.script look like? I spoke too soon - it does get past the loading kernel stage where I was bogged down all the time. However, it runs into another problem when booting:
[ 22.782759] sdhci-pltfm: SDHCI platform and OF driver helper [ 22.788442] mmc0: no vmmc regulator found [ 22.792729] ata1: SATA link down (SStatus 0 SControl F300) [ 22.831999] mmc0: SDHCI controller on sdhci-dove.0 [sdhci-dove.0] using DMA [ 22.838965] mmc1: no vmmc regulator found [ 22.881992] mmc1: SDHCI controller on sdhci-dove.1 [sdhci-dove.1] using DMA [ 22.888988] zram: num_devices not specified. Using default: 1 [ 22.894721] zram: Creating 1 devices ... [ 22.899705] TCP: cubic registered [ 22.903062] NET: Registered protocol family 10 [ 22.908219] Key type dns_resolver registered [ 22.912543] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 [ 22.920176] ThumbEE CPU extension supported. [ 22.924437] PJ4 iWMMXt coprocessor enabled. [ 22.929047] registered taskstats version 1 [ 22.933353] rtc-mv rtc-mv: setting system clock to 2012-11-27 20:44:00 UTC (1354049040) [ 22.941765] Freeing init memory: 264K [ 22.976707] mmc0: new high speed SDHC card at address aaaa [ 22.985304] mmcblk0: mmc0:aaaa SU04G 3.69 GiB [ 22.998024] mmcblk0: p1 p2 setterm: cannot (un)set powersave mode: Invalid argument /usr/sbin/klogconsole [ 0.831911] Including oem partition info file [ 0.926862] Searching for boot device... [ 18.296347] Failed to find boot device ! That means the MBR signature that the kiwi initrd searches for does not match the MBR signature of the SD card you have. Have you booted this system before with the kiwi initrd? Sure - this is the same SD card I have been playing around with all the time. I possibly reformatted at some stage along the way with the YaST
On 27/11/12 21:50, Alexander Graf wrote: partitioner. Would that have fscked it up?
[ 18.305829] rebootException: reboot in 120 sec...
The boot.script in the /boot section looks like this:
setenv ramdisk boot/initrd.uboot setenv kernel boot/linux.vmx setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs loader=uboot console=ttyS0,115200n8 showopts ${append} looks good, no? Is $append set?
Do reckon the difference between "console=ttyS0,115200" that I'm setting as bootarg and "console=ttyS0,115200n8" that the .kiwi file is setting could be the issue?
Alex
if itest 1$arcNumber == 13905; then setenv kerneladdr 0x2000000 setenv ramdiskaddr 0x5000000 fi ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p2" bootm ${kerneladdr} ${ramdiskaddr} boot
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27.11.2012, at 22:30, Ciaran Farrell wrote:
On 27.11.2012, at 21:45, Ciaran Farrell wrote:
On 27/11/12 21:42, Alexander Graf wrote:
On 27.11.2012, at 21:30, Ciaran Farrell wrote:
On 27/11/12 19:06, Cristian Rodríguez wrote:
El 26/11/12 18:32, Ciaran Farrell escribió:
> 6547890 bytes read > ## Booting kernel from Legacy Image at 02000000 ... > Image Name: Linux-3.6.0-1.2-cubox > Created: 2012-10-18 11:13:02 UTC > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 3927856 Bytes = 3.7 MB > Load Address: 00008000 > Entry Point: 00008000 > Verifying Checksum ... OK > ## Loading init Ramdisk from Legacy Image at 05000000 ... > Image Name: Initrd > Created: 2012-11-26 21:06:55 UTC > Image Type: ARM Linux RAMDisk Image (uncompressed) > Data Size: 26547826 Bytes = 25.3 MB > Load Address: 00000000 > Entry Point: 00000000 > Verifying Checksum ... OK > Loading Kernel Image ... OK > OK > > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > > And there it hangs... Now I have the same issue.. wow.. what is going on here.. maybe something else is needed to actually load this monster initrd.. I wonder why it is so big...
This works for me:
#!/bin/bash
set -x
file=boot/boot.script
echo 'if itest 1$arcNumber == 13905; then' >> $file echo ' setenv kerneladdr 0x2000000' >> $file echo ' setenv ramdiskaddr 0x5000000' >> $file echo 'fi' >> $file echo 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx' >> $file echo 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot' >> $file echo -n 'setenv bootargs "' >> $file echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file echo 'bootm ${kerneladdr} ${ramdiskaddr}' >> $file echo 'boot' >> $file mkopts="-A arm -O linux -a 0 -e 0 -T script -C none"; inputf="boot/boot.script"; result="boot/boot.scr"; if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then echo "Failed to create uboot script image" exit 1 fi
Though methinks agraf will want to belt me on the head for setenv bootargs line. In fairness though, at least the cubox specific stuff is back in its own if box... The setenv gets imported from the .kiwi file. Maybe something's bogus there? What does the actually built boot.script look like? I spoke too soon - it does get past the loading kernel stage where I was bogged down all the time. However, it runs into another problem when booting:
[ 22.782759] sdhci-pltfm: SDHCI platform and OF driver helper [ 22.788442] mmc0: no vmmc regulator found [ 22.792729] ata1: SATA link down (SStatus 0 SControl F300) [ 22.831999] mmc0: SDHCI controller on sdhci-dove.0 [sdhci-dove.0] using DMA [ 22.838965] mmc1: no vmmc regulator found [ 22.881992] mmc1: SDHCI controller on sdhci-dove.1 [sdhci-dove.1] using DMA [ 22.888988] zram: num_devices not specified. Using default: 1 [ 22.894721] zram: Creating 1 devices ... [ 22.899705] TCP: cubic registered [ 22.903062] NET: Registered protocol family 10 [ 22.908219] Key type dns_resolver registered [ 22.912543] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 [ 22.920176] ThumbEE CPU extension supported. [ 22.924437] PJ4 iWMMXt coprocessor enabled. [ 22.929047] registered taskstats version 1 [ 22.933353] rtc-mv rtc-mv: setting system clock to 2012-11-27 20:44:00 UTC (1354049040) [ 22.941765] Freeing init memory: 264K [ 22.976707] mmc0: new high speed SDHC card at address aaaa [ 22.985304] mmcblk0: mmc0:aaaa SU04G 3.69 GiB [ 22.998024] mmcblk0: p1 p2 setterm: cannot (un)set powersave mode: Invalid argument /usr/sbin/klogconsole [ 0.831911] Including oem partition info file [ 0.926862] Searching for boot device... [ 18.296347] Failed to find boot device ! That means the MBR signature that the kiwi initrd searches for does not match the MBR signature of the SD card you have. Have you booted this system before with the kiwi initrd? Sure - this is the same SD card I have been playing around with all the time. I possibly reformatted at some stage along the way with the YaST
On 27/11/12 21:50, Alexander Graf wrote: partitioner. Would that have fscked it up?
Well, the kiwi initrd only works the first time you boot an image. On first boot the MBR signature gets destroyed and a new initrd gets generated that doesn't check for the MBR signature.
[ 18.305829] rebootException: reboot in 120 sec...
The boot.script in the /boot section looks like this:
setenv ramdisk boot/initrd.uboot setenv kernel boot/linux.vmx setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs loader=uboot console=ttyS0,115200n8 showopts ${append} looks good, no? Is $append set?
Do reckon the difference between "console=ttyS0,115200" that I'm setting as bootarg and "console=ttyS0,115200n8" that the .kiwi file is setting could be the issue?
Hrm - maybe. How about you give it a try and change it in the .kiwi file accordingly? :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27/11/12 23:38, Alexander Graf wrote:
On 27.11.2012, at 22:30, Ciaran Farrell wrote:
On 27.11.2012, at 21:45, Ciaran Farrell wrote:
On 27/11/12 21:42, Alexander Graf wrote:
On 27.11.2012, at 21:30, Ciaran Farrell wrote:
On 27/11/12 19:06, Cristian Rodríguez wrote: > El 26/11/12 18:32, Ciaran Farrell escribió: > >> 6547890 bytes read >> ## Booting kernel from Legacy Image at 02000000 ... >> Image Name: Linux-3.6.0-1.2-cubox >> Created: 2012-10-18 11:13:02 UTC >> Image Type: ARM Linux Kernel Image (uncompressed) >> Data Size: 3927856 Bytes = 3.7 MB >> Load Address: 00008000 >> Entry Point: 00008000 >> Verifying Checksum ... OK >> ## Loading init Ramdisk from Legacy Image at 05000000 ... >> Image Name: Initrd >> Created: 2012-11-26 21:06:55 UTC >> Image Type: ARM Linux RAMDisk Image (uncompressed) >> Data Size: 26547826 Bytes = 25.3 MB >> Load Address: 00000000 >> Entry Point: 00000000 >> Verifying Checksum ... OK >> Loading Kernel Image ... OK >> OK >> >> Starting kernel ... >> >> Uncompressing Linux... done, booting the kernel. >> >> And there it hangs... > Now I have the same issue.. wow.. what is going on here.. maybe > something else is needed to actually load this monster initrd.. I > wonder why it is so big... > > > This works for me:
#!/bin/bash
set -x
file=boot/boot.script
echo 'if itest 1$arcNumber == 13905; then' >> $file echo ' setenv kerneladdr 0x2000000' >> $file echo ' setenv ramdiskaddr 0x5000000' >> $file echo 'fi' >> $file echo 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx' >> $file echo 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot' >> $file echo -n 'setenv bootargs "' >> $file echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file echo 'bootm ${kerneladdr} ${ramdiskaddr}' >> $file echo 'boot' >> $file mkopts="-A arm -O linux -a 0 -e 0 -T script -C none"; inputf="boot/boot.script"; result="boot/boot.scr"; if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then echo "Failed to create uboot script image" exit 1 fi
Though methinks agraf will want to belt me on the head for setenv bootargs line. In fairness though, at least the cubox specific stuff is back in its own if box... The setenv gets imported from the .kiwi file. Maybe something's bogus there? What does the actually built boot.script look like? I spoke too soon - it does get past the loading kernel stage where I was bogged down all the time. However, it runs into another problem when booting:
[ 22.782759] sdhci-pltfm: SDHCI platform and OF driver helper [ 22.788442] mmc0: no vmmc regulator found [ 22.792729] ata1: SATA link down (SStatus 0 SControl F300) [ 22.831999] mmc0: SDHCI controller on sdhci-dove.0 [sdhci-dove.0] using DMA [ 22.838965] mmc1: no vmmc regulator found [ 22.881992] mmc1: SDHCI controller on sdhci-dove.1 [sdhci-dove.1] using DMA [ 22.888988] zram: num_devices not specified. Using default: 1 [ 22.894721] zram: Creating 1 devices ... [ 22.899705] TCP: cubic registered [ 22.903062] NET: Registered protocol family 10 [ 22.908219] Key type dns_resolver registered [ 22.912543] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 [ 22.920176] ThumbEE CPU extension supported. [ 22.924437] PJ4 iWMMXt coprocessor enabled. [ 22.929047] registered taskstats version 1 [ 22.933353] rtc-mv rtc-mv: setting system clock to 2012-11-27 20:44:00 UTC (1354049040) [ 22.941765] Freeing init memory: 264K [ 22.976707] mmc0: new high speed SDHC card at address aaaa [ 22.985304] mmcblk0: mmc0:aaaa SU04G 3.69 GiB [ 22.998024] mmcblk0: p1 p2 setterm: cannot (un)set powersave mode: Invalid argument /usr/sbin/klogconsole [ 0.831911] Including oem partition info file [ 0.926862] Searching for boot device... [ 18.296347] Failed to find boot device ! That means the MBR signature that the kiwi initrd searches for does not match the MBR signature of the SD card you have. Have you booted this system before with the kiwi initrd? Sure - this is the same SD card I have been playing around with all the time. I possibly reformatted at some stage along the way with the YaST
On 27/11/12 21:50, Alexander Graf wrote: partitioner. Would that have fscked it up? Well, the kiwi initrd only works the first time you boot an image. On first boot the MBR signature gets destroyed and a new initrd gets generated that doesn't check for the MBR signature.
[ 18.305829] rebootException: reboot in 120 sec...
The boot.script in the /boot section looks like this:
setenv ramdisk boot/initrd.uboot setenv kernel boot/linux.vmx setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs loader=uboot console=ttyS0,115200n8 showopts ${append} looks good, no? Is $append set? Do reckon the difference between "console=ttyS0,115200" that I'm setting as bootarg and "console=ttyS0,115200n8" that the .kiwi file is setting could be the issue? Hrm - maybe. How about you give it a try and change it in the .kiwi file accordingly? :) http://www.solid-run.com/mw/index.php/Setup_SD_boot uses this:
setenv bootargs 'console=ttyS0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 So it would seem that 115200n8 is correct, not 115200. I'll give both versions a try as soon as I get back in front of a Cubox. Any idea what the difference between 115200 and 115200n8 is? Something to do with parity?
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27/11/12 23:38, Alexander Graf wrote:
On 27.11.2012, at 22:30, Ciaran Farrell wrote:
On 27.11.2012, at 21:45, Ciaran Farrell wrote:
On 27/11/12 21:42, Alexander Graf wrote:
On 27.11.2012, at 21:30, Ciaran Farrell wrote:
On 27/11/12 19:06, Cristian Rodríguez wrote: > El 26/11/12 18:32, Ciaran Farrell escribió: > >> 6547890 bytes read >> ## Booting kernel from Legacy Image at 02000000 ... >> Image Name: Linux-3.6.0-1.2-cubox >> Created: 2012-10-18 11:13:02 UTC >> Image Type: ARM Linux Kernel Image (uncompressed) >> Data Size: 3927856 Bytes = 3.7 MB >> Load Address: 00008000 >> Entry Point: 00008000 >> Verifying Checksum ... OK >> ## Loading init Ramdisk from Legacy Image at 05000000 ... >> Image Name: Initrd >> Created: 2012-11-26 21:06:55 UTC >> Image Type: ARM Linux RAMDisk Image (uncompressed) >> Data Size: 26547826 Bytes = 25.3 MB >> Load Address: 00000000 >> Entry Point: 00000000 >> Verifying Checksum ... OK >> Loading Kernel Image ... OK >> OK >> >> Starting kernel ... >> >> Uncompressing Linux... done, booting the kernel. >> >> And there it hangs... > Now I have the same issue.. wow.. what is going on here.. maybe > something else is needed to actually load this monster initrd.. I > wonder why it is so big... > > > This works for me:
#!/bin/bash
set -x
file=boot/boot.script
echo 'if itest 1$arcNumber == 13905; then' >> $file echo ' setenv kerneladdr 0x2000000' >> $file echo ' setenv ramdiskaddr 0x5000000' >> $file echo 'fi' >> $file echo 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx' >> $file echo 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot' >> $file echo -n 'setenv bootargs "' >> $file echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file echo 'bootm ${kerneladdr} ${ramdiskaddr}' >> $file echo 'boot' >> $file mkopts="-A arm -O linux -a 0 -e 0 -T script -C none"; inputf="boot/boot.script"; result="boot/boot.scr"; if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then echo "Failed to create uboot script image" exit 1 fi
Though methinks agraf will want to belt me on the head for setenv bootargs line. In fairness though, at least the cubox specific stuff is back in its own if box... The setenv gets imported from the .kiwi file. Maybe something's bogus there? What does the actually built boot.script look like? I spoke too soon - it does get past the loading kernel stage where I was bogged down all the time. However, it runs into another problem when booting:
[ 22.782759] sdhci-pltfm: SDHCI platform and OF driver helper [ 22.788442] mmc0: no vmmc regulator found [ 22.792729] ata1: SATA link down (SStatus 0 SControl F300) [ 22.831999] mmc0: SDHCI controller on sdhci-dove.0 [sdhci-dove.0] using DMA [ 22.838965] mmc1: no vmmc regulator found [ 22.881992] mmc1: SDHCI controller on sdhci-dove.1 [sdhci-dove.1] using DMA [ 22.888988] zram: num_devices not specified. Using default: 1 [ 22.894721] zram: Creating 1 devices ... [ 22.899705] TCP: cubic registered [ 22.903062] NET: Registered protocol family 10 [ 22.908219] Key type dns_resolver registered [ 22.912543] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 [ 22.920176] ThumbEE CPU extension supported. [ 22.924437] PJ4 iWMMXt coprocessor enabled. [ 22.929047] registered taskstats version 1 [ 22.933353] rtc-mv rtc-mv: setting system clock to 2012-11-27 20:44:00 UTC (1354049040) [ 22.941765] Freeing init memory: 264K [ 22.976707] mmc0: new high speed SDHC card at address aaaa [ 22.985304] mmcblk0: mmc0:aaaa SU04G 3.69 GiB [ 22.998024] mmcblk0: p1 p2 setterm: cannot (un)set powersave mode: Invalid argument /usr/sbin/klogconsole [ 0.831911] Including oem partition info file [ 0.926862] Searching for boot device... [ 18.296347] Failed to find boot device ! That means the MBR signature that the kiwi initrd searches for does not match the MBR signature of the SD card you have. Have you booted this system before with the kiwi initrd? Sure - this is the same SD card I have been playing around with all the time. I possibly reformatted at some stage along the way with the YaST
On 27/11/12 21:50, Alexander Graf wrote: partitioner. Would that have fscked it up? Well, the kiwi initrd only works the first time you boot an image. On first boot the MBR signature gets destroyed and a new initrd gets generated that doesn't check for the MBR signature.
[ 18.305829] rebootException: reboot in 120 sec...
The boot.script in the /boot section looks like this:
setenv ramdisk boot/initrd.uboot setenv kernel boot/linux.vmx setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs loader=uboot console=ttyS0,115200n8 showopts ${append} looks good, no? Is $append set? Do reckon the difference between "console=ttyS0,115200" that I'm setting as bootarg and "console=ttyS0,115200n8" that the .kiwi file is setting could be the issue? Hrm - maybe. How about you give it a try and change it in the .kiwi file accordingly? :) I could not believe this, but exactly that change in the Image.kiwi.in file seems to have fixed this for me. sr#143623 created (based on rev11).
It would be great if some other cubox users could test this to see if it works for them too (especially on older versions uboot)...
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
El 29/11/12 18:29, Ciaran Farrell escribió:
I could not believe this, but exactly that change in the Image.kiwi.in file seems to have fixed this for me. sr#143623 created (based on rev11).
So it is not that loading hangs, but the serial console output freezes giving the impression of a hang..shady little problems.. ;)
It would be great if some other cubox users could test this to see if it works for them too (especially on older versions uboot)...
I will test that. ;) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 30/11/12 13:49, Cristian Rodríguez wrote:
El 29/11/12 18:29, Ciaran Farrell escribió:
I could not believe this, but exactly that change in the Image.kiwi.in file seems to have fixed this for me. sr#143623 created (based on rev11).
So it is not that loading hangs, but the serial console output freezes giving the impression of a hang..shady little problems.. ;)
It would be great if some other cubox users could test this to see if it works for them too (especially on older versions uboot)...
I will test that. ;)
Wait, wait, wait! :-) I forgot to update the uboot-setup.tgz (kiwi-hooks/setupUboot.sh). Details here: http://c-farrell.blogspot.de/2012/11/opensuse-on-cubox-day-7.html Basically, the latest image (home:babelworx:branches...) can now survive a reboot, but dies on an illegal instruction. Which for me means that the new initrd that is written after yast2-firstboot is somehow kaputt. Ciaran -- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 30/11/12 13:56, Ciaran Farrell wrote:
On 30/11/12 13:49, Cristian Rodríguez wrote:
El 29/11/12 18:29, Ciaran Farrell escribió:
I could not believe this, but exactly that change in the Image.kiwi.in file seems to have fixed this for me. sr#143623 created (based on rev11).
So it is not that loading hangs, but the serial console output freezes giving the impression of a hang..shady little problems.. ;)
It would be great if some other cubox users could test this to see if it works for them too (especially on older versions uboot)... I will test that. ;)
Wait, wait, wait! :-)
I forgot to update the uboot-setup.tgz (kiwi-hooks/setupUboot.sh). Details here:
http://c-farrell.blogspot.de/2012/11/opensuse-on-cubox-day-7.html
Basically, the latest image (home:babelworx:branches...) can now survive a reboot, but dies on an illegal instruction. Which for me means that the new initrd that is written after yast2-firstboot is somehow kaputt. Fixed with https://build.opensuse.org/request/show/143674
For me, it now boots properly. Now testing the system itself... Ciaran
Ciaran
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 30/11/12 13:56, Ciaran Farrell wrote:
For me, it now boots properly. Now testing the system itself...
Ciaran
I did some testing and this are my findings. (excluding the obvious lack of video) - I could not make the CESA (crypto engine) to work, even if the module is compiled in the kernel. apparently is a known issue and requires out-of-tree patches. - The Watchdog timer driver (so I can configure systemd to reboot the machine when it hangs) is not built, apparently due to a bug in Kconfig's . CONFIG_WATCHDOG_ORION has depends that do not include DOVE platform. - Same with sound output. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 26/11/12 21:35, Alexander Graf wrote:
On 26.11.2012, at 21:34, Ciaran Farrell wrote:
On 26/11/12 21:29, Alexander Graf wrote:
On 26.11.2012, at 21:28, Ciaran Farrell wrote:
On 26/11/12 21:26, Alexander Graf wrote:
On 26.11.2012, at 21:23, Ciaran Farrell wrote:
On 26/11/12 21:21, Alexander Graf wrote: > On 26.11.2012, at 21:17, Ciaran Farrell wrote: > >> On 26/11/12 20:51, Bill Merriam wrote: >>> On Mon, 26 Nov 2012 16:15:33 -0300 >>> "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote: >>> >>>> El 26/11/12 13:54, Cristian Rodríguez escribió: >>>>> El 26/11/12 13:28, Ciaran Farrell escribió: >>>>>> On 26/11/12 17:20, Alexander Graf wrote: >>>>>>> On 26.11.2012, at 17:20, Ciaran Farrell wrote: >>>>>>> >>>>>>>> Any idea what is causing this? >>>>> https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219... >>>>> >>>>> >>>>> >>>> In short you need to have the latest u-boot from solidrun, dated Oct >>>> 3. >>>> >>>> http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc... >>>> >>> During the initial boot, the one where the initrd resizes the >>> partitions, it modifies u-boot environment variables and then tries to >>> save them. Something goes wrong. On subsequent boots u-boot finds a >>> bad checksum in the saved environment variables and uses default >>> values. That causes it to generate a random MAC address for the >>> ethernet adapter. Udev, finding a new MAC address, assigns it a new >>> device name. >>> >>> The immediate solution is to enter a "saveenv" command to u-boot. It >>> will then have a good checksum and won't create a new MAC address every >>> time. Then you have to fix your udev rules >>> in /etc/udev/rules.d/70-persistent-net.rules >> Could the resetenv in the uboot-setup script be causing this? I put it >> in there because it appeared to have helped me boot at all at first, but >> now I'm beginning to think it nukes the MAC address as well... > I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :) > > Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling. What would prevent me from taking your version (it boots into yast2-firstboot, by the way - I'm still configuring there, so I'll still need to see what happens after the first reboot), removing the resetenv and sr'ing? That would work too, but the former version was tested on a lot of boards and known to work, while the "short script" that's there now is not. So chances are higher more things break again later.
However, I consider contrib machines responsibilities of the respective contrib maintainers, so in this case that would be Max's call. Ok, understood. I'll try to mess around based on the original version and see what happens. I still haven't updated uboot on my CuBox - I'll hold off doing that for awhile to see if we can get the original generic code working. Another benefit of the original code was that it was almost identical to the one we use for generic platforms in Factory and 12.2. That means integration into the main project becomes easier later on :). I created sr#142958 to revert to revision 11. If somebody with the appropriate permission could check and approve that, it would be great. Could you please create an sr that reverts to 11 plus changes the ramdisk load address to 0x500... in both uboot-image-setup and uboot-setup.tgz/setupUBoot.sh? I now have three images tested: (1) a debian image (2) openSUSE with ramdiskaddr 0x300... (3) openSUSE with ramdiskaddr 0x500...
(1) boots quickly and without a problem (2) gets as far as loading the initrd and then chokes on some kind of illegal instruction (3) manages to load the initrd but then hangs at "booting the kernel" For (2) and (3) I used revision 11 of the JeOS-cubox package. For (2) I used it without any modifications. For (3) I changed the ramdiskaddr in uboot-image-setup and in the .tgz file that decompresses to kiwi-hooks. (1), (2) and (3) were done on a new uboot... Ciaran
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
El 26/11/12 17:21, Alexander Graf escribió:
I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :)
Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling.
The weird thing is that I got my cubox on saturday and have rebooted countless times without getting this behaviour at all. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
The weird thing is that I got my cubox on saturday and have rebooted countless times without getting this behaviour at all. Could you check what version of uboot you have. My CuBox (and those at
On 26/11/12 21:24, Cristian Rodríguez wrote: the SUSE office in Nuremberg) were delivered back in early summer. Perhaps newer deliveries have more recent versions of uboot. -- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue, 27 Nov 2012 08:51:13 +0100 Ciaran Farrell <cfarrell@suse.de> wrote:
The weird thing is that I got my cubox on saturday and have rebooted countless times without getting this behaviour at all. Could you check what version of uboot you have. My CuBox (and those at
On 26/11/12 21:24, Cristian Rodríguez wrote: the SUSE office in Nuremberg) were delivered back in early summer. Perhaps newer deliveries have more recent versions of uboot.
I have the new u-boot. I wrote a fresh image xz to a card, edited the boot.scr to remove the "resetenv", and everything "just works". The first boot does the partition resizing and other setup. All subsequent boots work without problems. I am now going to try to get packages made for the cubox graphics stuff. It doesn't look like the Marvell Dove / Vivante GC600 code has made it into the upstream kernel. Can I try to figure out how to put the patches on the openSUSE kernel and submit the patches to suse? Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
El 28/11/12 15:04, Bill Merriam escribió:
I am now going to try to get packages made for the cubox graphics stuff. It doesn't look like the Marvell Dove / Vivante GC600 code has made it into the upstream kernel. Can I try to figure out how to put the patches on the openSUSE kernel and submit the patches to suse?
Bill
Could you first test this kernel and share your results ? https://api.opensuse.org/build/home:elvigia:branches:openSUSE:Factory:ARM/st... I did some work in the configs ;) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
El 28/11/12 15:12, Cristian Rodríguez escribió:
https://api.opensuse.org/build/home:elvigia:branches:openSUSE:Factory:ARM/st...
I did some work in the configs ;)
Of course, I meant https://api.opensuse.org/build/home:elvigia:branches:openSUSE:Factory:ARM/st... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 11/28/2012 07:04 PM, Bill Merriam wrote:
On Tue, 27 Nov 2012 08:51:13 +0100 Ciaran Farrell<cfarrell@suse.de> wrote:
The weird thing is that I got my cubox on saturday and have rebooted countless times without getting this behaviour at all. Could you check what version of uboot you have. My CuBox (and those at
On 26/11/12 21:24, Cristian Rodríguez wrote: the SUSE office in Nuremberg) were delivered back in early summer. Perhaps newer deliveries have more recent versions of uboot.
I have the new u-boot. I wrote a fresh image xz to a card, edited the boot.scr to remove the "resetenv", and everything "just works". The first boot does the partition resizing and other setup. All subsequent boots work without problems.
I am now going to try to get packages made for the cubox graphics stuff.
Cool!
It doesn't look like the Marvell Dove / Vivante GC600 code has made it into the upstream kernel. Can I try to figure out how to put the patches on the openSUSE kernel and submit the patches to suse?
The general rule of thumb is that for normal (Factory) kernels, only patches that are either * not upstreamable at all, but very much interesting or required (like the stack unrolling stuff) or * already/almost accepted upstream, but need backporting for stable openSUSE kernels So the best way forward would be to get them upstream. Then we can talk about pulling them into the openSUSE kernel git. For contrib, things are different. There the quality of the kernel's code is the contrib maintainer's problem. We have a few contrib ports with purely downstream kernels around :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
El 26/11/12 13:20, Ciaran Farrell escribió:
One thing I've been noticing on the CuBox is that, at each reboot, the network interface is not brought up. Strangely, the system tries to set up ethX where X increments by one at each reboot. For example, I now see the following in /var/log/boot.log:
Strange, it works for me.. what u-boot you have installed ? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (5)
-
Alexander Graf -
Bill Merriam -
Ciaran Farrell -
Ciaran Farrell -
Cristian Rodríguez