No more output is seen on the console after "Starting Kernel..."

[Mathieu Malaterre]

Hi there,

While giving 4.12.10 a try I discover that I've lost any output right
after u-boot: It prints "Starting Kerne" and then nothing. If I repeat
the exact same operations with 4.9.46 then everything is back to
normal.

From laptop:

$ make ARCH=mips ci20_defconfig
$ make ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- uImage
$ sudo cp arch/mips/boot/uImage.bin /tftpboot/uImage.dev
$ sudo screen /dev/ttyUSB0 115200

From ci20:

dhcp 0x88000000 192.168.0.14:uImage.dev;
bootm 0x88000000;


Does anyone know what changed related to tty/uart in 4.x > 4.9.46 ?

Thanks,
--
Mathieu

[Mathieu Malaterre]

So I finally convinced myself to start a git bisect in between v4.10.1 and v4.11.1. This resulted in:

% git bisect good

73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 is the first bad commit

commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411

Author: Marcin Nowakowski <marcin.n...@imgtec.com>

Date:   Wed Nov 23 14:43:49 2016 +0100

    MIPS: fix mem=X@Y commandline processing

    

    When a memory offset is specified through the commandline, add the

    memory in range PHYS_OFFSET:Y as reserved memory area.

    Otherwise the bootmem allocator is initialised with low page equal to

    min_low_pfn = PHYS_OFFSET, and in free_all_bootmem will process pages

    starting from min_low_pfn instead of PFN(Y).

    

    Signed-off-by: Marcin Nowakowski <marcin.n...@imgtec.com>

    Cc: linux...@linux-mips.org

    Patchwork: https://patchwork.linux-mips.org/patch/14613/

    Signed-off-by: Ralf Baechle <ra...@linux-mips.org>

:040000 040000 fe26fcf6d072cbaedac5a417f9f6424df16d331c b99681a22464164b88c6a3cf77b1b87957cd95d6 M arch

 

Could anyone please comment on this commit with regards to Creator CI20 ?

Thanks

[Mathieu Malaterre]

So the above commit provide a correct behavior for mem=X@Y, but breaks my current u-boot setup: 

mem=768M@0x30000000 rootwait quiet rw root=/dev/mmcblk0p1 

This was automatically setup for me (no sure where) when using the default nand setup (http://elinux.org/CI20_Dev_Zone#NAND_Flashing_SD_card).

What should this 'mem' env variable should state instead now ?

Thanks very much !

[James Hogan]

Cc'ing Marcin,

> --
> You received this message because you are subscribed to the Google Groups "MIPS Creator CI20 Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mips-creator-ci2...@googlegroups.com.
> To post to this group, send an email to mips-creat...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/mips-creator-ci20-dev/1a04fa5f-19ab-4be4-a195-5b974c1a02f5%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Mathieu Malaterre]

Hi Marcin,

So the important part of the message is that by-default u-boot env
variables are currently setup with:

ci20# printenv
baudrate=115200
board_date=20140704
board_mfr=NP
bootargs=console=ttyS4,115200 console=tty0 mem=256M@0x0

mem=768M@0x30000000 rootwait quiet rw root=/dev/mmcblk0p1

bootcmd=run ethargs; ext4load mmc 0:1 0x88000000 /boot/uImage; bootm 0x88000000
bootdelay=1
ethact=dm9000
ethaddr=d0:31:10:ff:7d:20
ethargs=env set bootargs ${bootargs} dm9000.mac_addr=${ethaddr}
loads_echo=1
serial#=1255
stderr=eserial0,eserial4
stdin=eserial0,eserial4
stdout=eserial0,eserial4

Environment size: 488/32764 bytes


So clearly:

bootargs=console=ttyS4,115200 console=tty0 mem=256M@0x0

mem=768M@0x30000000 rootwait quiet rw root=/dev/mmcblk0p1

seems to indicate a copy/paste error.

-M

[Marcin Nowakowski]

Hi Mathieu,

Thanks for your report

I'll investigate the issue - I haven't used a ci20 board before and the
board I have access to doesn't want to cooperate with me very well, so
it might take a while to reach any conclusion :)

Marcin

[Marcin Nowakowski]

Hi Mathieu,

On 01.09.2017 09:53, Mathieu Malaterre wrote:

So that patch from did cause issues here - it turns out this is a memory
layout that unfortunately I haven't tested the patch with.
I have slightly limited debugging options on the ci20 board I'm using,
but what I think is happening here is that due to this patch, all of the
memory range below 0x30000000 is marked as reserved, which is obviously
incorrect and results in eg. a failure to allocate a memory block for
DMA (and potentially some other resource allocations as well).
The intention of 73fbc1eba7ff was to protect memory below the start of
RAM, but it didn't properly account for holes in the memory. I believe
the following patch should restore the intended behaviour.

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index fe39397..a1c39ec 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -374,6 +374,7 @@ static void __init bootmem_init(void)
unsigned long reserved_end;
unsigned long mapstart = ~0UL;
unsigned long bootmap_size;
+ phys_addr_t ramstart = ~0UL;
bool bootmap_valid = false;
int i;

@@ -394,6 +395,21 @@ static void __init bootmem_init(void)
max_low_pfn = 0;

/*
+ * Reserve any memory between the start of RAM and PHYS_OFFSET
+ */
+ for (i = 0; i < boot_mem_map.nr_map; i++) {
+ if (boot_mem_map.map[i].type != BOOT_MEM_RAM)
+ continue;
+
+ ramstart = min(ramstart, boot_mem_map.map[i].addr);
+ }
+
+ if (ramstart > PHYS_OFFSET)
+ add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
+ BOOT_MEM_RESERVED);
+
+
+ /*
* Find the highest page frame number we have available.
*/
for (i = 0; i < boot_mem_map.nr_map; i++) {
@@ -663,9 +679,6 @@ static int __init early_parse_mem(char *p)

add_memory_region(start, size, BOOT_MEM_RAM);

- if (start && start > PHYS_OFFSET)
- add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
- BOOT_MEM_RESERVED);
return 0;
}
early_param("mem", early_parse_mem);


It also makes sure that the region is protected as expected when the
memory offset is set through device tree, unlike in the original case
which only catered for the bootparam case (although I'm not sure how
likely this is to affect any real system - probably quite unlikely).

Moreover, since the memory ranges are defined in the devicetree I don't
think it is necessary at all to pass mem=... on the ci20. I suspect that
it may have been required on some older kernels and just remains as a
default in the bootloader. So removing both mem=... arguments from the
commandline and not patching the kernel would also fix the problem
you're having.

I'll need to think a bit more about this patch and will send to the mips
mailing list for review/upstreaming.

Marcin

[Mathieu Malaterre]

Hi all,

I confirm that clearing both mem=256M@0x0 & mem=768M@0x30000000 from
my u-boot allow me to boot 4.11.1 now:

ci20@ci20:~$ uname -a
Linux ci20 4.11.1 #2 PREEMPT Wed Aug 30 13:54:53 CEST 2017 mips GNU/Linux

Let me try all the good stuff from 4.13 !

Thanks,
--
Mathieu

[z4v4l]

I have a question with regard to this memory map discussion. linux has memory splitted into two regions (base - size): 0x00000000 - 0x10000000 and 0x30000000 - 0x30000000, which is (kind of) 256MB at 0 and 768MB at 0x30000000. But the ci20 board has only 1 GB of RAM and that means that the highest two bits of address are "don't care" for the memory chips. For example an address with the highest byte 0x40 and with 0x00, should point to the same SDRAM byte. because only 30 lower bits are meaningful for 1GB of SDRAM. This results in the range (highest byte only) 0x40 - 0x80 (exclusively) is a natural alias to the 0x00 - 0x40 range. Isn't it? So with the above map linux has:
1) only addressing of 768MB of RAM
2) which is worse, - possibilty of memory corruption (writing to physical address 0x40000000 changes content at address 0x00000000)

Maybe linux is aware of this aliasing, and avoids conflicts, but how about the 256MB loss then? why doesn't it address the second range like this: base:0x30000000 - size: 0x40000000?

середа, 30 серпня 2017 р. 13:25:41 UTC+3 користувач Mathieu Malaterre написав:

[Maarten ter Huurne]

On Saturday, 2 September 2017 21:24:19 CEST z4v4l wrote:
> I have a question with regard to this memory map discussion. linux has
> memory splitted into two regions (base - size): 0x00000000 -
> 0x10000000 and 0x30000000 - 0x30000000, which is (kind of) 256MB at 0
> and 768MB at 0x30000000. But the ci20 board has only 1 GB of RAM and
> that means that the highest two bits of address are "don't care" for
> the memory chips. For example an address with the highest byte 0x40
> and with 0x00, should point to the same SDRAM byte. because only 30
> lower bits are meaningful for 1GB of SDRAM. This results in the range
> (highest byte only) 0x40 - 0x80 (exclusively) is a natural alias to
> the 0x00 - 0x40 range. Isn't it? So with the above map linux has:
> 1) only addressing of 768MB of RAM
> 2) which is worse, - possibilty of memory corruption (writing to
> physical address 0x40000000 changes content at address 0x00000000)

There is still an indirection between the physical address and the
address selected in the SDRAM. As a result, there is no aliasing in the
address range used by the Linux kernel.

You can find some details in section 16.3 of the JZ4780 Programming
Manual.

Bye,
Maarten

[z4v4l]

субота, 2 вересня 2017 р. 23:50:15 UTC+3 користувач Maarten ter Huurne написав:

Thank you for your reply. I actually have checked and it really looks like system bus addresses 00000000-0fffffff never reach DDRC, and always translate into 20000000 - 2fffffff instead. Because when I set DMMAP0 register's base:mask to 40:c0, and accessing memory through kseg1 VA segment, I checked two words at addresses a0000000 and afffffff, didn't result in a successful test. There was no hang, but the reads from those addresses weren't matched with what I tried to write there. but when I set base:mask to 20:20, everything succeeded. Note, in both cases, the highest physical address' byte 00 (it should be that according to MIPS) should not satisfy the equation addr & mask = base, in the first it was
00 & 40 = 00, in second it was 00 & 20 = 00. Base mismatch in both cases, but the second worked. Why? Because 00 actually was 20, so on jz4780, if you write at kseg1 a0000000, you actually get "free" mapping into 20000000, and not in 00000000. So, that arrow in the manual, from 00 to 20 in the system space means this? Am I right?
I actually did this cute mapping scheme, for an easier understanding. Is it right, how do yoiu think?

 

[pa...@boddie.org.uk]

On Friday, November 10, 2017 at 1:32:09 AM UTC+1, z4v4l wrote:

Because 00 actually was 20, so on jz4780, if you write at kseg1 a0000000, you actually get "free" mapping into 20000000, and not in 00000000. So, that arrow in the manual, from 00 to 20 in the system space means this? Am I right?

I actually did this cute mapping scheme, for an easier understanding. Is it right, how do yoiu think?

I'm not sure it makes it easier to me, but I suppose one mental model of the mapping is that everything RAM-related really ends up being mapped to a base of 20000000. The mapping from the "lower" virtual addresses in the 00000000-10000000 region is some kind of compatibility convenience for software written for the other Ingenic SoCs, perhaps, where peripherals were placed in the 10000000-20000000 region (where they presumably still reside).

Sorry if this restated what you were trying to say!

Paul