initrd problem

initrd problem

[Ed Martini]

Background:

I'm trying to get 2.6.11 to run on a MIPS Malta board with Yamon.  The 
kernel that comes with the board is 2.4.18 with an embedded ramdisk that 
runs some scripts to install RPMS via NFS or CD-ROM.  The kernel is 
converted to s-records via objcopy(1), and loaded into memory via tftp.  
I want to do something similar with 2.6.latest.

Problem:

On or about Nov 21 of last year, the CONFIG_EMBEDDED_RAMDISK disappeared.

http://www.linux-mips.org/archives/linux-mips/2004-11/msg00135.html

In it's place it is suggested to use the tools in arch/mips/boot, so I 
tried it.  I can cross-compile the kernel, and I get an ELF vmlinux.  I 
can convert it to ecoff with elf2ecoff, and attach an initrd image with 
addinitrd.  The problem begins here.  I end up with an ecoff format 
kernel which is not recognized by objcopy(1), and therefore no s-records.

It seems there is a program called gensrec that would do the job, but 
google doesn't want to tell me where to get it.  Some IRIX binary perhaps?

Solution?

Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or 
write an ELF version of addinitrd?  Other ideas?

Thanks in advance.

Re: initrd problem

[Kumba]

Ed Martini wrote:
> Background:
> 
> I'm trying to get 2.6.11 to run on a MIPS Malta board with Yamon.  The 
> kernel that comes with the board is 2.4.18 with an embedded ramdisk that 
> runs some scripts to install RPMS via NFS or CD-ROM.  The kernel is 
> converted to s-records via objcopy(1), and loaded into memory via tftp.  
> I want to do something similar with 2.6.latest.
> 
> Problem:
> 
> On or about Nov 21 of last year, the CONFIG_EMBEDDED_RAMDISK disappeared.
> 
> http://www.linux-mips.org/archives/linux-mips/2004-11/msg00135.html
> 
> In it's place it is suggested to use the tools in arch/mips/boot, so I 
> tried it.  I can cross-compile the kernel, and I get an ELF vmlinux.  I 
> can convert it to ecoff with elf2ecoff, and attach an initrd image with 
> addinitrd.  The problem begins here.  I end up with an ecoff format 
> kernel which is not recognized by objcopy(1), and therefore no s-records.
> 
> It seems there is a program called gensrec that would do the job, but 
> google doesn't want to tell me where to get it.  Some IRIX binary perhaps?
> 
> Solution?
> 
> Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or 
> write an ELF version of addinitrd?  Other ideas?
> 
> Thanks in advance.

The future is purportedly in the feature known as initramfs.  See the file 
Documentation/early-userpace/README for more details on how that is supposed 
to work.

That said, I tried initramfs a few times, but either due to lack of 
understanding, or broken support code in 2.6.10, I couldn't get it to properly 
load an initrd bundled in, so I forward-ported a patch I wrote that originally 
fixed CONFIG_EMBEDDED_RAMDISK to work with any ABI to 2.6.10, and it worked 
rather well.  I'm sticking with this method until I find more/better docs on 
how to use initramfs properly.

If you're interested, the patch I use can be found here:
http://dev.gentoo.org/~kumba/mips/misc/misc-2.6.10-add-ramdisk-back.patch [2.6.10]
http://dev.gentoo.org/~kumba/mips/misc/misc-2.6.11-add-ramdisk-back.patch [2.6.11]


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: small 
hands do them because they must, while the eyes of the great are elsewhere." 
--Elrond

Re: initrd problem

[Ralf Baechle]

On Thu, Mar 10, 2005 at 03:42:04PM -0800, Ed Martini wrote:

> I'm trying to get 2.6.11 to run on a MIPS Malta board with Yamon.  The 
> kernel that comes with the board is 2.4.18 with an embedded ramdisk that 
> runs some scripts to install RPMS via NFS or CD-ROM.  The kernel is 
> converted to s-records via objcopy(1), and loaded into memory via tftp.  
> I want to do something similar with 2.6.latest.
> 
> Problem:
> 
> On or about Nov 21 of last year, the CONFIG_EMBEDDED_RAMDISK disappeared.
> 
> http://www.linux-mips.org/archives/linux-mips/2004-11/msg00135.html
> 
> In it's place it is suggested to use the tools in arch/mips/boot, so I 
> tried it.  I can cross-compile the kernel, and I get an ELF vmlinux.  I 
> can convert it to ecoff with elf2ecoff, and attach an initrd image with 
> addinitrd.  The problem begins here.  I end up with an ecoff format 
> kernel which is not recognized by objcopy(1), and therefore no s-records.

I guess that was an act of desperation - YAMON needs SRECs to be happy
but doesn't know anything about SRECs.

> It seems there is a program called gensrec that would do the job, but 
> google doesn't want to tell me where to get it.  Some IRIX binary perhaps?

make vmlinux.srec; the resulting file will be in arch/mips/boot/vmlinux.srec.

> Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or 
> write an ELF version of addinitrd?  Other ideas?

Things vanish for a reason ...  Try CONFIG_INITRAMFS_SOURCE instead.

  Ralf

Re: initrd problem

[Ed Martini]

Ralf Baechle wrote:

