Lost serial console after kernel starts init

I need the collective wisdom of people who work with embedded devices.

Background:
I'm working on an alternate firmware for the Meraki MS220 switch. It's a MIPS-based device that originally ships with Redboot, a NOR-based kernel + embedded initrd that kexec's to a NAND-based kernel + embedded initrd. Very inelegant, and the tools to work with TSOP48 NAND chips are expensive and cumbersome compared to NOR.

I've made some decent progress in modifying the firmware. The CRC and size checks have been patched out of Redboot (binary patching, Cisco has provided the bootloader source code but no instructions on how to turn the compiled binary into something flashable), allowing me to boot the NAND kernel directly from Redboot. This is important because there are out of tree binary modules shipped with their firmware that are needed to manage the switching ASIC, and they're only provided for the kernel version that runs from NAND.

But I'm not here to talk about Redboot or Cisco's firmware shenanigans because I don't care about those.

Someone added support for the SoC to u-boot in 2018. u-boot 2019.10 compiles and runs on the switch (with networking, even). I figured out that I needed to add support in the kernel for reading the argc and argv from u-boot.

This is all done and working:

## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux 3.18.123
   Image Type:   MIPS Linux Kernel Image (uncompressed)
   Data Size:    2165421 Bytes = 2.1 MiB
   Load Address: 81000000
   Entry Point:  81000000
   Verifying Checksum ... OK
   Loading Kernel Image
[    0.000000] Linux version 3.18.123-meraki-elemental (hmartin@alp) (gcc version 5.4.0 (GCC) ) #42 Fri May 1 16:09:10 UTC 2020
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 02019654 (MIPS 24KEc)
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 00477000 @ 00100000 (usable)
[    0.000000]  memory: 00049000 @ 00577000 (usable after init)
[    0.000000] User-defined physical RAM map:
[    0.000000]  memory: 07ff0000 @ 00000000 (usable)
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x00000000-0x07feffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00000000-0x07feffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x07feffff]
[    0.000000] Reserving 0MB of memory at 0MB for crashkernel
[    0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes.
[    0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32496
[    0.000000] Kernel command line: console=ttyS0,115200 mtdparts=m25p80:0x80000(uboot),0x40000(uboot-env),0x40000(uboot-conf),0x300000(kernel),
0x800000(squashfs),0x400000(jffs2) root=/dev/mtdblock5 rootfstype=squashfs mem=134152192 
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Writing ErrCtl register=80000811
[    0.000000] Readback ErrCtl register=80000811
[    0.000000] Cache parity protection enabled
[    0.000000] Memory: 123832K/131008K available (3633K kernel code, 187K rwdata, 740K rodata, 292K init, 119K bss, 7176K reserved, 0K cma-reser
ved)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:66
[    0.000000] sched_clock: 32 bits at 1kHz, resolution 1000000ns, wraps every 2147483648000000ns
[    0.002000] Calibrating delay loop... 275.45 BogoMIPS (lpj=137728)
[    0.013000] pid_max: default: 32768 minimum: 301
[    0.014000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.015000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.018000] ftrace: allocating 11996 entries in 24 pages
[    0.046000] Performance counters: mips/24K PMU enabled, 2 32-bit counters available to each CPU, irq -1 (share with timer interrupt)
[    0.053000] devtmpfs: initialized
[    0.059000] NET: Registered protocol family 16
[    0.094000] Switched to clocksource MIPS
[    0.133000] NET: Registered protocol family 2
[    0.140000] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[    0.147000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    0.153000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.160000] TCP: reno registered
[    0.163000] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.169000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.175000] NET: Registered protocol family 1
[    0.183000] VCORE-III Watchdog Timer enabled (30 seconds).  Prev boot was not caused by WDT reset.
[    0.194000] futex hash table entries: 256 (order: -1, 3072 bytes)
[    0.253000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.259000] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[    0.266000] msgmni has been set to 241
[    0.295000] io scheduler noop registered
[    0.299000] io scheduler deadline registered (default)
[    0.313000] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
[    0.328000] console [ttyS0] disabled
[    0.331000] serial8250.0: ttyS0 at MMIO 0x70100000 (irq = 14, base_baud = 13020833) is a 16550A
[    0.340000] console [ttyS0] enabled
[    0.340000] console [ttyS0] enabled
[    0.347000] bootconsole [early0] disabled
[    0.347000] bootconsole [early0] disabled
[    0.364000] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xf1
[    0.371000] nand: Micron MT29F1G08ABADAWP
[    0.375000] nand: 128MiB, SLC, page size: 2048, OOB size: 64
[    0.386000] Scanning device for bad blocks
[    0.510000] m25p80 spi0.1: found mx25l12805d, expected m25p80
[    0.516000] m25p80 spi0.1: mx25l12805d (16384 Kbytes)
[    0.521000] 6 cmdlinepart partitions found on MTD device m25p80
[    0.527000] Creating 6 MTD partitions on "m25p80":
[    0.532000] 0x000000000000-0x000000080000 : "uboot"
[    0.542000] 0x000000080000-0x0000000c0000 : "uboot-env"
[    0.551000] 0x0000000c0000-0x000000100000 : "uboot-conf"
[    0.562000] 0x000000100000-0x000000400000 : "kernel"
[    0.571000] 0x000000400000-0x000000c00000 : "squashfs"
[    0.583000] 0x000000c00000-0x000001000000 : "jffs2"
[    0.591000] tun: Universal TUN/TAP device driver, 1.6
[    0.597000] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    0.608000] i2c /dev entries driver
[    0.614000] TCP: cubic registered
[    0.617000] Initializing XFRM netlink socket
[    0.624000] NET: Registered protocol family 10
[    0.632000] NET: Registered protocol family 17
[    0.632000] NET: Registered protocol family 17
[    0.637000] NET: Registered protocol family 15
[    0.641000] 8021q: 802.1Q VLAN Support v1.8
[    0.646000] Meraki MS220-8 board detected
[    0.655000] i2c-gpio i2c-gpio.1: using pins 6 (SDA) and 5 (SCL)
[    0.669000] devtmpfs: mounted
[    0.706000] VFS: Mounted root (squashfs filesystem) readonly on device 31:5.
[    0.756000] devtmpfs: mounted
[    0.764000] Freeing unused kernel memory: 292K
[    4.191000] devpts: called with bogus options
[    5.654000] random: dropbear urandom read with 85 bits of entropy available
[  125.920000] random: nonblocking pool is initialized

