Page MenuHomeFreeBSD

LININO-ONE Support
AbandonedPublic

Authored by sbruno on Sep 28 2014, 4:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 6, 11:58 PM
Unknown Object (File)
Mon, Oct 6, 10:06 AM
Unknown Object (File)
Mon, Oct 6, 9:20 AM
Unknown Object (File)
Mon, Oct 6, 8:09 AM
Unknown Object (File)
Tue, Sep 30, 12:38 PM
Unknown Object (File)
Sep 4 2025, 10:41 PM
Unknown Object (File)
Aug 2 2025, 9:21 PM
Unknown Object (File)
Jul 11 2025, 3:30 AM
Subscribers

Details

Reviewers
emaste
gnn
adrian
Summary

Silly device uses a 250000 "baud" serial console, but otherwise
is just an AR9331 MIPS 24k device.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

sbruno retitled this revision from to LININO-ONE Support.
sbruno updated this object.
sbruno edited the test plan for this revision. (Show Details)
sbruno added reviewers: gnn, adrian.
adrian edited edge metadata.

Hah, 250000? Wow.

Maybe we should add support for much faster baud rates? I know various later model hardware (like FTDI) supports much faster bitrates.

But sure. Woo!

This revision is now accepted and ready to land.Sep 28 2014, 6:21 PM
adrian requested changes to this revision.Sep 28 2014, 6:23 PM
adrian edited edge metadata.

.. hm, returning UART_IOCTL_BAUD as 250,000 always could be problematic. We should likely teach the AR9331 UART driver about baud rate changes.

This revision now requires changes to proceed.Sep 28 2014, 6:23 PM

My build file, suitable for tftp and tested at EuroBSDCon with gnn:

http://people.freebsd.org/~sbruno/linino-one.factory.img

According to emaste@ it is now common for cheaper devices with certain crystals to require these odd baud rates. Since this is just an upper limit I see no harm in adding it in general. Is there a way to add a hint to update the baud rate so we don't have to hard code 250000 in the uart files?

The AR9331 ends up taking a 25MHz or 40MHz XTAL as its base clock reference - so no, it's not going to be a "cheaper crystal." It isn't a 16550 style UART with a fixed set of divisors - It'll likely synthesize 115200 well enough.

The other possibility is they don't want people screwing with the console unless they know what they're doing. There's also the possibility they're doing comms with the AVR over the UART, and thus they're wanting to clock it as fast as they can.

.. that UART on the AR9331 will go up to a few megabits, btw.

One possibility is to use a uart.baudrate hint.

Well, the reason I'm hard-code returning 115200 is because I didn't implement the "figure out the baud rate from the hardware rate."

So, what we should do in that ioctl is:

  • track what the current baud rate is - we do program it as needed
  • have some hint to set the baud rate at startup
  • have the ioctl return the current baud rate rather than a hard-coded rate.

I'll take a look at implementing that bit.

So, how about committing all the bits that add 250,000 as a valid baud rate to the TTY code and gettytab.

Then we'll open up a separate review for the AR9331 UART init and baud rate bits?

I believe if you update the ARxxxx uart code to obtain the actual hardware baud rate and return it for a UART_IOCTL_BAUD request, then the only other change needed would be to ensure that /dev/ttyu0 in /etc/ttys is set for "3wire" (without a speed). None of the other changes in this diff are needed.

I confirmed this by doing this exercise for imx6 -- its UART_IOCTL_BAUD was returning hard-coded 115200 and I changed it to return the actual hardware rate. Now in u-boot I can set any console speed and the kernel just uses it.

In D871#16, @ian wrote:

I believe if you update the ARxxxx uart code to obtain the actual hardware baud rate and return it for a UART_IOCTL_BAUD request, then the only other change needed would be to ensure that /dev/ttyu0 in /etc/ttys is set for "3wire" (without a speed). None of the other changes in this diff are needed.

I confirmed this by doing this exercise for imx6 -- its UART_IOCTL_BAUD was returning hard-coded 115200 and I changed it to return the actual hardware rate. Now in u-boot I can set any console speed and the kernel just uses it.

it looks like sys/mips/atheros/uart_dev_ar933x.c::ar933x_uarg_get_baud() doesn't probe the device to get the baud rate. I'll look at specifications to see if I can probe it from h/w

Found this on the interwebs, don't know if Atheros has officially released docs for public consumption though. http://www.openhacks.com/uploadsproductos/ar9331_datasheet.pdf

sbruno edited edge metadata.

Begin implementation of "read the baudrate info" and just use that.

Tested on MR-3020, waiting for bits to arrive for linino-one that
has the 250,000 baud serial console.

sys/mips/atheros/uart_dev_ar933x.c
159

We should either replace this loop to find scale and step with the formula recommended in the datasheet (if someone has hardware to test the change), or at least fix the definition of AR933X_UART_MAX_STEP (0xffff should be 0x3333 according to the datasheet).

I no longer have this hardware.