>On Thu, Mar 10, 2005 at 03:42:04PM -0800, Ed Martini wrote:
>  
>
>>Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or 
>>write an ELF version of addinitrd?  Other ideas?
>>    
>>
>
>Things vanish for a reason ...  Try CONFIG_INITRAMFS_SOURCE instead.
>
>  Ralf
>
Ok.  Then let's get rid of it completly, and provide a replacement that 
works.

There were vestiges of embedded initrd in the ld script that were 
confusing when trying to sort things out. That, in conjunction with 
Documentation/initrd.txt made it hard to discover early user space and 
initramfs when coming from the old world (2.4).

Also, unless you move the location of .init.ramfs, it gets freed twice, 
leading to a panic.

 From the documentation alone it's impossible to figure out how to build 
your initramfs.  In various places the docs refer to the initial 
executable as /linuxrc, /kinit, /init, and possibly others.  If you read 
init/main.c you see that for an initramfs, your initial process will be 
started from /init.

diff -urN linux-2.6.11-linux-mips.org/arch/mips/kernel/vmlinux.lds.S 
linux/arch/mips/kernel/vmlinux.lds.S
--- linux-2.6.11-linux-mips.org/arch/mips/kernel/vmlinux.lds.S 
2005-03-15 13:41:51.000000000 -0800
+++ linux/arch/mips/kernel/vmlinux.lds.S 2005-03-15 14:34:00.339164936 -0800
@@ -54,13 +54,6 @@

     *(.data)

-   /* Align the initial ramdisk image (INITRD) on page boundaries. */
-   . = ALIGN(4096);
-   __rd_start = .;
-   *(.initrd)
-   . = ALIGN(4096);
-   __rd_end = .;
-
     CONSTRUCTORS
   }
   _gp = . + 0x8000;
@@ -82,6 +75,13 @@

   _edata =  .;   /* End of data section */

+   /* Align the initial ramfs image on page boundaries. */
+   /* It will be freed by init/initramfs.c */
+  . = ALIGN(4096);
+  __initramfs_start = .;
+  .init.ramfs : { *(.init.ramfs) }
+  __initramfs_end = .;
+
   /* will be freed after init */
   . = ALIGN(4096);  /* Init code and data */
   __init_begin = .;
@@ -118,10 +118,6 @@
   .con_initcall.init : { *(.con_initcall.init) }
   __con_initcall_end = .;
   SECURITY_INIT
-  . = ALIGN(4096);
-  __initramfs_start = .;
-  .init.ramfs : { *(.init.ramfs) }
-  __initramfs_end = .;
   . = ALIGN(32);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }

Re: initrd problem

[Ralf Baechle]

On Tue, Mar 15, 2005 at 02:37:45PM -0800, Ed Martini wrote:

> Ok.  Then let's get rid of it completly, and provide a replacement that 
> works.

Way to go.

> There were vestiges of embedded initrd in the ld script that were 
> confusing when trying to sort things out. That, in conjunction with 
> Documentation/initrd.txt made it hard to discover early user space and 
> initramfs when coming from the old world (2.4).

Correct and I've applied that part of your patch already while thinking
about the problem you describe below.

> Also, unless you move the location of .init.ramfs, it gets freed twice, 
> leading to a panic.

Interesting one.  When I tested the code recently it did work for me and
it shouldn't have changed since.  The way this is supposed to work is
by setting the page_count to 1 by using set_page_count and unmarking the
page as reserved, so after that point a free_page should actually succeed -
even if done twice as you've observed, first in populate_rootfs then
once more in free_initmem.

It seems a frighteningly bad idea though since it relies on no memory
from the initrd range being allocated between the two calls - or it would
end being freed by force, in use or not.  On startup Linux tends to
allocate memory starting from high address towards low addresses which
must be why we usually get away with this one.

> From the documentation alone it's impossible to figure out how to build 
> your initramfs.  In various places the docs refer to the initial 
> executable as /linuxrc, /kinit, /init, and possibly others.  If you read 
> init/main.c you see that for an initramfs, your initial process will be 
> started from /init.

I guess I read the code so I didn't notice the lacking qualities of the
documentation ...

  Ralf

initrd/initramfs problem

[Ed Martini]

What fails is when CONFIG_BLK_DEV_INITRD and CONFIG_INITRAMFS_SOURCE are 
both set.  I realize (now) that I don't need initrd at all, and 
initramfs works fine by itself, as you have tested.  It seems that the 
kernel may need some exclusion between these two mechanisms while the 
difference is sorted out.

I'm not totally up on Kconfig files, but maybe something like this in 
drivers/block/Kconfig:

config INITRAMFS_SOURCE
        string "Initramfs source file(s)"
        default ""
        depends on BLK_DEV_INITRD=n

Regarding the documenation it would have been helpful to me if 
Documentation/initrd.txt had a reference to 
Documentation/early-userspace/README.  I'm not sure who maintains that 
directory, or I'd send a suggestion.  tldp.org?

THX
Ed Martini


Original context: 
http://www.linux-mips.org/archives/linux-mips/2005-03/index.html


Ralf Baechle wrote:

