Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

2018-04-12 Thread H. Nikolaus Schaller
Hi Tony,

> Am 12.04.2018 um 17:03 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [180411 07:05]:
>>> Am 10.04.2018 um 22:56 schrieb Ladislav Michl :
>>> Well, that's a shame... However, this code is in production for several
>>> months now,
>> 
>> Well, we could have tested earlier release-candidates...
> 
> I've found it's way easier to test Linux next on regular basis
> and report the regressions compared to chasing regressions after
> the merge window or tagged kernels. By that time you may have
> already multiple regressions to deal with which is always fun.
> 
> If you have products running with mainline kernel, maybe set up
> automated boot testing for core devices to catch regressions
> early?

Well, it is rare that we face upstream regressions of this severe
kind. Every 2-3 years... We much more often have to face missing
features in upstream so that we add our own patch sets on top
of each -rc.

In this case here we could have found this right after the merge window
when v4.16-rc1 came out. But by bad chance (and holidays and other
more important tasks) we did only test on GTA04 boards with standard
NAND. And just now did boot a board with OneNAND installed and were
surprised by this boot problem.

BR,
Nikolaus





Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

2018-04-12 Thread H. Nikolaus Schaller
Hi Tony,

> Am 12.04.2018 um 17:03 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [180411 07:05]:
>>> Am 10.04.2018 um 22:56 schrieb Ladislav Michl :
>>> Well, that's a shame... However, this code is in production for several
>>> months now,
>> 
>> Well, we could have tested earlier release-candidates...
> 
> I've found it's way easier to test Linux next on regular basis
> and report the regressions compared to chasing regressions after
> the merge window or tagged kernels. By that time you may have
> already multiple regressions to deal with which is always fun.
> 
> If you have products running with mainline kernel, maybe set up
> automated boot testing for core devices to catch regressions
> early?

Well, it is rare that we face upstream regressions of this severe
kind. Every 2-3 years... We much more often have to face missing
features in upstream so that we add our own patch sets on top
of each -rc.

In this case here we could have found this right after the merge window
when v4.16-rc1 came out. But by bad chance (and holidays and other
more important tasks) we did only test on GTA04 boards with standard
NAND. And just now did boot a board with OneNAND installed and were
surprised by this boot problem.

BR,
Nikolaus





Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

2018-04-12 Thread Tony Lindgren
* H. Nikolaus Schaller  [180411 07:05]:
> > Am 10.04.2018 um 22:56 schrieb Ladislav Michl :
> > Well, that's a shame... However, this code is in production for several
> > months now,
> 
> Well, we could have tested earlier release-candidates...

I've found it's way easier to test Linux next on regular basis
and report the regressions compared to chasing regressions after
the merge window or tagged kernels. By that time you may have
already multiple regressions to deal with which is always fun.

If you have products running with mainline kernel, maybe set up
automated boot testing for core devices to catch regressions
early?

Regards,

Tony


Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

2018-04-12 Thread Tony Lindgren
* H. Nikolaus Schaller  [180411 07:05]:
> > Am 10.04.2018 um 22:56 schrieb Ladislav Michl :
> > Well, that's a shame... However, this code is in production for several
> > months now,
> 
> Well, we could have tested earlier release-candidates...

I've found it's way easier to test Linux next on regular basis
and report the regressions compared to chasing regressions after
the merge window or tagged kernels. By that time you may have
already multiple regressions to deal with which is always fun.

If you have products running with mainline kernel, maybe set up
automated boot testing for core devices to catch regressions
early?

Regards,

Tony


Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

2018-04-11 Thread H. Nikolaus Schaller
Hi Ladislav,

> Am 10.04.2018 um 22:56 schrieb Ladislav Michl :
> 
> Hi Nikolaus,
> 
> On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
>> Hi,
>> we just started testing the v4.16 kernel and found the
>> device no longer bootable (works with v4.15). It turned
>> out that there was a harmful modification somewhere between
>> v4.15.0 and v4.16-rc1.
>> 
>> A git bisect points to this patch:
> 
> Well, that's a shame... However, this code is in production for several
> months now,

Well, we could have tested earlier release-candidates...

