Welcome! Log In Create A New Profile

Advanced

Lost serial console after kernel starts init

Posted by hmartin 
Lost serial console after kernel starts init
May 02, 2020 03:04PM
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.
Re: Lost serial console after kernel starts init
May 02, 2020 04:51PM
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
Re: Lost serial console after kernel starts init
May 02, 2020 06:19PM
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
Re: Lost serial console after kernel starts init
May 02, 2020 06:25PM
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
Re: Lost serial console after kernel starts init
May 02, 2020 07:08PM
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
Re: Lost serial console after kernel starts init
May 03, 2020 09:38AM
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.
Re: Lost serial console after kernel starts init
May 03, 2020 04:34PM
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



Edited 1 time(s). Last edit at 05/03/2020 04:37PM by bodhi.
Re: Lost serial console after kernel starts init
May 03, 2020 04:54PM
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
Re: Lost serial console after kernel starts init
May 14, 2020 06:48AM
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.
Re: Lost serial console after kernel starts init
May 14, 2020 04:43PM
> 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
Author:

Your Email:


Subject:


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