>On Tue, Mar 15, 2005 at 02:37:45PM -0800, Ed Martini wrote:
>
>  
>
>>Also, unless you move the location of .init.ramfs, it gets freed twice, 
>>leading to a panic.
>>    
>>
>
>Interesting one.  When I tested the code recently it did work for me and
>it shouldn't have changed since.  The way this is supposed to work is
>by setting the page_count to 1 by using set_page_count and unmarking the
>page as reserved, so after that point a free_page should actually succeed -
>even if done twice as you've observed, first in populate_rootfs then
>once more in free_initmem.
>
>It seems a frighteningly bad idea though since it relies on no memory
>from the initrd range being allocated between the two calls - or it would
>end being freed by force, in use or not.  On startup Linux tends to
>allocate memory starting from high address towards low addresses which
>must be why we usually get away with this one.
>
>  
>
>>From the documentation alone it's impossible to figure out how to build 
>>your initramfs.  In various places the docs refer to the initial 
>>executable as /linuxrc, /kinit, /init, and possibly others.  If you read 
>>init/main.c you see that for an initramfs, your initial process will be 
>>started from /init.
>>    
>>
>
>I guess I read the code so I didn't notice the lacking qualities of the
>documentation ...
>
>  Ralf
>  
>

initrd/initramfs problem

[Ed Martini]

What fails is when CONFIG_BLK_DEV_INITRD and CONFIG_INITRAMFS_SOURCE are 
both set.  I realize (now) that I don't need initrd at all, and 
initramfs works fine by itself, as you have tested.  It seems that the 
kernel may need some exclusion between these two mechanisms while the 
difference is sorted out.

I'm not totally up on Kconfig files, but maybe something like this in 
drivers/block/Kconfig:

config INITRAMFS_SOURCE
      string "Initramfs source file(s)"
      default ""
      depends on BLK_DEV_INITRD=n

Regarding the documenation it would have been helpful to me if 
Documentation/initrd.txt had a reference to 
Documentation/early-userspace/README.  I'm not sure who maintains that 
directory, or I'd send a suggestion.  tldp.org?

THX
Ed Martini

Original context: 
http://www.linux-mips.org/archives/linux-mips/2005-03/index.html

Ralf Baechle wrote:

>On Tue, Mar 15, 2005 at 02:37:45PM -0800, Ed Martini wrote:
>  
>
>>Also, unless you move the location of .init.ramfs, it gets freed twice, 
>>leading to a panic.
>>    
>>
>
>Interesting one.  When I tested the code recently it did work for me and
>it shouldn't have changed since.  The way this is supposed to work is
>by setting the page_count to 1 by using set_page_count and unmarking the
>page as reserved, so after that point a free_page should actually succeed -
>even if done twice as you've observed, first in populate_rootfs then
>once more in free_initmem.
>
>It seems a frighteningly bad idea though since it relies on no memory
>from the initrd range being allocated between the two calls - or it would
>end being freed by force, in use or not.  On startup Linux tends to
>allocate memory starting from high address towards low addresses which
>must be why we usually get away with this one.
>
>  
>
>>From the documentation alone it's impossible to figure out how to build 
>>your initramfs.  In various places the docs refer to the initial 
>>executable as /linuxrc, /kinit, /init, and possibly others.  If you read 
>>init/main.c you see that for an initramfs, your initial process will be 
>>started from /init.
>>    
>>
>
>I guess I read the code so I didn't notice the lacking qualities of the
>documentation ...
>
>  Ralf
>  
>

Observations on LLSC and SMP

[Ed Martini]

In include/asm-mips/ atomic.h, bitops.h and system.h there are a bunch 
of inline functions which contain this logic:

        if (cpu_has_llsc && R10000_LLSC_WAR) {
                __asm__ (stuff)
        } else if (cpu_has_llsc) {
                __asm__ (other stuff)
        } else {
                C lang stuff;
        }

My two observations relate to both code size and runtime performance.  
These observations don't affect my situation, so I'm not inclined to 
spend a bunch of time on it, but maybe someone else is interested.  This 
should be especially interesting since these inline functions are used 
all over the kernel, so it might actually make a marginally significant 
difference.

I suppose there's a reason this code is the way it is.  If so, feel free 
to ignore me or flame away.

1. If the first part of the if were an ifdef instead it would result in 
a code size reduction as well as a runtime performance gain.

2. In atomic.h the "C lang stuff" is wrapped with a spinlock.  In the 
SMP case the spinlock will result in code that contains ll and sc 
instructions, so I infer that there are no SMP system configs that use 
CPUs that don't have the ll and sc instructions. 

Paranoid version:
-----
        if (cpu_has_llsc) {
#ifdef R10000_LLSC_WAR
                __asm__ (stuff)
#else
                __asm__ (other stuff)
#endif
        } else {
#ifdef CONFIG_SMP
                panic("SMP on CPUs with no LLSC is broken\n");
#else
                C lang stuff;
#endif
        }
-----
Most efficient version:
-----
#ifndef CONFIG_SMP
        if (cpu_has_llsc)
#endif
        {
#ifdef R10000_LLSC_WAR
                __asm__ (stuff)
#else
                __asm__ (other stuff)
#endif
        }
-----

Re: Observations on LLSC and SMP

[Daniel Jacobowitz]

On Fri, Mar 25, 2005 at 11:24:05AM -0800, Ed Martini wrote:
> 1. If the first part of the if were an ifdef instead it would result in 
> a code size reduction as well as a runtime performance gain.

You should spend a little time playing with an optimizing compiler. 
They're capable of working out when a condition will always be false.

