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