Bohdi:
Got a question about kernel settings that control console log output to the serial port on a Dockstar during boot.
I started out to regenerate a couple of Dockstars that were gathering dust on the shelf, but decided to update the kernels from System.map-3.2.0-4-kirkwood to your current linux-4.17.2-kirkwood.
My first attempt to update uBoot was >ahem< less than successful, resulting in a box that wouldn't boot from the previous kernel. Fortunately, I had purchased a 3.3 volt serial cable and could watch the boot process.
This post helped me restore that Dockstar and the rest by using tftp to restore the uBoot in flash memory, and has become my standard way to update the boot loader:
https://forum.doozan.com/read.php?3,6965,6965#msg-6965
It was worth the time to set up a tftp server on a laptop running Ubuntu. I did notice that you have to read this line in the manual instructions carefully to get the length of the load correct, and then things were consistent:
....
Marvell>> nand write.e 0x800000 0x0 0x80000
nand write.e 0x800000 0x0 0x80000
^^^^^^^^
This sets the length of the load to 512 KB, same as the file size.
At the moment, I have one Dockstar up to your linux-4.17.2-kirkwood-tld-1-bodhi.tar.bz2 build; but I am holding the rest at the Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2 rootfs after updates.
I noticed that the rootfs build boots up with verbose console messages. This is helpful to me because I can see issues during the boot and the messages give me someplace to look.
Your 4.17.2 build turns these off. The messages are all captured in the ring buffer and available through the dmesg command, but if the system is unbootable, that creates more problems trying to correct the problem.
For the 4.17.2 build, the console is silent once the kernel starts booting. If the boot is successful, I can use the dmesg command. If the box does not boot, however, I am left with little to go on.
I have chased the printk settings, but these control the depth of logging captured by dmesg, not what is printed on the serial console output. So far, I haven't been able to find the magic switch to turn them back on.
In your experience, what kernel parameter can I set or pass to restore verbose console messages during bootup?
ADVThanksANCE,
Christopher
Got a question about kernel settings that control console log output to the serial port on a Dockstar during boot.
I started out to regenerate a couple of Dockstars that were gathering dust on the shelf, but decided to update the kernels from System.map-3.2.0-4-kirkwood to your current linux-4.17.2-kirkwood.
My first attempt to update uBoot was >ahem< less than successful, resulting in a box that wouldn't boot from the previous kernel. Fortunately, I had purchased a 3.3 volt serial cable and could watch the boot process.
This post helped me restore that Dockstar and the rest by using tftp to restore the uBoot in flash memory, and has become my standard way to update the boot loader:
https://forum.doozan.com/read.php?3,6965,6965#msg-6965
It was worth the time to set up a tftp server on a laptop running Ubuntu. I did notice that you have to read this line in the manual instructions carefully to get the length of the load correct, and then things were consistent:
....
Marvell>> nand write.e 0x800000 0x0 0x80000
nand write.e 0x800000 0x0 0x80000
^^^^^^^^
This sets the length of the load to 512 KB, same as the file size.
At the moment, I have one Dockstar up to your linux-4.17.2-kirkwood-tld-1-bodhi.tar.bz2 build; but I am holding the rest at the Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2 rootfs after updates.
I noticed that the rootfs build boots up with verbose console messages. This is helpful to me because I can see issues during the boot and the messages give me someplace to look.
Your 4.17.2 build turns these off. The messages are all captured in the ring buffer and available through the dmesg command, but if the system is unbootable, that creates more problems trying to correct the problem.
For the 4.17.2 build, the console is silent once the kernel starts booting. If the boot is successful, I can use the dmesg command. If the box does not boot, however, I am left with little to go on.
I have chased the printk settings, but these control the depth of logging captured by dmesg, not what is printed on the serial console output. So far, I haven't been able to find the magic switch to turn them back on.
In your experience, what kernel parameter can I set or pass to restore verbose console messages during bootup?
ADVThanksANCE,
Christopher