> 2. In atomic.h the "C lang stuff" is wrapped with a spinlock.  In the 
> SMP case the spinlock will result in code that contains ll and sc 
> instructions, so I infer that there are no SMP system configs that use 
> CPUs that don't have the ll and sc instructions. 

That's correct.  It is not practical to implement SMP without a mutex
primitive.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Observations on LLSC and SMP

[Ed Martini]

Daniel Jacobowitz wrote:

>On Fri, Mar 25, 2005 at 11:24:05AM -0800, Ed Martini wrote:
>  
>
>>1. If the first part of the if were an ifdef instead it would result in 
>>a code size reduction as well as a runtime performance gain.
>>    
>>
>
>You should spend a little time playing with an optimizing compiler. 
>They're capable of working out when a condition will always be false.
>  
>
Yes, but in the case where R10000_LLSC_WAR is true, but cpu_has_llsc 
returns false there are still two wasted tests, and two blocks of code 
that the compiler can't optimize out.

Re: Observations on LLSC and SMP

[Daniel Jacobowitz]

On Fri, Mar 25, 2005 at 02:46:04PM -0800, Ed Martini wrote:
> Daniel Jacobowitz wrote:
> 
> >On Fri, Mar 25, 2005 at 11:24:05AM -0800, Ed Martini wrote:
> > 
> >
> >>1. If the first part of the if were an ifdef instead it would result in 
> >>a code size reduction as well as a runtime performance gain.
> >>   
> >>
> >
> >You should spend a little time playing with an optimizing compiler. 
> >They're capable of working out when a condition will always be false.
> > 
> >
> Yes, but in the case where R10000_LLSC_WAR is true, but cpu_has_llsc 
> returns false there are still two wasted tests, and two blocks of code 
> that the compiler can't optimize out.

Not only is cpu_has_llsc often a constant, R10000_LLSC_WAR will never
be true if the CPU does not have LL/SC.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: initrd problem

[colin]

Hi Kumba,
I used your patch for 2.6.11 on MIPS kernel, and found that it lost the
definition "kernel_physaddr".
Could you tell me where is it?

Regards,
Colin



----------------------------------------------------------------------------
---------------


Ed Martini wrote:
> Background:
>
> I'm trying to get 2.6.11 to run on a MIPS Malta board with Yamon.  The
> kernel that comes with the board is 2.4.18 with an embedded ramdisk that
> runs some scripts to install RPMS via NFS or CD-ROM.  The kernel is
> converted to s-records via objcopy(1), and loaded into memory via tftp.
> I want to do something similar with 2.6.latest.
>
> Problem:
>
> On or about Nov 21 of last year, the CONFIG_EMBEDDED_RAMDISK disappeared.
>
> http://www.linux-mips.org/archives/linux-mips/2004-11/msg00135.html
>
> In it's place it is suggested to use the tools in arch/mips/boot, so I
> tried it.  I can cross-compile the kernel, and I get an ELF vmlinux.  I
> can convert it to ecoff with elf2ecoff, and attach an initrd image with
> addinitrd.  The problem begins here.  I end up with an ecoff format
> kernel which is not recognized by objcopy(1), and therefore no s-records.
>
> It seems there is a program called gensrec that would do the job, but
> google doesn't want to tell me where to get it.  Some IRIX binary perhaps?
>
> Solution?
>
> Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or
> write an ELF version of addinitrd?  Other ideas?
>
> Thanks in advance.

The future is purportedly in the feature known as initramfs.  See the file
Documentation/early-userpace/README for more details on how that is supposed
to work.

That said, I tried initramfs a few times, but either due to lack of
understanding, or broken support code in 2.6.10, I couldn't get it to
properly
load an initrd bundled in, so I forward-ported a patch I wrote that
originally
fixed CONFIG_EMBEDDED_RAMDISK to work with any ABI to 2.6.10, and it worked
rather well.  I'm sticking with this method until I find more/better docs on
how to use initramfs properly.

If you're interested, the patch I use can be found here:
http://dev.gentoo.org/~kumba/mips/misc/misc-2.6.10-add-ramdisk-back.patch
[2.6.10]
http://dev.gentoo.org/~kumba/mips/misc/misc-2.6.11-add-ramdisk-back.patch
[2.6.11]


--Kumba

Re: initrd problem

[colin]

Hi Kumba,
I used your patch for 2.6.11 on MIPS kernel, and found that it lost the
definition "kernel_physaddr".
Could you tell me where is it?

Regards,
Colin



----------------------------------------------------------------------------
---------------


Ed Martini wrote:
> Background:
>
> I'm trying to get 2.6.11 to run on a MIPS Malta board with Yamon.  The
> kernel that comes with the board is 2.4.18 with an embedded ramdisk that
> runs some scripts to install RPMS via NFS or CD-ROM.  The kernel is
> converted to s-records via objcopy(1), and loaded into memory via tftp.
> I want to do something similar with 2.6.latest.
>
> Problem:
>
> On or about Nov 21 of last year, the CONFIG_EMBEDDED_RAMDISK disappeared.
>
> http://www.linux-mips.org/archives/linux-mips/2004-11/msg00135.html
>
> In it's place it is suggested to use the tools in arch/mips/boot, so I
> tried it.  I can cross-compile the kernel, and I get an ELF vmlinux.  I
> can convert it to ecoff with elf2ecoff, and attach an initrd image with
> addinitrd.  The problem begins here.  I end up with an ecoff format
> kernel which is not recognized by objcopy(1), and therefore no s-records.
>
> It seems there is a program called gensrec that would do the job, but
> google doesn't want to tell me where to get it.  Some IRIX binary perhaps?
>
> Solution?
>
> Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or
> write an ELF version of addinitrd?  Other ideas?
>
> Thanks in advance.

