Re: Boot stops at loader after build/install cycle

On Apr 13, 2023, at 21:49, Mark Millard <marklmi@yahoo.com> wrote:

> On Mar 30, 2023, at 10:40, Warner Losh <imp@bsdimp.com> wrote:
> 
>> On Thu, Mar 30, 2023 at 9:27 AM bob prohaska <fbsd@www.zefox.net> wrote:
>> On Wed, Mar 29, 2023 at 06:09:00PM -0700, Steve Rikli wrote:
>>> On Thu, Mar 30, 2023 at 12:24:13AM +0000, Marcin Cieslak wrote:
>>>> 
>>>> The characters look too regular to me, just like a normal terminal
>>>> codes, not a line noise. I test the device now powered from the
>>>> same USB hub as the USB-serial converter. Rockchip needs 1500000 bps
>>>> console, pretty fest.
>>> 
>>> OK, then let's assume your serial cables & hoods etc. are OK for the
>>> moment. What does serial console config on the rpi look like?
>>> 
>>> When I specified the rpi4 serial console speed in the config to match my
>>> serial terminal server, rather than let it "float" (default 9600), my
>>> loader interruptions stopped, and no more stray characters on the serial
>>> console after boot either.
>>> 
>>>> Also, uboot autoboot prompt never gets interrupted.
>>>> 
>>>> I also noticed that "resizewin" complains about not getting
>>>> information about the terminal upon login on the serial console
>>>> while being in the vt(4) text mode.
>>>> 
>>>> Looks like the bootloader tries to send/receives some terminal control
>>>> sequences and this fails, interupting the autoboot.
>>> 
>>> It may be something along those lines. When I was getting loader stops
>>> during reboot on my rpi4, my guess was the default FreeBSD speed 9600
>>> vs. my serial terminal server setting of 115200 was causing stray
>>> characters on the line during boot, loader interpretted that as a
>>> keystroke, so it stopped.
>> 
>> Where are you setting the serial console to 9600 baud? AIUI the
>> Pi defaults to 115200, can it be set in config.txt?
> 
> [FYI: my context is 115200 based throughout.]
> 
>> The sequence ending in R is indeed "report cursor location" so it's the result
>> of resizewin not reading it and leaving that around maybe? Or something else
>> sending the Query Cursor Location and then not reading it.
>> 
>> https://www.cse.psu.edu/~kxc104/class/cmpen472/11f/hw/hw7/vt100ansi.htm
> 
> FYI: I just booted a 2023-Apr-13 snapshot and saw the behavior
> for the first time: "0;200R" at the boot prompt (the window
> being 60 lines by 200 columns). I had not seen this with the
> Apr-06 snapshot or before, although normally my snapshot
> updates have been very rare, not two weeks in a row.
> 
> I deleted the 0;200R text and typed boot to manually continue
> the boot. (Yes: the "6" was not present.)
> 
> A "shutdown -r now" sequence did not get the problem.
> 
> It leaves me wondering about varaibility in the u-boot
> to FreeBSD-loader transition's handling of things or
> other sources of variability in the handling in the
> loader.
> 
> I'll see if I can get a capture of the byte stream with
> an example of the extra text (apparently via power-on).

No repetition so far.

But I can report that the prior <ESC>[6n (Query Cursor Position)
before the FreeBSD loader's OK prompt is during U-Boot activity:
part of the escpe sequences just after:

Device 0: Vendor: OWC      Rev: 0    Prod: Envoy Pro mini  
            Type: Hard Disk
            Capacity: 228936.5 MB = 223.5 GB (468862128 x 512)
... is now current device
Scanning usb 0:1...

This suggests that U-Boot failed to read/clear some of the
Report Cursor Position text --and that the loader accepts
what it finds already present (probably so that typing ahead
of time would work).

So: Looks to me like a probable U-Boot issue for which a
FreeBSD workaround to ignore text would have other
consequences (lack of effective typeahead for the loader
prompt).

===
Mark Millard
marklmi at yahoo.com