Why I need your collective wisdom

Serial output is broken when the kernel hands off to init/userspace. Looking from the kernel messages above, I know userspace is alive because I can see dropbear reading urandom and 125 seconds later, the kernel has finished initializing the nonblocking random pool. If userspace was dead, I'd have a kernel panic and the device would reset in 5 seconds.

My rootfs is minimal and built using buildroot. I know it works, because I compiled the kernel with TTY_PRINTK support, and created a start-up script in /etc/init.d/ to print out to /dev/ttyprintk to show that userspace is alive:

[    4.779000]  S05printk starting; userspace is alive
[    5.689000] random: dropbear urandom read with 85 bits of entropy available
[    7.356000]  Hello from S51printk; userspace is alive but serial is broken

Buildroot by default uses busybox for init. Okay, so I thought maybe busybox has some bug and isn't outputting to /dev/ttyS0. So I configured buildroot to use OpenRC instead of busybox for init. Nope, still lose my serial output once the kernel invokes init.

The kernel command line is correct, serial output works for all of printk. I haven't gone gang-busters in modifying the command line since moving from Redboot to u-boot anyway, just some mtdpart changes that were necessary for u-boot/env.

If I boot using Redboot instead of u-boot (same kernel, just lacking the argc/argv patch), serial output from userspace is working:

[    1.664000] VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
[    1.695000] devtmpfs: mounted
[    1.703000] Freeing unused kernel memory: 292K
init started: BusyBox v1.25.1 (2018-08-24 12:51:28 PDT)


BusyBox v1.25.1 (2018-08-24 12:51:28 PDT) built-in shell (ash)

But this. doesn't. make. sense. The bootloader shouldn't have anything to do with the handover between the kernel and init/userspace. Kernel printk works in both cases, but only in the case of u-boot, is serial output broken once the kernel invokes init. The load address of the kernel differs between Redboot (0x80100000) and u-boot (0x81000000), but if I was somehow messing up the memory map, I'd expect to see zero output from printk and (more likely) a kernel panic during boot.

I did configure getty and it is supposed to be listening on ttyS0, but since there's not even any serial output from init, getty isn't accessible:

# Put a getty on the serial port
ttyS0::respawn:/sbin/getty -L  ttyS0 115200 vt100 # GENERIC_SERIAL

I cannot figure out why I'm losing the serial console when the kernel invokes init. What am I missing here?

Here is the kernel .config



Edited 1 time(s). Last edit at 05/02/2020 03:15PM by hmartin.

hmartin,

Good to see you posting again. Welcome back!

I recall that we have seen similar problem with the HP T5325. Let see if Gravelrash does too.

I'll look at my notes to see what I can find.

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

Quote

# Put a getty on the serial port
ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL

ttyS0 might be wrong, should be S0.

And the /etc/inittab content below.

My current HP T5325 Debian rootfs:

T0:2345:respawn:/sbin/getty -L ttyS0 115200 linux

My stock HP T5325 rootfs (from my notes):

T0:2345:respawn:/sbin/getty -L ttyS0 115200 linux
s0:2345:respawn:/sbin/agetty -L -f /etc/issueserial 9600 ttyS0 vt100

Also the issue might be with the speed 115200 vs 9600.

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

Also,

If this kernel was compiled with earlyprintk, then add earlyprintk=serial to bootargs. It migh show a little more in the bootlog.

CONFIG_EARLY_PRINTK=y

[    0.000000] Kernel command line: console=ttyS0,115200 mtdparts=m25p80:0x80000(uboot),0x40000(uboot-env),0x40000(uboot-conf),0x300000(kernel),
0x800000(squashfs),0x400000(jffs2) root=/dev/mtdblock5 rootfstype=squashfs mem=134152192 earlyprintk=serial

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

What I describe below is most likely irrrelevant to this tty console problem. But just food for thoughts.

Quote

But this. doesn't. make. sense. The bootloader shouldn't have anything to do with the handover between the kernel and init/userspace.

That is only true for the handover (u-boot is long gone at this point).

However, depending on the SoC, u-boot have several parameters that used by the kernel that are not visible to us in bootargs. When we look ATAG param that passed to the kernel, there are registers values/locations that are implicitly agreed upon, i.e. bootloader-kernel protocol. Things such as internal registers memory map address that also might not be in ATAG either. And that would affect UART address too.

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

Quote

ttyS0 might be wrong, should be S0.

I tried modifying the line to just S0, no difference:

S0::respawn:/sbin/getty -L  ttyS0 115200 vt100

I looked into this, and as best as I can tell, the arguments to getty are what matters and the first portion of the line exists only for legacy purposes:
https://serverfault.com/questions/925480/t0-vs-s0-in-inittab-for-serial-ttys0-access

Other people using buildroot seem to have ttyS0 at the start of their inittab getty lines, and it seems to work: http://buildroot-busybox.2317881.n4.nabble.com/buildroot-inittab-getty-td115526.html

Quote

If this kernel was compiled with earlyprintk, then add earlyprintk=serial to bootargs. It migh show a little more in the bootlog.

The kernel is compiled with CONFIG_EARLY_PRINTK=y, but if I add earlyprintk=serial I lose output even earlier :(

## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux 3.18.123
   Image Type:   MIPS Linux Kernel Image (uncompressed)
   Data Size:    2166588 Bytes = 2.1 MiB
   Load Address: 81000000
   Entry Point:  81000000
   Verifying Checksum ... OK
   Loading Kernel Image
[    0.000000] Linux version 3.18.123-meraki-elemental (hmartin@alp) (gcc version 5.4.0 (GCC) ) #43 Sun May 3 08:31:46 UTC 
2020
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 02019654 (MIPS 24KEc)
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 00477000 @ 00100000 (usable)
[    0.000000]  memory: 00049000 @ 00577000 (usable after init)
[    0.000000] Wasting 8192 bytes for tracking 256 unused pages

I went and reflashed the original Redboot + kernel that boots with userspace output, and compared /dev/ttyS0 and /proc/iomem between the two. Unsurprisingly, as it's the same kernel, there's no difference between /dev/ttyS0 device nodes or the iomem map. I tried compiling the kernel with more than 1 ttyS device, but that didn't change anything (as there's only one hardware uart, I didn't really expect it to).

[    7.474000]  S99 starting; we print stuff
[    7.481000]  Now we print /dev
[    7.501000]  total 0
[    7.505000]  crw-------    1 root     root        5,   1 Jan  1 00:00 console
[    7.514000]  crw-------    1 root     root       10,  63 Jan  1 00:00 cpu_dma_latency
[    7.524000]  lrwxrwxrwx    1 root     root            13 Jan  1 00:00 fd -> /proc/self/fd
[    7.535000]  crw-rw-rw-    1 root     root        1,   7 Jan  1 00:00 full
[    7.544000]  crw-------    1 root     root       89,   1 Jan  1 00:00 i2c-1
[    7.553000]  crw-------    1 root     root        1,   2 Jan  1 00:00 kmem
[    7.562000]  crw-r--r--    1 root     root        1,  11 Jan  1 00:00 kmsg
[    7.571000]  srw-rw-rw-    1 root     root             0 Jan  1 00:00 log
[    7.580000]  crw-------    1 root     root        1,   1 Jan  1 00:00 mem
[    7.589000]  crw-------    1 root     root       10,  60 Jan  1 00:00 memory_bandwidth
[    7.599000]  crw-------    1 root     root       90,   0 Jan  1 00:00 mtd0
[    7.608000]  crw-------    1 root     root       90,   1 Jan  1 00:00 mtd0ro
[    7.617000]  crw-------    1 root     root       90,   2 Jan  1 00:00 mtd1
[    7.626000]  crw-------    1 root     root       90,   3 Jan  1 00:00 mtd1ro
[    7.635000]  crw-------    1 root     root       90,   4 Jan  1 00:00 mtd2
[    7.644000]  crw-------    1 root     root       90,   5 Jan  1 00:00 mtd2ro
[    7.653000]  crw-------    1 root     root       90,   6 Jan  1 00:00 mtd3
[    7.662000]  crw-------    1 root     root       90,   7 Jan  1 00:00 mtd3ro
[    7.671000]  crw-------    1 root     root       90,   8 Jan  1 00:00 mtd4
[    7.680000]  crw-------    1 root     root       90,   9 Jan  1 00:00 mtd4ro
[    7.689000]  crw-------    1 root     root       90,  10 Jan  1 00:00 mtd5
[    7.698000]  crw-------    1 root     root       90,  11 Jan  1 00:00 mtd5ro
[    7.707000]  crw-------    1 root     root       90,  12 Jan  1 00:00 mtd6
[    7.716000]  crw-------    1 root     root       90,  13 Jan  1 00:00 mtd6ro
[    7.725000]  brw-------    1 root     root       31,   0 Jan  1 00:00 mtdblock0
[    7.734000]  brw-------    1 root     root       31,   1 Jan  1 00:00 mtdblock1
[    7.744000]  brw-------    1 root     root       31,   2 Jan  1 00:00 mtdblock2
[    7.753000]  brw-------    1 root     root       31,   3 Jan  1 00:00 mtdblock3
[    7.763000]  brw-------    1 root     root       31,   4 Jan  1 00:00 mtdblock4
[    7.771000]  brw-------    1 root     root       31,   5 Jan  1 00:00 mtdblock5
[    7.781000]  brw-------    1 root     root       31,   6 Jan  1 00:00 mtdblock6
[    7.791000]  drwxr-xr-x    2 root     root            60 Jan  1 00:00 net
[    7.799000]  crw-------    1 root     root       10,  62 Jan  1 00:00 network_latency
[    7.810000]  crw-------    1 root     root       10,  61 Jan  1 00:00 network_throughput
[    7.819000]  crw-rw-rw-    1 root     root        1,   3 Jan  1 00:00 null
[    7.829000]  crw-rw-rw-    1 root     root        5,   2 Jan  1 00:00 ptmx
[    7.837000]  drwxr-xr-x    2 root     root             0 Jan  1 00:00 pts
[    7.846000]  crw-rw-rw-    1 root     root        1,   8 Jan  1 00:00 random
[    7.855000]  brw-------    1 root     root       31,   5 Jan  1 00:00 root
[    7.864000]  drwxrwxrwx    2 root     root            40 Jan  1 00:00 shm
[    7.873000]  lrwxrwxrwx    1 root     root            15 Jan  1 00:00 stderr -> /proc/self/fd/2
[    7.886000]  lrwxrwxrwx    1 root     root            15 Jan  1 00:00 stdin -> /proc/self/fd/0
[    7.898000]  lrwxrwxrwx    1 root     root            15 Jan  1 00:00 stdout -> /proc/self/fd/1
[    7.909000]  crw-rw-rw-    1 root     root        5,   0 Jan  1 00:00 tty
[    7.918000]  crw-------    1 root     root        4,  64 Jan  1 00:00 ttyS0
[    7.927000]  crw-------    1 root     root        4,  65 Jan  1 00:00 ttyS1
[    7.936000]  crw-------    1 root     root        4,  66 Jan  1 00:00 ttyS2
[    7.945000]  crw-------    1 root     root        5,   3 Jan  1 00:00 ttyprintk
[    7.954000]  crw-------    1 root     root       10,  59 Jan  1 00:00 ubi_ctrl
[    7.964000]  crw-rw-rw-    1 root     root        1,   9 Jan  1 00:00 urandom
[    7.972000]  crw-------    1 root     root       10, 130 Jan  1 00:00 watchdog
[    7.982000]  crw-rw-rw-    1 root     root        1,   5 Jan  1 00:00 zero

[    7.994000]  Now we print /proc/iomem
[    8.009000]  00000000-07feffff : System RAM
[    8.013000]    00000000-00000000 : Crash kernel
[    8.018000]    00100000-0048ce43 : Kernel code
[    8.023000]    0048ce44-0057614f : Kernel data
[    8.028000]  40000000-4fffffff : Serial interface
[    8.033000]  50000000-5fffffff : Parallel interface
[    8.038000]    50000000-50000010 : gen_nand.0
[    8.043000]      50000000-50000010 : gen_nand.0
[    8.048000]  60000000-60ffffff : Switch registers
[    8.053000]  70000000-701fffff : CPU Registers
[    8.057000]    70100000-7010001f : serial

Quote

However, depending on the SoC, u-boot have several parameters that used by the kernel that are not visible to us in bootargs. When we look ATAG param that passed to the kernel, there are registers values/locations that are implicitly agreed upon, i.e. bootloader-kernel protocol. Things such as internal registers memory map address that also might not be in ATAG either. And that would affect UART address too.

I actually had a similar question a little while ago when I was staring at the entry point of the kernel, trying to figure out why Redboot would boot vmlinux but not vmlinuz. I never figured out why and just moved on to u-boot.

I guess (ulong)linux_env is the next place I'll look, since I'm pretty stuck on the userspace side.

hmartin,

Quote

Redboot would boot vmlinux but not vmlinuz

Could be the compression/uncompression is not compatible between this Redboot and that kernel.

Quote

The kernel is compiled with CONFIG_EARLY_PRINTK=y, but if I add earlyprintk=serial I lose output even earlier :(
## Booting kernel from Legacy Image at 81000000 ...
Image Name: Linux 3.18.123
Image Type: MIPS Linux Kernel Image (uncompressed)
Data Size: 2166588 Bytes = 2.1 MiB
Load Address: 81000000
Entry Point: 81000000
Verifying Checksum ... OK
Loading Kernel Image
[ 0.000000] Linux version 3.18.123-meraki-elemental (hmartin@alp) (gcc version 5.4.0 (GCC) ) #43 Sun May 3 08:31:46 UTC
2020
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 02019654 (MIPS 24KEc)
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 00477000 @ 00100000 (usable)
[ 0.000000] memory: 00049000 @ 00577000 (usable after init)
[ 0.000000] Wasting 8192 bytes for tracking 256 unused pages

This has a good hint. I think possibly there is memory conflict between this u-boot and the kernel. The u-boot and kernel handover occur after it loads and start the kernel. The params data remained as the input to the kernel. It tells the kernel where things are to go and read.

Does this u-boot has a "mem" command? some older stock u-boot can dump memory map with this command.

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



Edited 1 time(s). Last edit at 05/03/2020 04:37PM by bodhi.

Furthermore in the kernell config.

Try setting this number to 4.

CONFIG_SERIAL_8250_NR_UARTS=1
CONFIG_SERIAL_8250_RUNTIME_UARTS=1

And I don't think you need the tty_printk

CONFIG_TTY_PRINTK=y

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

Quote

Does this u-boot has a "mem" command?

Yes, but it's not useful:

luton # mem
DRAM:  128 MiB
luton # meminfo 
DRAM:  128 MiB

Quote

The u-boot and kernel handover occur after it loads and start the kernel. The params data remained as the input to the kernel. It tells the kernel where things are to go and read.

I could be mistaken, but I don't think Vitesse implemented the necessary code to read the environment from the bootloader. I don't find any reference to fw_arg2 in the prom code for this mach. I'll steal this print statement from ralink and see what u-boot is passing in fw_arg2. Redboot doesn't put anything in fw_arg2, and I had to add support to read argc and argv from fw_arg0 and fw_arg1.

The uart code in this kernel appears to include part of the TLB initialization code, and from the comments the Vitesse engineers really abused the TLB to preserve their early boot console:

	/*
	 * Very very very ugly. We should be the only thing that installed
	 * a wired mapping, so it is safe for us to remove it. However,
	 * if there are other wired mappings, we should just warn about
	 * it and do nothing. There are only 16 TLBs on the VCore-III
	 * so using a wired TLB is a bad idea.
	 */

I tried booting with keep_bootcon but that ended in (I think) a kernel oops:

[    0.856000] devtmpfs: mounted
[    0.856000] devtmpfs: mounted
[    0.867000] Freeing unused kernel memory: 292K
[    0.873000] Reserved instruction in kernel code[#1]:

I think I'm going to take a different approach to debugging this, because I don't feel like I will be successful with the current approach. I'm going to revert back to Redboot and fix my userspace enough that I can load the modules to manage the switch ASIC and get telnet or SSH running, and then with remote access it should hopefully be easier to debug why the uart dies.

> Does this u-boot has a "mem" command?
>
> Yes, but it's not useful:
>

> luton # mem
> DRAM:  128 MiB
> luton # meminfo 
> DRAM:  128 MiB
>

Sorry, I meant "map" command.

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

bodhi Wrote:
> Sorry, I meant "map" command.

No support for the map command, I'm sorry to say.

I reverted back to RedBoot and I'm almost to the point of having network connectivity in userspace, but there's something in the Click Router configuration that's blocking traffic to userspace. (Click: pesky over-complicated and severely under-documented research paper project to replace a perfectly functional existing networking stack in the kernel)

hmartin,

Have you tried this:

Quote

Try setting this number to 4.
CONFIG_SERIAL_8250_NR_UARTS=1
CONFIG_SERIAL_8250_RUNTIME_UARTS=1

And I don't think you need the tty_printk
CONFIG_TTY_PRINTK=y

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

IMO, this problem is because either:

1. The IRQ assigned to serial was taken away erroneously at the time when it went away.

Or

2. There is memory conflict from u-boot to kernel. But usually when that happens, there is an exception right after, or kernel hang. There is a memory location that u-boot tells the kernel what u-boot is using.

This is from the Mirabox stock u-boot:

Marvell>> map

CPU Interface
-------------
SDRAM_CS0 ....base 00000000, size 512MB 
SDRAM_CS1 ....base 20000000, size 512MB 
SDRAM_CS2 ....disable
SDRAM_CS3 ....disable
DEVICE_CS0 ....no such
DEVICE_CS1 ....no such
DEVICE_CS2 ....no such
DEVICE_CS3 ....no such
PEX0_MEM ....base b0000000, size  32MB 
PEX0_IO ....no such
PEX1_MEM ....base b2000000, size  32MB 
PEX1_IO ....no such
INTER_REGS ....base d0000000, size   1MB 
DMA_UART ....no such
SPI_CS0 ....base f4000000, size  16MB 
SPI_CS1 ....no such
SPI_CS2 ....no such
SPI_CS3 ....no such
SPI_CS4 ....no such
SPI_CS5 ....no such
SPI_CS6 ....no such
SPI_CS7 ....no such
BOOT_ROM_CS ....base f8000000, size   1MB 
DEV_BOOTCS ....base fd000000, size  16MB 
PMU_SCRATCHPAD ....no such
CRYPT0_ENG ....base c8010000, size  64KB 

AHB To MBUS Bridge:
-------------------
win0 - PEX0_MEM base b0000000, ....size  32MB 
win1 - PEX1_MEM base b2000000, ....size  32MB 
win2 - disable
win3 - disable
win4 - disable
win5 - disable
win6 - disable
win7 - disable
win8 - SPI_CS0 base f4000000, ....size  16MB 
win9 - DEV_BOOTCS base fd000000, ....size  16MB 
win10 - CRYPT0_ENG base c8010000, ....size  64KB 
win11 - disable
win12 - disable
win13 - BOOT_ROM_CS base f8000000, ....size   1MB 
win14 - disable
win15 - disable
win16 - disable
win17 - disable
win18 - disable
win19 - disable
win20 - INTER_REGS base d0000000, ....size   1MB 

PEX0:
-----

Pex Bars 

Internal Regs Bar0.... base d0000000, size   1MB 
DRAM Bar1............. base 00000000, size   1GB 
Devices Bar2.......... disable

Pex Decode Windows

win0 - SDRAM_CS0 base 00000000, ....size 512MB 
win1 - SDRAM_CS1 base 20000000, ....size 512MB 
win2 - disable
win3 - disable
win4 - disable
win5 - disable
default win - SDRAM_CS0 
Expansion ROM - SDRAM_CS0 

PEX1:
-----

Pex Bars 

Internal Regs Bar0.... base d0000000, size   1MB 
DRAM Bar1............. base 00000000, size   1GB 
Devices Bar2.......... disable

Pex Decode Windows

win0 - SDRAM_CS0 base 00000000, ....size 512MB 
win1 - SDRAM_CS1 base 20000000, ....size 512MB 
win2 - disable
win3 - disable
win4 - disable
win5 - disable
default win - SDRAM_CS0 
Expansion ROM - SDRAM_CS0 

USB 0:
----
win0 - SDRAM_CS0 base 00000000, ....size 512MB 
win1 - SDRAM_CS1 base 20000000, ....size 512MB 
win2 - PEX0_MEM base b0000000, ....size  32MB 
win3 - disable

USB 1:
----
win0 - SDRAM_CS0 base 00000000, ....size 512MB 
win1 - SDRAM_CS1 base 20000000, ....size 512MB 
win2 - PEX0_MEM base b0000000, ....size  32MB 
win3 - disable

ETH 0:
----
win0 - SDRAM_CS0 base 00000000, ....size 512MB 
win1 - SDRAM_CS1 base 20000000, ....size 512MB 
win2 - disable
win3 - disable
win4 - disable
win5 - disable

ETH 1:
----
win0 - SDRAM_CS0 base 00000000, ....size 512MB 
win1 - SDRAM_CS1 base 20000000, ....size 512MB 
win2 - disable
win3 - disable
win4 - disable
win5 - disable

XOR 0:
----
win0 - SDRAM_CS0 base 00000000, ....size 512MB 
win1 - SDRAM_CS1 base 20000000, ....size 512MB 
win2 - PEX0_MEM base b0000000, ....size  32MB 
win3 - PEX1_MEM base b2000000, ....size  32MB 
win4 - disable
win5 - disable
win6 - disable
win7 - disable

XOR 1:
----
win0 - SDRAM_CS0 base 00000000, ....size 512MB 
win1 - SDRAM_CS1 base 20000000, ....size 512MB 
win2 - PEX0_MEM base b0000000, ....size  32MB 
win3 - PEX1_MEM base b2000000, ....size  32MB 
win4 - disable
win5 - disable
win6 - disable
win7 - disable

Sata 0:
----
win0 - SDRAM_CS0 base 00000000, ....size 256MB 
win1 - SDRAM_CS1 base 10000000, ....size 256MB 
win2 - SDRAM_CS2 base 20000000, ....size 256MB 
win3 - SDRAM_CS3 base 30000000, ....size 256MB 

Sata 1:
----
win0 - SDRAM_CS0 base 00000000, ....size 256MB 
win1 - SDRAM_CS1 base 10000000, ....size 256MB 
win2 - SDRAM_CS2 base 20000000, ....size 256MB 
win3 - SDRAM_CS3 base 30000000, ....size 256MB 
Marvell>>

This is important:

DEV_BOOTCS ....base fd000000, size  16MB

In an FDT kernel, you can see it in the DTS. But with an older, non-FDT kernel, you would have to dig in the code to find where this memory is define.

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

bodhi, do you know the u-boot config option for the map command?

Is this perhaps a vendor specific command, added to a fork of u-boot?

I've searched several times for map in menuconfig and come up empty on the command you're referencing. I'm building denx u-boot from the v2019.10 tag.

hmartin,

> bodhi, do you know the u-boot config option for
> the map command?
>
> Is this perhaps a vendor specific command, added
> to a fork of u-boot?

> I've searched several times for map in menuconfig
> and come up empty on the command you're
> referencing. I'm building denx u-boot from the
> v2019.10 tag.

It is a vendor specific command. Some old vendor u-boots have map command, some don't. map command is not a standard u-boot command, so we have to code it (or port from a vendor GPL u-boot).

U-Boot command is quite easy to add, as long as you have the GPL code that you can port, and it conforms to the current mainline u-boot (meaning you can match up the includes with what is currently in mainline).

U-Boot standard commands are all in the ./cmd folder.

/usr/src/u-boot-2017.07-tld/cmd

And example of the button command I've added to the Kirkwood boxes. In this case the Pogo V4.

/usr/src/u-boot-2017.07-tld# cat ./board/cloudengines/pogo_v4/pogo_v4.c | tail -40

		break;
	case BOOTSTAGE_ID_NET_ETH_START:	/* Ethernet initialization */
		set_leds(GREEN_LED, GREEN_LED);
		break;
	default:
		if (val < 0)	/* error */
			set_leds(RED_LED, RED_LED);
		break;
	}
}

#if defined(CONFIG_KIRKWOOD_GPIO)
/* Return GPIO button status */
/*
un-pressed:
 gpio-29 (Eject Button ) in hi (act lo) - IRQ edge (clear )
pressed
 gpio-29 (Eject Button ) in lo (act hi) - IRQ edge (clear )
*/

static int
do_read_button(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
	if (strcmp(argv[1], "eject") == 0) {
			kw_gpio_set_valid(BTN_EJECT, GPIO_INPUT_OK);
			kw_gpio_direction_input(BTN_EJECT);
			return kw_gpio_get_value(BTN_EJECT);
	}
	else
		return -1;
}


U_BOOT_CMD(button, 2, 0, do_read_button,
	   "Return GPIO button status 0=off 1=on",
	   "- button eject: test buttons states\n"
);

#endif

So you can see that the new command can be any where (it does not have to reside in ./cmd). The macro U_BOOT_CMD is how u-boot gather all defined commands to add them to its list.

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



Edited 1 time(s). Last edit at 06/10/2020 04:48AM by bodhi.