The future is purportedly in the feature known as initramfs.  See the file
Documentation/early-userpace/README for more details on how that is supposed
to work.

That said, I tried initramfs a few times, but either due to lack of
understanding, or broken support code in 2.6.10, I couldn't get it to
properly
load an initrd bundled in, so I forward-ported a patch I wrote that
originally
fixed CONFIG_EMBEDDED_RAMDISK to work with any ABI to 2.6.10, and it worked
rather well.  I'm sticking with this method until I find more/better docs on
how to use initramfs properly.

If you're interested, the patch I use can be found here:
http://dev.gentoo.org/~kumba/mips/misc/misc-2.6.10-add-ramdisk-back.patch
[2.6.10]
http://dev.gentoo.org/~kumba/mips/misc/misc-2.6.11-add-ramdisk-back.patch
[2.6.11]


--Kumba

initrd problem

[Alexander Shiyan]

Hello.

I successfully use the barebox with custom board based on CC-i.MX51 module.
I am using 30MB UBI volume as initrd for root filesystem. This configuration is
works fine for me.

I decided to change the size of the UBI volume for the root file system to 60 MB.
Now I get a weird OOM error. Turning on debug information shows a conflict,
but I do not quite understand where to look for the problem.
Where is the starting point to try to solve this problem?


barebox 2018.12.0-00337-g5ff5b7b05-dirty #11 Thu Jan 24 12:17:32 MSK 2019

Board: Mega-Milas Informer i.MX51
__request_region ok: 0x73fa8000:0x73fabfff
__request_region ok: 0x73fd4000:0x73fd7fff
__request_region ok: 0x73fa0000:0x73fa3fff
__request_region ok: 0x73f84000:0x73f87fff
__request_region ok: 0x73f88000:0x73f8bfff
__request_region ok: 0x73f8c000:0x73f8ffff
__request_region ok: 0x73f90000:0x73f93fff
__request_region ok: 0x90000000:0x97ffffff
detected i.MX51 revision 3.0
i.MX reset reason POR (SRSR: 0x00000001)
__request_region ok: 0x73fd0000:0x73fd3fff
__request_region ok: 0x7000c000:0x7000ffff
__request_region ok: 0x73fbc000:0x73fbffff
__request_region ok: 0x73fc0000:0x73fc3fff
__request_region ok: 0x83fd9000:0x83fd9fff
__request_region ok: 0x97fe4000:0x97fe7fff
__request_region: 0x00000000:0x00000fff outside parent resource 0x90000000:0x97ffffff
__request_region ok: 0x95df8d40:0x97df8d3f
__request_region ok: 0x97e00000:0x97e6e517
__request_region ok: 0x97e6e518:0x97e86707
__request_region ok: 0x97e86708:0x97e897df
__request_region ok: 0x73f80800:0x73f809ff
__request_region ok: 0x70010000:0x70013fff
__request_region ok: 0x83fac000:0x83faffff
__request_region ok: 0x83fc4000:0x83fc7fff
mc13xxx-spi mc13892@00: Found MC13892 ID: 0x0045d0 [Rev: 2.0a]
__request_region ok: 0x73fb4000:0x73fb7fff
__request_region ok: 0x73fb8000:0x73fbbfff
__request_region ok: 0x83f98000:0x83f9bfff
__request_region ok: 0x97fe8000:0x97feffff
Module Variant: i.MX515@600MHz, PHY, Accel (0x0b)
Module HW Rev : 03
Module Serial : W115171467
__request_region ok: 0x98000000:0x9fffffff
MC13892 PMIC initialized.
__request_region ok: 0x83fdb000:0x83fdbfff
__request_region ok: 0xcfff0000:0xcfffffff
nand: ONFI flash detected
nand: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
__request_region ok: 0x73f80000:0x73f801ff
imx-usb 73f80000.usb@73f80000: USB EHCI 1.00
__request_region ok: 0x73f80200:0x73f803ff
imx-usb 73f80200.usb@73f80200: USB EHCI 1.00
__request_region ok: 0x70004000:0x70007fff
imx-esdhc 70004000.esdhc@70004000: registered as mmc0
__request_region ok: 0x70008000:0x7000bfff
ERROR: mmc1: Failed to get 'vmmc' regulator.
imx-esdhc 70008000.esdhc@70008000: registered as mmc1
__request_region ok: 0x40000000:0x5fffffff
imx-ipuv3 40000000.ipu@40000000: IPUv3EX probed
__request_region ok: 0x1ffe0000:0x1fffffff
__request_region ok: 0x73f98000:0x73f9bfff
__request_region ok: 0x83fda000:0x83fdafff
imx-weim 83fda000.weim@83fda000: WEIM driver registered.
__request_region ok: 0x97df8d40:0x97dfffde
malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
envfs: no envfs (magic mismatch) - envfs never written?
running /env/bin/init...
imx-ipuv3-crtc imx-ipuv3-crtc0: ipu_crtc_mode_set: mode->xres: 320
imx-ipuv3-crtc imx-ipuv3-crtc0: ipu_crtc_mode_set: mode->yres: 240
i2c_write: I/O error
i2c_write: I/O error
NOTICE: ubi0: scanning is finished
NOTICE: ubi0: registering /dev/nand0.system.ubi
NOTICE: ubi0: registering kernel as /dev/nand0.system.ubi.kernel
NOTICE: ubi0: registering root as /dev/nand0.system.ubi.root
NOTICE: ubi0: registering bbox as /dev/nand0.system.ubi.bbox
NOTICE: ubi0: attached mtd0 (name "nand0.system", size 255 MiB) to ubi0
NOTICE: ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
NOTICE: ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
NOTICE: ubi0: VID header offset: 512 (aligned 512), data offset: 2048
NOTICE: ubi0: good PEBs: 2040, bad PEBs: 2, corrupted PEBs: 0
NOTICE: ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
NOTICE: ubi0: max/mean erase counter: 30/16, WL threshold: 4096, image sequence number: 23290
NOTICE: ubi0: available PEBs: 0, total reserved PEBs: 2040, PEBs reserved for bad PEB handling: 38

