Welcome! Log In Create A New Profile

Advanced

Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region

Posted by CyberPK 
Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 22, 2019 07:33AM
I've compiled the mainline kernel (without patches) and trying to run the generated uImage and the ramdisk of the debian installer.
My problem is that if I use the precompiled kernle 5.1.2 the initrd is not loaded beacuse the ramfs is disabled. My compiled kernel with BLK_DEV_RAM=y instead of external module fails with these errors
...
[    0.000000][    T0] INITRD: 0x00f00000+0x01461000 overlaps in-use memory region - disabling initrd
....
[    2.495171][    T1] FAT-fs (ram0): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[    2.506803][    T1] FAT-fs (ram0): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[    2.519234][    T1] F2FS-fs (ram0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[    2.526774][    T1] F2FS-fs (ram0): Can't find valid F2FS filesystem in 1th superblock
[    2.534756][    T1] F2FS-fs (ram0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[    2.542280][    T1] F2FS-fs (ram0): Can't find valid F2FS filesystem in 2th superblock
[    2.550272][    T1] List of all partitions:
[    2.554491][    T1] 0100           32768 ram0 
[    2.554493][    T1]  (driver?)
[    2.562026][    T1] No filesystem could mount root, tried: 
[    2.562028][    T1]  ext3
[    2.567638][    T1]  ext4
[    2.570270][    T1]  vfat
[    2.572901][    T1]  msdos
[    2.575541][    T1]  iso9660
[    2.578261][    T1]  udf
[    2.581155][    T1]  f2fs
[    2.583706][    T1] 
[    2.588536][    T1] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)


If I use the precompiled kernel from https://themm.net/public/ex2u/start the ramdisk is loaded and the installer popups immediately in the serial console.
Any help?
Thank you

*** EDIT ***
I've managed to start the netinstaller of debian moving the address where uRamdisk is loaded to 0x2000000, the same used in case of tftp loading
usb start
fatload usb 0:1 0xa00000 boot/uImage
fatload usb 0:1 0x2000000 boot/uRamdisk
bootm 0xa00000 0x2000000


Why this behaviour was not evidend with older kernel versions?

-----

moderator: added code tags.



Edited 5 time(s). Last edit at 05/22/2019 02:13PM by CyberPK.
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 22, 2019 02:17PM
CyberPK ,

You did not say which box do you have?

There should be no problem if you use this kernel:
https://forum.doozan.com/read.php?2,32146

Quote

Latest released kernel: linux-5.1.2-mvebu-tld-1 (18 May 2019)

If you build your own kernel then you can use my config file in the released tarball: linux-5.1.2-mvebu-tld-1-bodhi.tar.bz2.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 22, 2019 02:52PM
I own a WD My Cloud Mirror Gen 2 and I'm already trying to use your package. Only the dts is from fox-exe (http://fox-exe.ru/WDMyCloud/Other/Official_linux_kernel/armada-385-wdmc-mirror-gen2.dts) because there isn't in your patch.
If I use the precompiled kernel, in uboot format, I cannot load the uRamdisk with the debian net installer.
I would like to build the kernel by my own, and also create a rootfs into an usb drive, and uInitrd to be stored into the nand to boot to the usb (can you help me in this step?). Probably is better to inline root= label to the usb drive, but still haven't tried if it is feasible.
My idea is to use multiple drive couples and easily replace them; also it is useful to allow the drive to spin down. Moreover I'd like to update as long as I like the device.
Once successful I'll share the instruction to repeat every step, thank to your great work and support.

My idea is also to eventually use the preseed function to enable the network-console debian setup version to be used without the serial console connected

Also I cannot find how to eventually start the tftp upload to the device.

Returning to the problem, it appears to me that for some reason the memory schema is different and the space reserved for uRamdisk is smaller, so the overlapping resolved changing the memory location, that require a manual boot through uboot.



Edited 1 time(s). Last edit at 05/22/2019 02:57PM by CyberPK.
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 23, 2019 12:53AM
CyberPK,

> I own a WD My Cloud Mirror Gen 2 and I'm
> already trying to use your package. Only the dts
> is from fox-exe
> (http://fox-exe.ru/WDMyCloud/Other/Official_linux_kernel/armada-385-wdmc-mirror-gen2.dts)
> because there isn't in your patch.

Ah. So the people in this working thread are more knowledgeable than I am about this box:

JanN, MM, Peacemaker, mcmg2 and hmartin.


> If I use the precompiled kernel,

Which precompiled kernel? can you be more specific about the version name?

> in uboot format,
> I cannot load the uRamdisk with the debian net
> installer.


> I would like to build the kernel by my own, and
> also create a rootfs into an usb drive, and
> uInitrd to be stored into the nand to boot to the
> usb (can you help me in this step?).

Sorry, the answer is no. It would take too much time, that I don't have. But I can help you boot my released rootfs Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2.,

> Probably is
> better to inline root= label to the usb drive, but
> still haven't tried if it is feasible.
> My idea is to use multiple drive couples and
> easily replace them; also it is useful to allow
> the drive to spin down. Moreover I'd like to
> update as long as I like the device.
> Once successful I'll share the instruction to
> repeat every step, thank to your great work and
> support.
>
> My idea is also to eventually use the preseed
> function to enable the network-console debian
> setup version to be used without the serial
> console connected

Netconsole is not supported in this box u-boot, so stock u-boot need to be patched and rebuild to enable that.

> Also I cannot find how to eventually start the
> tftp upload to the device.
>
> Returning to the problem, it appears to me that
> for some reason the memory schema is different and
> the space reserved for uRamdisk is smaller, so the
> overlapping resolved changing the memory location,
> that require a manual boot through uboot.

To start, you should connect serial console, list the u-boot envs at u-boot prompt. And then try to boot with my rootfs Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2. And post the entire serial console log here.

u-boot envs adjustment will boot this box into USB rootfs or HDD rootfs (I have to refresh my memory, it's been quite a while, I probably forgot all about this box specifics).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 26, 2019 07:03PM
Thank you for answering. Effectively my question was a bit confusing. Thank you for trying to understand my problems.

About the network-console, effectively I do not need it for the network console (and kernel messages), but I've used it (probably wrongly) to make the ssh daemon start in unattended mode using the pressed.cfg (done with success). Probably I should have used only the netboot to start the setup to an usb drive.

Let me try to better explain what I've done.
I've downloaded the last stable kernel (5.1.4 at time of the first post), downloaded your package and downloaded the debian netboot.

Prepared the uRamdisk from the initrd.gz of the debian netboot
mkimage -A arm -T ramdisk -n "debian installer" -c gzip -d initrd.gz uRamdisk

Downloaded the WD MyCloud Mirror Gen 2 from http://fox-exe.ru/WDMyCloud/Other/Official_linux_kernel/armada-385-wdmc-mirror-gen2.dts

Applied your patch to the kernel, compiled the kernel and the dtb and finally created the uImage.
patch -p1 -d linux-stable < linux-5.1.2-mvebu-tld-1-bodhi/linux-5.1.2-mvebu-tld-1.patch
cd linux-stable
make -j 4 oldconfig
make -j 4 zImage
make -j 4 armada-385-wdmc-mirror-gen2.dtb
cat arch/arm/boot/zImage arch/arm/boot/dts/armada-385-wdmc-mirror-gen2.dtb > zImage
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n armada-385-wdmc-mirror-gen2 -d zImage uImage

Prepared the usb drive to perform a boot from usb
echo -e "1 100M 0xb\n,4000M" | sudo sfdisk /dev/sdb
sudo mkfs.vfat -F32 /dev/sdb1
sudo mkfs.ext4 /dev/sdb2
sudo mount /dev/sdb1 /mnt/
sudo mkdir /mnt/boot
sudo cp output/uImage uRamdisk /mnt/boot
sudo umount /mnt

Connected the serial console, started the WD MyCloud with the reset button presset to boot from the usb.
And this is the error that appears.
...
[    0.000000][    T0] INITRD: 0x00f00000+0x013ba000 overlaps in-use memory region - disabling initrd
...
[    2.507474][    T1] VFS: Cannot open root device "ram" or unknown-block(1,0): error -6
[    2.515455][    T1] Please append a correct "root=" boot option; here are the available partitions:
[    2.524570][    T1] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

At first I missed the first line, so I wrongly think that was missing the ramfs support, so edited the .config set BLK_DEV_RAM=y, recompiled the kernel and booted again with the following error:
 Reset button be pushed.
(Re)start USB...
USB0:   Port (usbActive) : 0	Interface (usbType = 3) : USB XHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found
reading /boot/uImage
##### boot from USB #####
Net:   
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |   In-Band    |
| egiga1 |   RGMII   |   In-Band    |
| egiga2 |   SGMII   |     0x00     |
egiga0, egiga1, egiga2 [PRIME]
Hit any key to stop autoboot:  1  0 
(Re)start USB...
USB0:   Port (usbActive) : 0	Interface (usbType = 3) : USB XHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found
reading /boot/uImage
4698018 bytes read in 164 ms (27.3 MiB/s)
reading /boot/uRamdisk
21367585 bytes read in 613 ms (32.2 MiB/s)
boot_get_kernel : Reset button have been pushed
## Booting image at 00a00000 ...
## Booting kernel from Legacy Image at 00a00000 ...
   Image Name:   armada-385-wdmc-mirror-gen2
   Created:      2019-05-22  14:51:19 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4698018 Bytes = 4.5 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00f00000 ...
   Image Name:   initrd.gz
   Created:      2019-05-22   2:06:59 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    21367585 Bytes = 20.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
...
[    0.000000][    T0] INITRD: 0x00f00000+0x01461000 overlaps in-use memory region - disabling initrd
....
[    2.495171][    T1] FAT-fs (ram0): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[    2.506803][    T1] FAT-fs (ram0): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[    2.519234][    T1] F2FS-fs (ram0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[    2.526774][    T1] F2FS-fs (ram0): Can't find valid F2FS filesystem in 1th superblock
[    2.534756][    T1] F2FS-fs (ram0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[    2.542280][    T1] F2FS-fs (ram0): Can't find valid F2FS filesystem in 2th superblock
[    2.550272][    T1] List of all partitions:
[    2.554491][    T1] 0100           32768 ram0 
[    2.554493][    T1]  (driver?)
[    2.562026][    T1] No filesystem could mount root, tried: 
[    2.562028][    T1]  ext3
[    2.567638][    T1]  ext4
[    2.570270][    T1]  vfat
[    2.572901][    T1]  msdos
[    2.575541][    T1]  iso9660
[    2.578261][    T1]  udf
[    2.581155][    T1]  f2fs
[    2.583706][    T1] 
[    2.588536][    T1] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

Then I used the kernel uImage precompiled from TheMM available for download at the page https://themm.net/public/ex2u/start (https://themm.net/_media/public/ex2u/uimage.bin) simply copied to the usb drive, booted again and finally the debian installer popped up. So I could not understand why the compiled kernel 5.1.4 would not boot!

Finally my attention was captured from the first error:
...
[    0.000000][    T0] INITRD: 0x00f00000+0x01461000 overlaps in-use memory region - disabling initrd
....
and understood that for some reason the memory was probably mapped differently and the assigned memory location for the uRamdisk was not big enough to contain the debian netboot installer. The first assumption may be wrong, but the second is right for sure. The location is not big enough and I should find a bigger one, free to be used.

The simpler think to do was to check the uBoot env for any clue.
Marvell>> printenv 
CASset=max
MALLOC_len=5
MPmode=SMP
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
bootargs=root=/dev/ram console=ttyS0,115200
bootargs_dflt=$console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=nand read.e 0xa00000 0x500000 0x500000;nand read.e 0xf00000 0xa00000 0x500000;bootm 0xa00000 0xf00000
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000; 
bootdelay=1
cacheShare=no
console=console=ttyS0,115200
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=xx:xx:xx:xx:xx:xx
eth1mtu=1500
eth2addr=xx:xx:xx:xx:xx:xx
eth2mtu=1500
eth3addr=xx:xx:xx:xx:xx:xx
eth3mtu=1500
ethact=egiga2
ethaddr=xx:xx:xx:xx:xx:xx
ethmtu=1500
ethprime=egiga2
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
filesize=12
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.11.110
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
loadaddr=0x02000000
loads_echo=0
mtddevname=u-boot
mtddevnum=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:5m(u-boot)ro,5m@5m(kernel),5m@10m(uRamdisk),185m@15m(image.cfs),15m@200m(rescue_fw),20m@215m(config),10m@235m(reserve1),10m@245m(reserve2)
mvNetConfig=mv_net_config=4,(xx:xx:xx:xx:xx:xx,0:1:2:3),mtu=1500
mv_pon_addr=xx:xx:xx:xx:xx:xx
nandEcc=nfcConfig=4bitecc
netbsd_en=no
netmask=255.255.255.0
netretry=no
partition=nand0,0
pcieTune=no
pexMode=RC
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
serverip=192.168.11.114
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
usb0Mode=host
usbActive=0
usbType=3
vxworks_en=no
yuk_ethaddr=xx:xx:xx:xx:xx:xx

Environment size: 3209/524284 bytes

What I've attentioned is the bootcmd env and any other boot env
bootcmd=nand read.e 0xa00000 0x500000 0x500000;nand read.e 0xf00000 0xa00000 0x500000;bootm 0xa00000 0xf00000
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000; 
...
loadaddr=0x02000000
...
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
So the best candidate could have been 0x2000000, and I should have give it a try.
Booted the WD MyCloud Mirror Gen2 and pressed '1' in the serial console to start the uBoot console and run these command:
usb start
fatload usb 0:1 0xa00000 boot/uImage
fatload usb 0:1 0x2000000 boot/uRamdisk
bootm 0xa00000 0x2000000

That made finally load the uRamdisk correctly and made the installer boot!

What puzzles me is: why the https://themm.net/_media/public/ex2u/uimage.bin kernel boot up directly and without problem the debian netboot installer, and the kernel 5.1.4 do not?
I would like to keep the uboot partition and env untouched. What do you think?

Now I had to stop my experiment for some days, but I'll install debian to a second usb drive, and I plan to compile a dts with an additional command to boot the rootf from a specific label, the one with the usb drive.
Maybe this is not the right path, so I will need some help to understand the right boot order and finally accomplish it

Regards

***edit***
Here the envs when is pressed the reset button:
 Reset button be pushed.
(Re)start USB...
USB0:   Port (usbActive) : 0	Interface (usbType = 3) : USB XHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found
reading /boot/uImage
##### boot from USB #####
Net:   
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |   In-Band    |
| egiga1 |   RGMII   |   In-Band    |
| egiga2 |   SGMII   |     0x00     |
egiga0, egiga1, egiga2 [PRIME]
Hit any key to stop autoboot:  1  0 
Marvell>> 1111111       printenv
CASset=max
MALLOC_len=5
MPmode=SMP
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
bootargs=root=/dev/ram console=ttyS0,115200
bootargs_dflt=$console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=usb reset; fatload usb 0:1 0xa00000 /boot/uImage; fatload usb 0:1 0xf00000 /boot/uRamdisk; bootm 0xa00000 0xf00000
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000; 
bootdelay=1
cacheShare=no
console=console=ttyS0,115200
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=xx:xx:xx:xx:xx:xx
eth1mtu=1500
eth2addr=xx:xx:xx:xx:xx:xx
eth2mtu=1500
eth3addr=xx:xx:xx:xx:xx:xx
eth3mtu=1500
ethact=egiga2
ethaddr=xx:xx:xx:xx:xx:xx
ethmtu=1500
ethprime=egiga2
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
filesize=12
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.11.110
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
loadaddr=0x02000000
loads_echo=0
mtddevname=u-boot
mtddevnum=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:5m(u-boot)ro,5m@5m(kernel),5m@10m(uRamdisk),185m@15m(image.cfs),15m@200m(rescue_fw),20m@215m(config),10m@235m(reserve1),10m@245m(reserve2)
mvNetConfig=mv_net_config=4,(xx:xx:xx:xx:xx:xx,0:1:2:3),mtu=1500
mv_pon_addr=xx:xx:xx:xx:xx:xx
nandEcc=nfcConfig=4bitecc
netbsd_en=no
netmask=255.255.255.0
netretry=no
partition=nand0,0
pcieTune=no
pexMode=RC
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
serverip=192.168.11.114
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
usb0Mode=host
usbActive=0
usbType=3
vxworks_en=no
yuk_ethaddr=xx:xx:xx:xx:xx:xx

Environment size: 3222/524284 bytes



Edited 4 time(s). Last edit at 05/26/2019 10:54PM by CyberPK.
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 26, 2019 10:58PM
CyberPK,

I see. My guess is:

1) The 2 different boot attempts have different uImage with different size
2) And the kernel configuration switches are different (this makes a lot of differences in where things are loaded).

Usually when you boot with stock u-boot, you need to keep in mind that it does not do reallocation very well. We need to help these old u-boots by loading uInitrd at a location far from where uImage is loaded (with more modern u-boots, we don't need to worry much about these load addresses).

Quote

[ 0.000000][ T0] INITRD: 0x00f00000+0x01461000 overlaps in-use memory region - disabling initrd
....
[ 2.495171][ T1] FAT-fs (ram0): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[ 2.506803][ T1] FAT-fs (ram0): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[ 2.519234][ T1] F2FS-fs (ram0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[ 2.526774][ T1] F2FS-fs (ram0): Can't find valid F2FS filesystem in 1th superblock
[ 2.534756][ T1] F2FS-fs (ram0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[ 2.542280][ T1] F2FS-fs (ram0): Can't find valid F2FS filesystem in 2th superblock
[ 2.550272][ T1] List of all partitions:
[ 2.554491][ T1] 0100 32768 ram0
[ 2.554493][ T1] (driver?)
[ 2.562026][ T1] No filesystem could mount root, tried:
[ 2.562028][ T1] ext3
[ 2.567638][ T1] ext4
[ 2.570270][ T1] vfat
[ 2.572901][ T1] msdos
[ 2.575541][ T1] iso9660
[ 2.578261][ T1] udf
[ 2.581155][ T1] f2fs
[ 2.583706][ T1]
[ 2.588536][ T1] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

If the above, the kernel reported that the region that initrd will be in already has something loaded. And the 2nd error is because the lack of initrd, the kernel can not find the rootfs.

So since your bootcmd is

bootcmd=usb reset; fatload usb 0:1 0xa00000 /boot/uImage; fatload usb 0:1 0xf00000 /boot/uRamdisk; bootm 0xa00000 0xf00000

You can try move uRamdisk (i.e. uInitrd) load address from 0xf00000 to a different location farther, such as

0x1f00000
or
0x2f00000

And with these MVEBU old u-boots, sometime this will help:

setenv initrd_high 0xffffffff

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 27, 2019 12:18AM
Thank you for helping.
1) The uImage size appears irrilevant to me;
2) The kernel is compiled following these instuction https://themm.net/public/ex2u/kernel with this config: https://raw.githubusercontent.com/c-MM/mcm-daemon/master/kernel/4.8.12/config.txt
What you suggest to check? Maybe there is a relocation?

To me 0x00f00000+0x01461000 appear to be the base address + uRamdisk size + alignment
For some reason there is something else mapped there. What? I don't know how to check.

If there is not any other alternative, do you agree it's better to leave the uboot untouched, and simply set bootcmd of the recovery mode to load uRamdisk at 0x2000000? This proved to be working, and it is the same address used for any other boot
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 27, 2019 01:43AM
CyberPK,

> To me 0x00f00000+0x01461000 appear to be the base
> address + uRamdisk size + alignment
> For some reason there is something else mapped
> there. What? I don't know how to check.

Really does not matter. It's quite a waste of time to chase old stock u-boot shortcoming :) and you'll end up with knowledge that is not applicable to modern u-boot. U-boot architecture has changed a few times in the last 10 years or so.

>
> If there is not any other alternative, do you
> agree it's better to leave the uboot untouched,
> and simply set bootcmd of the recovery mode to
> load uRamdisk at 0x2000000? This proved to be
> working, and it is the same address used for any
> other boot

Sure. Whatever works is fine.

With that said, and I do understand the hesitation to mess with u-boot env. However, when you only try to make the kernel side to boot properly with stock u-boot, you will eventually need to mess with it again. To me, the proper way to fully hack a box is to figure out what stock u-boot envs you can change to boot a modern Linux kernel with a lot of resilience to changes, or go all out and build a new u-boot for it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/27/2019 01:45AM by bodhi.
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 27, 2019 08:08AM
My hesitation is because I do not master all the knowledge required, and before bricking the box, I think is better to make a simple question to someone more knowledgeable than me :)

Thank you very much
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 27, 2019 05:51PM
CyberPK,

> My hesitation is because I do not master all the
> knowledge required, and before bricking the box, I
> think is better to make a simple question to
> someone more knowledgeable than me :)
>

I was only speaking in general, to all users. You already understood how to approach this process :)

When you have serial console, it is quite safe to play with u-boot envs, as long as you don't save the envs, and test that with no important USB or HDD atached (i.e. use a test rootfs to do the setup).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 28, 2019 08:58AM
Thank you!

I would like to share my result, but I need to be sure that there is not any error.
Can you help me better understand the uBoot and related arguments (obviously web resources or books to read)?
Can you build the dtb also for the WD My Cloud Mirror Gen 2 for the next releases? (If I'm correct it's the same as EX2 Ultra, but with less RAM, only 512MB)

OT: Do you know if I can directly start an encrypted rootfs without any other boot partition?

*** edit ***
tried to use setenv but it do not save the env once reboot. Any help?



Edited 1 time(s). Last edit at 05/28/2019 04:25PM by CyberPK.
Re: Linux Kernel 5.1.2 MVEBU - INITRD overlaps in-use memory region
May 28, 2019 05:33PM
CyberPK,

> Can you help me better understand the uBoot and
> related arguments (obviously web resources or
> books to read)?

The online manual is old, but should cover all the fundementals:

http://www.denx.de/wiki/DULG/Manual

> Can you build the dtb also for the WD My Cloud
> Mirror Gen 2 for the next releases? (If I'm
> correct it's the same as EX2 Ultra, but with less
> RAM, only 512MB)
>

Sure. I can include the DTB. But I can only do that after someone run my released kernel and rootfs Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2 with the DTB. Even it works with mainline kernel and your own rootfs, I cannot know for sure if it works in my released kernel and rootfs.


> OT: Do you know if I can directly start an
> encrypted rootfs without any other boot
> partition?

In the Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2, it is supported as modules, so you need to boot with uInitrd to use encryption and RAID.

> *** edit ***
> tried to use setenv but it do not save the env
> once reboot. Any help?

Don't save envs until you know it works consistenly after several boots. The u-boot command is

saveenv

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
I am using your Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2 with dtb patch.
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: