[ARMedslack] Hello
Davide
louigi600 at yahoo.it
Sat Mar 19 18:12:40 UTC 2011
That's not what was going on on my dockstar as I was on the serial console and I saw nothing.
Whatever was the issue I think it must be something specific to my dockstar setup or even me screwing up something. Whatever it was I'm up and running with current and I'm happy about that apart some minor problems with vim not cutting and pasting correctly.
I'm now moving on to the interesting things I want to implement on my dockstar.
Thanks a milion to everybody for the hints and sorry for asking some irrelevant questions.
--- Sab 19/3/11, Rich <richard.lapointe at gmail.com> ha scritto:
> Da: Rich <richard.lapointe at gmail.com>
> Oggetto: Re: [ARMedslack] Hello
> A: armedslack at lists.armedslack.org
> Data: Sabato 19 marzo 2011, 17:16
> Regarding the 13.1 failing to boot
> problem. I think all of us dockstar
> users with the exception of Thorston had the same
> problem. I believe it
> is related to the fact that the dockstar doesn't have a
> real time clock
> and hence all the installed files get bad time
> stamps. So on first boot
> it fails a fdisk check and just stalls there waiting for
> user input, but
> since you can't see this without a serial connection,
> it appears that
> it never booted up. The difference with
> current is that it now
> includes e2fsck.conf in /etc which allows fdisk to ignore
> bad time
> stamps. I willing to bet if you add this file to the
> 13.1 install it
> would boot also.
>
> Rich Lapointe
>
>
> On 03/17/2011 02:23 PM, Davide wrote:
> > Well I checked md5sum on the 13.1 miniroot tarball and
> it was ok.
> > I got the kernel and initrd from /boot in the miniroot
> after extraction so I'm giessung they should be ok.
> >
> > Not sure if 13.1 kernel has changed since you two
> tried but I can assure you that kernel gets loaded and
> booted but then nothing else:
> > 7706248 bytes read
> > ## Booting kernel from Legacy Image at 06400000 ...
> > Image
> Name: Linux-2.6.33.5-kirkwood
> > Image
> Type: ARM Linux Kernel Image
> (uncompressed)
> > Data Size:
> 2096716 Bytes = 2 MiB
> > Load Address: 00008000
> > Entry Point: 00008000
> > Verifying Checksum ... OK
> > ## Loading init Ramdisk from Legacy Image at 01100000
> ...
> > Image
> Name: Slackware ARM Initial RAM disk f
> > Image
> Type: ARM Linux RAMDisk Image (gzip
> compressed)
> > Data Size:
> 7706184 Bytes = 7.3 MiB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Loading Kernel Image ... OK
> > OK
> >
> > Starting kernel ...
> >
> > Uncompressing Linux... done, booting the kernel.
> >
> > This is the last thing that my doickstar does untill
> hard reset with 13.1 kernel 2.6.33.5-kirkwood
> >
> > I noticed that this is not the default 13.1 kernel on
> x86 which is 2.6.33.4 so things may have changed since
> then.
> > I can assure you that I cut and pasted the very same
> instructions in order to boot from u-boot so there is ither
> something wrong with the kernel or something wrong with my
> dockstar.
> >
> > Here are the instructions I'm using (which have now
> been saved to flash as it looks save for booting
> with 2.6.38rc8-kirkwood:
> > setenv x_bootcmd_kernel 'fatload usb 0:1 0x6400000
> uimage'
> > setenv x_bootcmd_initrd 'fatload usb 0:1 0x1100000
> uinitrd'
> > setenv x_bootargs_root 'root=LABEL=usbroot ro
> rootfstype=ext2'
> > setenv x_bootargs 'console=ttyS0,115200
> mtdparts=orion_nand:1M(u-boot),1M at 1M(second_stage_u-boot),3M at 2M(kernel),32M at 5M(rootfs),219M at 37M(data)
> ro'
> > setenv bootcmd '${x_bootcmd_usb}; ${x_bootcmd_kernel};
> ${x_bootcmd_initrd}; setenv bootargs ${x_bootargs}
> ${x_bootargs_root}; bootm 0x6400000 0x1100000;'
> > boot
> >
> > This works with 2.6.38rc8-kirkwood but not with
> 2.6.33.5-kirkwood.
> > One other thing I've not checked out is if with the
> 13.1 kernel it's only the serial console that is dead ...
> but the led on the usb stick seems dead too so my giess is
> that there is more to it then just the serial console.
> >
> > Regards
> > David
> > --- Gio 17/3/11, Thorsten Mühlfelder<thenktor at gmx.de>
> ha scritto:
> >
> >
> >> Da: Thorsten Mühlfelder<thenktor at gmx.de>
> >> Oggetto: Re: [ARMedslack] Hello
> >> A: "Slackware ARM port"<armedslack at lists.armedslack.org>
> >> Data: Giovedì 17 marzo 2011, 18:17
> >> Am Thursday 17 March 2011 17:48:09
> >> schrieb Stuart Winter:
> >>
> >>> On Thu, 17 Mar 2011, Davide wrote:
> >>>
> >>>> I downloaded miniroot current and did the
> exact
> >>>>
> >> same and it booted !!!
> >>
> >>>> I guess there is something wrong with
> 13.1's
> >>>>
> >> kirkwood kernel image.
> >>
> >>> NOthing wrong with 13.1's kirkwood kernel -
> works fine
> >>>
> >> on the SheevaPlug,
> >>
> >>> Guru and OpenRD client. I don't know
> what the
> >>>
> >> support was like for the
> >>
> >>> Dockstar for that kernel though (or if it was
> even in
> >>>
> >> there at all!)
> >>
> >> I can confirm that I had the 13.1 kernel running
> on my
> >> dockstar without
> >> problems.
> >>
> >>
> >>>> The only thing I noticed wrong while
> system came
> >>>>
> >> up is:
> >>
> >>>> [ 25.669649]
> uncorrectable error
> >>>>
> >> :
> >>
> >>>> [ 25.672905] end_request:
> I/O
> >>>>
> >> error, dev mtdblock0, sector 1920
> >>
> >>>> [ 25.678944] Buffer I/O
> error on
> >>>>
> >> device mtdblock0, logical block 240
> >>
> >>>> [ 25.839517]
> uncorrectable error
> >>>>
> >> :
> >>
> >>>> [ 25.845664] end_request:
> I/O
> >>>>
> >> error, dev mtdblock0, sector 1920
> >>
> >>>> [ 25.851715] Buffer I/O
> error on
> >>>>
> >> device mtdblock0, logical block 240
> >>
> >>>> [ 25.860583]
> uncorrectable error
> >>>>
> >> :
> >>
> >>>> [ 25.863897]
> uncorrectable error
> >>>>
> >> :
> >>
> >>>> [ 25.867630] end_request:
> I/O
> >>>>
> >> error, dev mtdblock0, sector 0
> >>
> >>>> [ 25.873419] Buffer I/O
> error on
> >>>>
> >> device mtdblock0, logical block 0
> >>
> >>>> [ 25.879845]
> uncorrectable error
> >>>>
> >> :
> >>
> >>>> [ 25.883085]
> uncorrectable error
> >>>>
> >> :
> >>
> >>>> [ 25.886731] end_request:
> I/O
> >>>>
> >> error, dev mtdblock0, sector 8
> >>
> >>>> This may be because mtdparts may be
> incorrect
> >>>>
> >> since I'm using openwrt
> >>
> >>>> second stage u-boot that may have passed
> wrong
> >>>>
> >> flash partitions to
> >>
> >>>> kernel. Hope it did not make a mess of
> the
> >>>>
> >> content.
> >>
> >>> http://www.spinics.net/lists/arm-kernel/msg62881.html
> >>>
> >>> AFAIK it's nothing to worry about, but read up
> on it
> >>>
> >> by following the info
> >>
> >>> in there.
> >>>
> >> I have the same errors and I've assumed that they
> are bad
> >> block related. The
> >> link confirmed that in some way (OOB holds bad
> block
> >> information and some
> >> other data as well). But I've wondered why the
> mtd
> >> partitions are touched at
> >> bootup, even they are not mounted.
> >> Was this issue introduced with new kernels? On
> another
> >> device I'm using a
> >> 2.6.24 and 2.6.29 kernel and I'm writing u-boot
> and
> >> u-boot-env from within
> >> Linux to the NAND, but u-boot does not complain
> about
> >> anything (as noted in
> >> your link).
> >>
> >> --
> >> Thorsten Mühlfelder
> >> Salix OS: www.salixos.org
> >> _______________________________________________
> >> ARMedslack mailing list
> >> ARMedslack at lists.armedslack.org
> >> http://lists.armedslack.org/mailman/listinfo/armedslack
> >>
> >>
> >
> >
> > _______________________________________________
> > ARMedslack mailing list
> > ARMedslack at lists.armedslack.org
> > http://lists.armedslack.org/mailman/listinfo/armedslack
> >
> >
> _______________________________________________
> ARMedslack mailing list
> ARMedslack at lists.armedslack.org
> http://lists.armedslack.org/mailman/listinfo/armedslack
>
More information about the ARMedslack
mailing list