Hit any key to stop autoboot:    2   1   0
booting 'nand'

Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
__request_region ok: 0x92000000:0x922a244f
1 0xffffffff
2 0x923a3000
__request_region ok: 0x923a3000:0x923c2fff
__request_region ok: 0x923a3000:0x923e2fff
__request_region ok: 0x923a3000:0x92402fff
...
__request_region ok: 0x923a3000:0x95da2fff
__request_region ok: 0x923a3000:0x95dc2fff
__request_region ok: 0x923a3000:0x95de2fff
__request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
__request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
unable to request SDRAM 0x923a3000-0x95e02fff
ERROR: Booting 'nand' failed: Out of memory
booting 'nand' failed: Out of memory
boot: Out of memory
barebox@Mega-Milas Informer i.MX51:/


---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Sascha Hauer]

Hi Alexander,

Sorry for the delay. Has this been resolved in the meantime?

On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
> I decided to change the size of the UBI volume for the root file system to 60 MB.
> Now I get a weird OOM error. Turning on debug information shows a conflict,
> but I do not quite understand where to look for the problem.
> Where is the starting point to try to solve this problem?
> 
> 
> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
> 
> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
> __request_region ok: 0x92000000:0x922a244f

The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
to avoid relocation. This is what we see here.

> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f

Now we try allocate space for the initrd above it which is 60MiB. This
conflicts with the malloc space.

So yes, you're out of memory.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Alexander Shiyan]

Hello.

>Среда, 30 января 2019, 9:08 +03:00 от Sascha Hauer <s.hauer@pengutronix.de>:
>Sorry for the delay. Has this been resolved in the meantime?

Still no.

>On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
>> I decided to change the size of the UBI volume for the root file system to 60 MB.
>> Now I get a weird OOM error. Turning on debug information shows a conflict,
>> but I do not quite understand where to look for the problem.
>> Where is the starting point to try to solve this problem?
>> 
>> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
>> 
>> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
>> __request_region ok: 0x92000000:0x922a244f
>The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
>to avoid relocation. This is what we see here.
>
>> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
>
>Now we try allocate space for the initrd above it which is 60MiB. This
>conflicts with the malloc space.
>
>So yes, you're out of memory.
Memory should be enough (256 Mb). I think the problem is that the memory is
divided into two banks of 128 Mb each.

Just look for a next line:
__request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff

Maybe we need some kind of option to merge nearby banks?

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Alexander Shiyan]

>>On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
>>> I decided to change the size of the UBI volume for the root file system to 60 MB.
>>> Now I get a weird OOM error. Turning on debug information shows a conflict,
>>> but I do not quite understand where to look for the problem.
>>> Where is the starting point to try to solve this problem?
>>> 
>>> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
>>> 
>>> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
>>> __request_region ok: 0x92000000:0x922a244f
>>The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
>>to avoid relocation. This is what we see here.
>>
>>> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
>>
>>Now we try allocate space for the initrd above it which is 60MiB. This
>>conflicts with the malloc space.
>>
>>So yes, you're out of memory.
>Memory should be enough (256 Mb). I think the problem is that the memory is
>divided into two banks of 128 Mb each.
>
>Just look for a next line:
>__request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
>
>Maybe we need some kind of option to merge nearby banks?

Problem is resolved by adding:
global.bootm.initrd.loadaddr=0x98000000

...But I do not really like this method.

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Sascha Hauer]

On Wed, Jan 30, 2019 at 11:03:02AM +0300, Alexander Shiyan wrote:
> Hello.
> 
> >Среда, 30 января 2019, 9:08 +03:00 от Sascha Hauer <s.hauer@pengutronix.de>:
> >Sorry for the delay. Has this been resolved in the meantime?
> 
> Still no.
> 
> >On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
> >> I decided to change the size of the UBI volume for the root file system to 60 MB.
> >> Now I get a weird OOM error. Turning on debug information shows a conflict,
> >> but I do not quite understand where to look for the problem.
> >> Where is the starting point to try to solve this problem?
> >> 
> >> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
> >> 
> >> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
> >> __request_region ok: 0x92000000:0x922a244f
> >The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
> >to avoid relocation. This is what we see here.
> >
> >> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
> >
> >Now we try allocate space for the initrd above it which is 60MiB. This
> >conflicts with the malloc space.
> >
> >So yes, you're out of memory.
> Memory should be enough (256 Mb). I think the problem is that the memory is
> divided into two banks of 128 Mb each.
> 
> Just look for a next line:
> __request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
> 
> Maybe we need some kind of option to merge nearby banks?

