Hi Jacco,
I’ve tried the dreamplug image on an SD card but the box gets stuck into the
message below. This is probably a uBoot issue.
6 USB Device(s) found
scanning usb for storage devices... 2 Storage Device(s) found
3665856 bytes read in 418 ms (8.4 MiB/s)
17811253 bytes read in 1726 ms (9.8 MiB/s)
## Booting kernel from Legacy Image at 06400000 ...
Image Name: 3.10.14-100.fc18.armv5tel.kirkwo
Created: 2015-09-20 16:39:00 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3665792 Bytes = 3.5 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 07400000 ...
Image Name: initramfs
Created: 2015-09-20 16:39:00 UTC
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 17811189 Bytes = 17 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
The boot variables are
Marvell>> printenv
baudrate=115200
bootargs=console=ttyS0,115200 root=LABEL=rootfs rootwait
bootargs_console=console=ttyS0,115200
bootcmd=usb start; ${loadImage}; ${loadInitrd} ; bootm 0x6400000 0x7400000
bootcmd_usb=usb start; ext2load usb 1:1 0x00800000 /uImage; ext2load usb 1:1 0xd
bootdelay=3
egiga0=02:50:43:ae:ae:0b
egiga1=02:50:43:34:63:dc
eth1addr=02:50:43:34:63:dc
ethact=egiga0
ethaddr=02:50:43:ae:ae:0b
loadImage=ext2load usb 1:1 0x6400000 uImage
loadInitrd=ext2load usb 1:1 0x7400000 uInitrd
stderr=serial
stdin=serial
stdout=serial
x_bootargs=console=ttyS0,115200
x_bootargs_root=root=/dev/sda2 rootdelay=10
x_bootcmd_ethernet=ping 192.168.2.1
x_bootcmd_kernel=ext2load usb 1 0x6400000 uImage
x_bootcmd_usb=usb start
Environment size: 755/4092 bytes
Marvell>>
The SD card is USB 1 as shown below from uBoot.
Marvell>> ext2ls usb 1:1
<DIR> 1024 .
<DIR> 1024 ..
<DIR> 12288 lost+found
<DIR> 1024 grub
582234 initrd-plymouth.img
3665856 uImage
2 boot.scr
<DIR> 1024 dtb-3.10.14-100.fc18.armv5tel.kirkwood
17811253 uInitrd
179 .vmlinuz-3.10.14-100.fc18.armv5tel.kirkwood.hmac
1688755 System.map-3.10.14-100.fc18.armv5tel.kirkwood
125174 config-3.10.14-100.fc18.armv5tel.kirkwood
17811189 initramfs-3.10.14-100.fc18.armv5tel.kirkwood.img
3665792 vmlinuz-3.10.14-100.fc18.armv5tel.kirkwood
3665856 uImage-3.10.14-100.fc18.armv5tel.kirkwood
17811253 uInitrd-3.10.14-100.fc18.armv5tel.kirkwood
35 klist.txt
Marvell>>
And it is sdb from OS point of view.
uBoot version
U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 21:53:14)
Marvell-DreamPlug
> On Oct 22, 2015, at 5:48 AM, Jacco Ligthart <[email protected]> wrote:
>
> Hi,
>
> both :)
> I think Mandar uses some directory trees under files/<board> to store
> kernels/modules or other artifacts, which can be copied over at image
> creation time. However, as it will install everything else from RPMs,
> it's easy to add the kernel rpm to the list of RPMs to install.
> I include in this mail the templates I used for rpi2 and dreamplug.
>
> For the rpi2 you can see that the kernel (and some other RPMs which I
> find that should be installed on a rpi2) are just listed in the
> <package> section.
>
> For the dreamplug that did not quite work, as the kernel (from F18)
> requires "/sbin/new-kernel-pkg", which is provided by grubby. However
> this is not as such listed in the provides section of grubby. This
> creates a dependency failure and thus a non working image.
> So I installed the kernel afterwards by hand (loop mount the image and
> "yum install --installroot=" etc.
> The "right" way would probably have been to create a board script to yum
> install the kernel. Such a script could then f.i. adjust dracut.conf
> beforehand etc.
>
> You might notice that I included a local repo called comps. This is
> because our repo does not include a "core" group currently. I think I
> included the contents of this group in an earlier email.
>
> Jacco
>
>
>
> On 21-10-15 13:05, Gordan Bobic wrote:
>> Does rbf do rpm installing itself or is it image based? I ask because
>> I'm hoping to get this to the point where we have a kernel rpm for
>> Kirkwood devices that works transparently on upgrades like on x86.
>>
>> On 2015-10-21 11:59, Jacco Ligthart wrote:
>>> I think it would be good to include this in a rbf template. This will
>>> allow for a repeatable process of image creation.
>>>
>>> I'll post mine later today, when I'm home.
>>>
>>> Jacco
>>>
>>>
>>> On Wednesday, 21 October, 2015 11:20 CEST, Gordan Bobic
>>> <[email protected]> wrote:
>>>
>>>> It's not a kernel bug, it's a dracut bug that I was talking about.
>>>> The problem is that dracut wasn't including ehci-orion USB driver
>>>> in the initramfs. Once you figure out what the root cause of the
>>>> problem is, it is trivially fixable with the configuration option
>>>> I listed below.
>>>>
>>>> From here I should be able to follow the standard RSEL recipe:
>>>> 1) Grab a working kernel uImage, /lib/firmware, and
>>>> /lib/modules/$kernel/
>>>> 2) Drop them into the RSEL image
>>>> 3) Make the configuration changes mentioned below (also remember to
>>>> blacklist the orion_nand driver due to the GuruPlug/DreamPlug machid
>>>> confusion issue, as loading the orion_nand driver on DreamPlug will
>>>> hang)
>>>> 4) Rebuild initramfs using dracut, and uboot it using mkimage
>>>>
>>>> And that should just work.
>>>>
>>>> For completeness and neatness, I will put together a kernel package
>>>> that can be installed using rpm and facilitate seamless kernel
>>>> upgrades.
>>>>
>>>> Another package that may require revisiting in RSEL to facilitate
>>>> seamless kernel upgrades is grubby, as this handles re-packing
>>>> vmlinux and initramfs into uImage/uInitrd.
>>>>
>>>> Gordan
>
> <dreamplug_redsleeve.xml><rpi2_redsleeve.xml>_______________________________________________
> users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.redsleeve.org/mailman/listinfo/users
> <http://lists.redsleeve.org/mailman/listinfo/users>
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