> so could you, please put 'goto out_copy' if 'buf >= high_memory'
> condition is met, ie:
> --- a/drivers/mtd/nand/onenand/omap2.c
> +++ b/drivers/mtd/nand/onenand/omap2.c
> @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
> *mtd, int area,
>   if (buf >= high_memory) {
>   struct page *p1;
> 
> + goto out_copy;
>   if (((size_t)buf & PAGE_MASK) !=
>   ((size_t)(buf + count - 1) & PAGE_MASK))
>   goto out_copy;
> and in case it does not help put the same goto at the very beginning of
> omap2_onenand_read_bufferram function and report result?

Yes, works for me. Device boots and I can mount the NAND to inspect the
ubifs.

Only omap2_onenand_write_bufferram has the same problem, but that is to
be expected.

I'll try you new patch now.

> 
> Thank you for cooperation,
>   ladis

Thanks for the quick reply and analysis.

BR,
Nikolaus

> 
>> commit bdaca9345d41fd9420995469d27603ea62054691
>> Author: Ladislav Michl 
>> Date:   Fri Jan 12 14:16:57 2018 +0100
>> 
>>   mtd: onenand: omap2: Decouple DMA enabling from INT pin availability
>> 
>>   INT pin (gpio_irq) is not really needed for DMA but only for notification
>>   when a command that needs wait has completed. DMA memcpy can be still used
>>   even without gpio_irq available, so enable it unconditionally.
>> 
>>   Signed-off-by: Ladislav Michl 
>>   Reviewed-by: Peter Ujfalusi 
>>   Tested-by: Tony Lindgren 
>>   Tested-by: Aaro Koskinen 
>>   Acked-by: Roger Quadros 
>>   Signed-off-by: Boris Brezillon 
>> 
>> Kernel panic log is attached which indeed indicates a DMA problem.
>> 
>> Note that we have added compatible = "ti,omap2-onenand";
>> 
>> Any suggestions, fixes?
>> 
>> BR and thanks,
>> Nikolaus Schaller
>> 
>> 
>> 
>> ## Booting kernel from Legacy Image at 8200 ...
>>   Image Name:   Linux-4.16.0-letux+
>>   Image Type:   ARM Linux Kernel Image (uncompressed)
>>   Data Size:4456744 Bytes = 4.3 MiB
>>   Load Address: 80008000
>>   Entry Point:  80008000
>>   Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 81c0
>>   Booting using the fdt blob at 0x81c0
>>   Loading Kernel Image ... OK
>>   Using Device Tree in place at 81c0, end 81c14a1e
>> 
>> Starting kernel ...
>> 
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Linux version 4.16.0-letux+ (hns@iMac.local) (gcc version 
>> 4.9.2 (GCC)) #2187 SMP PREEMPT Tue Apr 10 16:23:45 CEST 2018
>> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
>> cr=10c5387d
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
>> instruction cache
>> [0.00] OF: fdt: Machine model: Goldelico GTA04A5/Letux 2804
>> [0.00] debug: ignoring loglevel setting.
>> [0.00] Memory policy: Data cache writeback
>> [0.00] cma: Reserved 16 MiB at 0xbe80
>> [0.00] On node 0 totalpages: 261632
>> [0.00]   Normal zone: 1536 pages used for memmap
>> [0.00]   Normal zone: 0 pages reserved
>> [0.00]   Normal zone: 196608 pages, LIFO batch:31
>> [0.00]   HighMem zone: 65024 pages, LIFO batch:15
>> [0.00] CPU: All CPU(s) started in SVC mode.
>> [0.00] OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
>> [0.00] random: fast init done
>> [0.00] percpu: Embedded 17 pages/cpu @(ptrval) s39744 r8192 d21696 
>> u69632
>> [0.00] pcpu-alloc: s39744 r8192 d21696 u69632 alloc=17*4096
>> [0.00] pcpu-alloc: [0] 0 
>> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
>> [0.00] Kernel command line: console=ttyO2,115200n8 
>> mtdoops.mtddev=omap2.nand ubi.mtd=4 root=/dev/mmcblk0p1 rw 
>> rootfstype=ext4,ext3 rootwait console=ttyO2,115200n8 vram=12M 
>> omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait 
>> twl4030_charger.allow_usb=1 log_buf_len=8M ignore_loglevel earlyprintk
>> [0.00] log_buf_len: 8388608 bytes
>> [0.00] early log buf free: 63924(97%)
>> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
>> bytes)
>> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>> [

Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

2018-04-11 Thread H. Nikolaus Schaller
Hi Ladislav,

> Am 10.04.2018 um 22:56 schrieb Ladislav Michl :
> 
> Hi Nikolaus,
> 
> On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
>> Hi,
>> we just started testing the v4.16 kernel and found the
>> device no longer bootable (works with v4.15). It turned
>> out that there was a harmful modification somewhere between
>> v4.15.0 and v4.16-rc1.
>> 
>> A git bisect points to this patch:
> 
> Well, that's a shame... However, this code is in production for several
> months now,

Well, we could have tested earlier release-candidates...

> so could you, please put 'goto out_copy' if 'buf >= high_memory'
> condition is met, ie:
> --- a/drivers/mtd/nand/onenand/omap2.c
> +++ b/drivers/mtd/nand/onenand/omap2.c
> @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
> *mtd, int area,
>   if (buf >= high_memory) {
>   struct page *p1;
> 
> + goto out_copy;
>   if (((size_t)buf & PAGE_MASK) !=
>   ((size_t)(buf + count - 1) & PAGE_MASK))
>   goto out_copy;
> and in case it does not help put the same goto at the very beginning of
> omap2_onenand_read_bufferram function and report result?

Yes, works for me. Device boots and I can mount the NAND to inspect the
ubifs.

Only omap2_onenand_write_bufferram has the same problem, but that is to
be expected.

I'll try you new patch now.

> 
> Thank you for cooperation,
>   ladis

Thanks for the quick reply and analysis.

BR,
Nikolaus

> 
>> commit bdaca9345d41fd9420995469d27603ea62054691
>> Author: Ladislav Michl 
>> Date:   Fri Jan 12 14:16:57 2018 +0100
>> 
>>   mtd: onenand: omap2: Decouple DMA enabling from INT pin availability
>> 
>>   INT pin (gpio_irq) is not really needed for DMA but only for notification
>>   when a command that needs wait has completed. DMA memcpy can be still used
>>   even without gpio_irq available, so enable it unconditionally.
>> 
>>   Signed-off-by: Ladislav Michl 
>>   Reviewed-by: Peter Ujfalusi 
>>   Tested-by: Tony Lindgren 
>>   Tested-by: Aaro Koskinen 
>>   Acked-by: Roger Quadros 
>>   Signed-off-by: Boris Brezillon 
>> 
>> Kernel panic log is attached which indeed indicates a DMA problem.
>> 
>> Note that we have added compatible = "ti,omap2-onenand";
>> 
>> Any suggestions, fixes?
>> 
>> BR and thanks,
>> Nikolaus Schaller
>> 
>> 
>> 
>> ## Booting kernel from Legacy Image at 8200 ...
>>   Image Name:   Linux-4.16.0-letux+
>>   Image Type:   ARM Linux Kernel Image (uncompressed)
>>   Data Size:4456744 Bytes = 4.3 MiB
>>   Load Address: 80008000
>>   Entry Point:  80008000
>>   Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 81c0
>>   Booting using the fdt blob at 0x81c0
>>   Loading Kernel Image ... OK
>>   Using Device Tree in place at 81c0, end 81c14a1e
>> 
>> Starting kernel ...
>> 
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Linux version 4.16.0-letux+ (hns@iMac.local) (gcc version 
>> 4.9.2 (GCC)) #2187 SMP PREEMPT Tue Apr 10 16:23:45 CEST 2018
>> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
>> cr=10c5387d
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
>> instruction cache
>> [0.00] OF: fdt: Machine model: Goldelico GTA04A5/Letux 2804
>> [0.00] debug: ignoring loglevel setting.
>> [0.00] Memory policy: Data cache writeback
>> [0.00] cma: Reserved 16 MiB at 0xbe80
>> [0.00] On node 0 totalpages: 261632
>> [0.00]   Normal zone: 1536 pages used for memmap
>> [0.00]   Normal zone: 0 pages reserved
>> [0.00]   Normal zone: 196608 pages, LIFO batch:31
>> [0.00]   HighMem zone: 65024 pages, LIFO batch:15
>> [0.00] CPU: All CPU(s) started in SVC mode.
>> [0.00] OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
>> [0.00] random: fast init done
>> [0.00] percpu: Embedded 17 pages/cpu @(ptrval) s39744 r8192 d21696 
>> u69632
>> [0.00] pcpu-alloc: s39744 r8192 d21696 u69632 alloc=17*4096
>> [0.00] pcpu-alloc: [0] 0 
>> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
>> [0.00] Kernel command line: console=ttyO2,115200n8 
>> mtdoops.mtddev=omap2.nand ubi.mtd=4 root=/dev/mmcblk0p1 rw 
>> rootfstype=ext4,ext3 rootwait console=ttyO2,115200n8 vram=12M 
>> omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait 
>> twl4030_charger.allow_usb=1 log_buf_len=8M ignore_loglevel earlyprintk
>> [0.00] log_buf_len: 8388608 bytes
>> [0.00] early log buf free: 63924(97%)
>> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
>> bytes)
>> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>> [0.00] Memory: 1002524K/1046528K available (6169K kernel code, 626K 
>> rwdata, 1660K rodata, 1024K init, 218K bss, 27620K reserved, 16384K 
>> cma-reserved, 243712K highmem)
>> [   

Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

2018-04-10 Thread Ladislav Michl
Hi Nikolaus,

On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> Hi,
> we just started testing the v4.16 kernel and found the
> device no longer bootable (works with v4.15). It turned
> out that there was a harmful modification somewhere between
> v4.15.0 and v4.16-rc1.
> 
> A git bisect points to this patch:

Well, that's a shame... However, this code is in production for several
months now, so could you, please put 'goto out_copy' if 'buf >= high_memory'
condition is met, ie:
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
if (buf >= high_memory) {
struct page *p1;
 
+   goto out_copy;
if (((size_t)buf & PAGE_MASK) !=
((size_t)(buf + count - 1) & PAGE_MASK))
goto out_copy;
and in case it does not help put the same goto at the very beginning of
omap2_onenand_read_bufferram function and report result?

Thank you for cooperation,
ladis

> commit bdaca9345d41fd9420995469d27603ea62054691
> Author: Ladislav Michl 
> Date:   Fri Jan 12 14:16:57 2018 +0100
> 
>mtd: onenand: omap2: Decouple DMA enabling from INT pin availability
> 
>INT pin (gpio_irq) is not really needed for DMA but only for notification
>when a command that needs wait has completed. DMA memcpy can be still used
>even without gpio_irq available, so enable it unconditionally.
> 
>Signed-off-by: Ladislav Michl 
>Reviewed-by: Peter Ujfalusi 
>Tested-by: Tony Lindgren 
>Tested-by: Aaro Koskinen 
>Acked-by: Roger Quadros 
>Signed-off-by: Boris Brezillon 
> 
> Kernel panic log is attached which indeed indicates a DMA problem.
> 
> Note that we have added compatible = "ti,omap2-onenand";
> 
> Any suggestions, fixes?
> 
> BR and thanks,
> Nikolaus Schaller
> 
> 
> 
> ## Booting kernel from Legacy Image at 8200 ...
>Image Name:   Linux-4.16.0-letux+
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4456744 Bytes = 4.3 MiB
>Load Address: 80008000
>Entry Point:  80008000
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 81c0
>Booting using the fdt blob at 0x81c0
>Loading Kernel Image ... OK
>Using Device Tree in place at 81c0, end 81c14a1e
> 
> Starting kernel ...
> 
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.16.0-letux+ (hns@iMac.local) (gcc version 
> 4.9.2 (GCC)) #2187 SMP PREEMPT Tue Apr 10 16:23:45 CEST 2018
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: Goldelico GTA04A5/Letux 2804
> [0.00] debug: ignoring loglevel setting.
> [0.00] Memory policy: Data cache writeback
> [0.00] cma: Reserved 16 MiB at 0xbe80
> [0.00] On node 0 totalpages: 261632
> [0.00]   Normal zone: 1536 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 196608 pages, LIFO batch:31
> [0.00]   HighMem zone: 65024 pages, LIFO batch:15
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
> [0.00] random: fast init done
> [0.00] percpu: Embedded 17 pages/cpu @(ptrval) s39744 r8192 d21696 
> u69632
> [0.00] pcpu-alloc: s39744 r8192 d21696 u69632 alloc=17*4096
> [0.00] pcpu-alloc: [0] 0 
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
> [0.00] Kernel command line: console=ttyO2,115200n8 
> mtdoops.mtddev=omap2.nand ubi.mtd=4 root=/dev/mmcblk0p1 rw 
> rootfstype=ext4,ext3 rootwait console=ttyO2,115200n8 vram=12M 
> omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait 
> twl4030_charger.allow_usb=1 log_buf_len=8M ignore_loglevel earlyprintk
> [0.00] log_buf_len: 8388608 bytes
> [0.00] early log buf free: 63924(97%)
> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
> bytes)
> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Memory: 1002524K/1046528K available (6169K kernel code, 626K 
> rwdata, 1660K rodata, 1024K init, 218K bss, 27620K reserved, 16384K 
> cma-reserved, 243712K highmem)
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> [0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
> [0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
> [0.00]  

Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

2018-04-10 Thread Ladislav Michl
Hi Nikolaus,

On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> Hi,
> we just started testing the v4.16 kernel and found the
> device no longer bootable (works with v4.15). It turned
> out that there was a harmful modification somewhere between
> v4.15.0 and v4.16-rc1.
> 
> A git bisect points to this patch:

Well, that's a shame... However, this code is in production for several
months now, so could you, please put 'goto out_copy' if 'buf >= high_memory'
condition is met, ie:
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
if (buf >= high_memory) {
struct page *p1;
 
+   goto out_copy;
if (((size_t)buf & PAGE_MASK) !=
((size_t)(buf + count - 1) & PAGE_MASK))
goto out_copy;
and in case it does not help put the same goto at the very beginning of
omap2_onenand_read_bufferram function and report result?

Thank you for cooperation,
ladis

> commit bdaca9345d41fd9420995469d27603ea62054691
> Author: Ladislav Michl 
> Date:   Fri Jan 12 14:16:57 2018 +0100
> 
>mtd: onenand: omap2: Decouple DMA enabling from INT pin availability
> 
>INT pin (gpio_irq) is not really needed for DMA but only for notification
>when a command that needs wait has completed. DMA memcpy can be still used
>even without gpio_irq available, so enable it unconditionally.
> 
>Signed-off-by: Ladislav Michl 
>Reviewed-by: Peter Ujfalusi 
>Tested-by: Tony Lindgren 
>Tested-by: Aaro Koskinen 
>Acked-by: Roger Quadros 
>Signed-off-by: Boris Brezillon 
> 
> Kernel panic log is attached which indeed indicates a DMA problem.
> 
> Note that we have added compatible = "ti,omap2-onenand";
> 
> Any suggestions, fixes?
> 
> BR and thanks,
> Nikolaus Schaller
> 
> 
> 
> ## Booting kernel from Legacy Image at 8200 ...
>Image Name:   Linux-4.16.0-letux+
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4456744 Bytes = 4.3 MiB
>Load Address: 80008000
>Entry Point:  80008000
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 81c0
>Booting using the fdt blob at 0x81c0
>Loading Kernel Image ... OK
>Using Device Tree in place at 81c0, end 81c14a1e
> 
> Starting kernel ...
> 
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.16.0-letux+ (hns@iMac.local) (gcc version 
> 4.9.2 (GCC)) #2187 SMP PREEMPT Tue Apr 10 16:23:45 CEST 2018
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: Goldelico GTA04A5/Letux 2804
> [0.00] debug: ignoring loglevel setting.
> [0.00] Memory policy: Data cache writeback
> [0.00] cma: Reserved 16 MiB at 0xbe80
> [0.00] On node 0 totalpages: 261632
> [0.00]   Normal zone: 1536 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 196608 pages, LIFO batch:31
> [0.00]   HighMem zone: 65024 pages, LIFO batch:15
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
> [0.00] random: fast init done
> [0.00] percpu: Embedded 17 pages/cpu @(ptrval) s39744 r8192 d21696 
> u69632
> [0.00] pcpu-alloc: s39744 r8192 d21696 u69632 alloc=17*4096
> [0.00] pcpu-alloc: [0] 0 
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
> [0.00] Kernel command line: console=ttyO2,115200n8 
> mtdoops.mtddev=omap2.nand ubi.mtd=4 root=/dev/mmcblk0p1 rw 
> rootfstype=ext4,ext3 rootwait console=ttyO2,115200n8 vram=12M 
> omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait 
> twl4030_charger.allow_usb=1 log_buf_len=8M ignore_loglevel earlyprintk
> [0.00] log_buf_len: 8388608 bytes
> [0.00] early log buf free: 63924(97%)
> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
> bytes)
> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Memory: 1002524K/1046528K available (6169K kernel code, 626K 
> rwdata, 1660K rodata, 1024K init, 218K bss, 27620K reserved, 16384K 
> cma-reserved, 243712K highmem)
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> [0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
> [0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
> [0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
> [0.00]   .text : 0x(ptrval)