If I'm not mistaken the banks are not really nearby. You should have two
banks, one from 0x90000000 to 0x97ffffff and one from 0xa0000000 to
0xa7ffffff.
I don't know where the resource 0x98000000:0x9fffffff comes from. Could
you paste the output of the iomem command? Are you using the code from
arch/arm/mach-imx/esdctl.c or are you bypassing it?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Alexander Shiyan]

>> >On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
>> >> I decided to change the size of the UBI volume for the root file system to 60 MB.
>> >> Now I get a weird OOM error. Turning on debug information shows a conflict,
>> >> but I do not quite understand where to look for the problem.
>> >> Where is the starting point to try to solve this problem?
>> >> 
>> >> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
>> >> 
>> >> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
>> >> __request_region ok: 0x92000000:0x922a244f
>> >The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
>> >to avoid relocation. This is what we see here.
>> >
>> >> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
>> >
>> >Now we try allocate space for the initrd above it which is 60MiB. This
>> >conflicts with the malloc space.
>> >
>> >So yes, you're out of memory.
>> Memory should be enough (256 Mb). I think the problem is that the memory is
>> divided into two banks of 128 Mb each.
>> 
>> Just look for a next line:
>> __request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
>> 
>> Maybe we need some kind of option to merge nearby banks?
>
>If I'm not mistaken the banks are not really nearby. You should have two
>banks, one from 0x90000000 to 0x97ffffff and one from 0xa0000000 to
>0xa7ffffff.
>I don't know where the resource 0x98000000:0x9fffffff comes from. Could
>you paste the output of the iomem command? Are you using the code from
>arch/arm/mach-imx/esdctl.c or are you bypassing it?

It is not an error. CCMX51 not using ESDCTL.
The first bank is minimal size 128M. The second is a chain to first, its size
depends on module variant.

barebox@Mega-Milas Informer i.MX51:/ iomem
0x00000000 - 0xffffffff (size 0x00000000) iomem
  0x1ffe0000 - 0x1fffffff (size 0x00020000) 1ffe0000.iram@1ffe0000
  0x40000000 - 0x5fffffff (size 0x20000000) 40000000.ipu@40000000
  0x70004000 - 0x70007fff (size 0x00004000) 70004000.esdhc@70004000
  0x70008000 - 0x7000bfff (size 0x00004000) 70008000.esdhc@70008000
  0x7000c000 - 0x7000ffff (size 0x00004000) 7000c000.serial@7000c000
  0x70010000 - 0x70013fff (size 0x00004000) 70010000.spi@70010000
  0x73f80000 - 0x73f801ff (size 0x00000200) 73f80000.usb@73f80000
  0x73f80200 - 0x73f803ff (size 0x00000200) 73f80200.usb@73f80200
  0x73f80800 - 0x73f809ff (size 0x00000200) 73f80800.usbmisc@73f80800
  0x73f84000 - 0x73f87fff (size 0x00004000) 73f84000.gpio@73f84000
  0x73f88000 - 0x73f8bfff (size 0x00004000) 73f88000.gpio@73f88000
  0x73f8c000 - 0x73f8ffff (size 0x00004000) 73f8c000.gpio@73f8c000
  0x73f90000 - 0x73f93fff (size 0x00004000) 73f90000.gpio@73f90000
  0x73f98000 - 0x73f9bfff (size 0x00004000) 73f98000.wdog@73f98000
  0x73fa0000 - 0x73fa3fff (size 0x00004000) 73fa0000.timer@73fa0000
  0x73fa8000 - 0x73fabfff (size 0x00004000) 73fa8000.iomuxc@73fa8000
  0x73fb4000 - 0x73fb7fff (size 0x00004000) 73fb4000.pwm@73fb4000
  0x73fb8000 - 0x73fbbfff (size 0x00004000) 73fb8000.pwm@73fb8000
  0x73fbc000 - 0x73fbffff (size 0x00004000) 73fbc000.serial@73fbc000
  0x73fc0000 - 0x73fc3fff (size 0x00004000) 73fc0000.serial@73fc0000
  0x73fd0000 - 0x73fd3fff (size 0x00004000) 73fd0000.src@73fd0000
  0x73fd4000 - 0x73fd7fff (size 0x00004000) 73fd4000.ccm@73fd4000
  0x83f98000 - 0x83f9bfff (size 0x00004000) 83f98000.iim@83f98000
  0x83fac000 - 0x83faffff (size 0x00004000) 83fac000.spi@83fac000
  0x83fc4000 - 0x83fc7fff (size 0x00004000) 83fc4000.i2c@83fc4000
  0x83fd9000 - 0x83fd9fff (size 0x00001000) imx51-esdctl0
  0x83fda000 - 0x83fdafff (size 0x00001000) 83fda000.weim@83fda000
  0x83fdb000 - 0x83fdbfff (size 0x00001000) 83fdb000.nand@83fdb000
  0x90000000 - 0x97ffffff (size 0x08000000) ram0
    0x95df8d40 - 0x97df8d3f (size 0x02000000) malloc space
    0x97df8d40 - 0x97dfffde (size 0x0000729f) board data
    0x97e00000 - 0x97e6e537 (size 0x0006e538) barebox
    0x97e6e538 - 0x97e86727 (size 0x000181f0) barebox data
    0x97e86728 - 0x97e897ff (size 0x000030d8) bss
    0x97fe4000 - 0x97fe7fff (size 0x00004000) ttb
    0x97fe8000 - 0x97feffff (size 0x00008000) stack
  0x98000000 - 0x9fffffff (size 0x08000000) ram1
  0xcfff0000 - 0xcfffffff (size 0x00010000) 83fdb000.nand@83fdb000

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Sascha Hauer]

