[ARMedslack] Hello

Rich richard.lapointe at gmail.com
Sat Mar 19 16:16:47 UTC 2011


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
>
>    


More information about the ARMedslack mailing list