On Wed, Jan 30, 2019 at 12:20:38PM +0300, Alexander Shiyan wrote:
> >> >On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
> >> >> I decided to change the size of the UBI volume for the root file system to 60 MB.
> >> >> Now I get a weird OOM error. Turning on debug information shows a conflict,
> >> >> but I do not quite understand where to look for the problem.
> >> >> Where is the starting point to try to solve this problem?
> >> >> 
> >> >> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
> >> >> 
> >> >> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
> >> >> __request_region ok: 0x92000000:0x922a244f
> >> >The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
> >> >to avoid relocation. This is what we see here.
> >> >
> >> >> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
> >> >
> >> >Now we try allocate space for the initrd above it which is 60MiB. This
> >> >conflicts with the malloc space.
> >> >
> >> >So yes, you're out of memory.
> >> Memory should be enough (256 Mb). I think the problem is that the memory is
> >> divided into two banks of 128 Mb each.
> >> 
> >> Just look for a next line:
> >> __request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
> >> 
> >> Maybe we need some kind of option to merge nearby banks?
> >
> >If I'm not mistaken the banks are not really nearby. You should have two
> >banks, one from 0x90000000 to 0x97ffffff and one from 0xa0000000 to
> >0xa7ffffff.
> >I don't know where the resource 0x98000000:0x9fffffff comes from. Could
> >you paste the output of the iomem command? Are you using the code from
> >arch/arm/mach-imx/esdctl.c or are you bypassing it?
> 
> It is not an error. CCMX51 not using ESDCTL.
> The first bank is minimal size 128M. The second is a chain to first, its size
> depends on module variant.

I see. Similar to what is done in arch/arm/boards/ccxmx51/ccxmx51.c,
right?

In that case merging the two banks won't give you much since barebox
will already be placed in the middle of the available RAM.

Can't you shuffle the code so that you can detect the board variant and
thus the amount of SDRAM before even calling barebox_arm_entry? You
would need some early variant of imx_iim_read(), but in the end this
goes down to a register read, so shouldn't be hard to implement.
Then you could drop the splitting into separate SDRAM regions entirely.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Alexander Shiyan]

>Среда, 30 января 2019, 12:35 +03:00 от Sascha Hauer <s.hauer@pengutronix.de>:
>> >> >> I decided to change the size of the UBI volume for the root file system to 60 MB.
>> >> >> Now I get a weird OOM error. Turning on debug information shows a conflict,
>> >> >> but I do not quite understand where to look for the problem.
>> >> >> Where is the starting point to try to solve this problem?
>> >> >> 
>> >> >> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
>> >> >> 
>> >> >> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
>> >> >> __request_region ok: 0x92000000:0x922a244f
>> >> >The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
>> >> >to avoid relocation. This is what we see here.
>> >> >
>> >> >> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
>> >> >
>> >> >Now we try allocate space for the initrd above it which is 60MiB. This
>> >> >conflicts with the malloc space.
>> >> >
>> >> >So yes, you're out of memory.
>> >> Memory should be enough (256 Mb). I think the problem is that the memory is
>> >> divided into two banks of 128 Mb each.
>> >> 
>> >> Just look for a next line:
>> >> __request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
>> >> 
>> >> Maybe we need some kind of option to merge nearby banks?
>> >
>> >If I'm not mistaken the banks are not really nearby. You should have two
>> >banks, one from 0x90000000 to 0x97ffffff and one from 0xa0000000 to
>> >0xa7ffffff.
>> >I don't know where the resource 0x98000000:0x9fffffff comes from. Could
>> >you paste the output of the iomem command? Are you using the code from
>> >arch/arm/mach-imx/esdctl.c or are you bypassing it?
>> 
>> It is not an error. CCMX51 not using ESDCTL.
>> The first bank is minimal size 128M. The second is a chain to first, its size
>> depends on module variant.
>
>I see. Similar to what is done in arch/arm/boards/ccxmx51/ccxmx51.c,
>right?
>
>In that case merging the two banks won't give you much since barebox
>will already be placed in the middle of the available RAM.
>
>Can't you shuffle the code so that you can detect the board variant and
>thus the amount of SDRAM before even calling barebox_arm_entry? You
>would need some early variant of imx_iim_read(), but in the end this
>goes down to a register read, so shouldn't be hard to implement.
>Then you could drop the splitting into separate SDRAM regions entirely.

At the moment I have used an alternative method to solve this problem.
I have reduced MALLOC_SIZE to 16 Mb and as a result, the 60 Mb initd
loaded fine for boards with 128 MB RAM.

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox