[J-core] Checking in.

[William D. Jones]

>Um, what's involved in setting it up?

>I've added it to my todo list (actually a comment in toys/pending/gettty.c) but
>I haven't used this before so have to research what success looks like. I'm
>guessing from https://tools.ietf.org/html/rfc1661#section-3.4 the handoff is
>basically recognizing a link configure packet and calling the ppp daemon, but
>the last time I set up ppp was actually pppoe and it was last decade.)

Took me long enough to respond to this, but...

On the NetBSD getty, before exec()ing, getty waits for a string to be returned
that either corresponds to a login username or a sequence of PPP fields defined in
RFC 1662: https://github.com/NetBSD/src/blob/trunk/libexec/getty/main.c#L388

If a newline is detected at any point, getty assumes the user typed in a login
username and then exec()s login. However, at the same time it's looking for
a newline, the getname() function is going through a state machine looking
for PPP fields in a specific order:
https://github.com/NetBSD/src/blob/trunk/libexec/getty/main.c#L487-L511

If enough PPP fields are seen in order, getty stops waiting for a username
and exec()s ppplogin:
https://github.com/NetBSD/src/blob/trunk/libexec/getty/main.c#L390

This means that once a user presses enter at any point while getty is running,
it goes straight to login and the opportunity to negotiate a PPP connection
is lost. This never bothered me that much (though it makes bringing up a
connection automatically on the other peer at boot time a bit complex), and
makes the code simpler.

I believe that covers everything. Let me know if you have other questions and
thank you for looking into this :).

Sincerely,

On 12/17/2019 12:55 AM, Rob Landley wrote:
> Sorry, gmail's spam filter ate this for some reason. Just fished it out.
>
> On 12/6/19 2:26 PM, wjones at wdj-consulting.com wrote:
>>> In the existing bitstream? One. The USB-A charge connection thingy has a serial
>>> port on it, which the kernel serial console defaults to. (I.E. plug it into a
>>> laptop or powered hub and it's both the power source and a serial data connection.)
>> In my setup, it's _probably_ not going to be feasible to use a serial port
>> that's shared with the power connection. I plan to plug the TurtleBoard directly
>> into an outlet. What is the current draw of the TurtleBoard under load if you
>> know? I can _try_ it and see what happens, of course.
> Um, I don't have a tool that shows me the current draw on a USB port. Is there a
> way to get Linux to tell you that? (Although the USB stack probably only knows
> what it's negotiated, not how much it's actually _using_...)
>
> Martin or Jeff might have real figures?
>
>>> Here's an old post about modifying the bitstream to put serial ports on the GPIO
>> pins:
>> http://lists.j-core.org/pipermail/j-core/2016-April/000070.html
>>
>> This is very good to know, I'm probably going to have to go this route and
>> redirect the kernel console to this port.
> The kernel console info is on the kernel command line. I believe we're supplying
> the kernel command line via device tree, thus it's in the .dtb file on the sd
> card? (That's a Rich Felker question, really.)
>
> The ultimate source of it is CONFIG_CMDLINE="console=ttyUL0 earlycon"
> in arch/sh/configs/j2_defconnfig in the kernel source, so presumably if you
> change that and rebuild everything and replace all the files, it should just
> work. But I _think_ the .dtb file is the important one for this...)
>
>>> We have a TODO item to hook up DMA to the serial port in the kernel, but haven't
>> done it yet.
>> Not a big deal, even on my most powerful SBC (Tinker Board), DMA on the serial
>> port doesn't work :P. I'll manage without it.
> If you're using the serial port as your network stack, you're gonna want a big
> FIFO and DMA if at all possible. (And to dial the speed up as fast as possible.
> I dunno where the clock we're using for serial currently maxes out, Jeff and I
> talked about this last year but I have no idea where the notes on it would be.
> In _theory_ I think we can do 4 megabit, in practice I dunno what kind of
> pentagrams and dribbly candles are required to make that work. That's a jeff
> question.)
>
>>> I could add a getty to toybox that does it, I just didn't know there was demand?
>> I would appreciate that; I know my use case is niche, but PPP has actually saved
>> me a number of times where the a serial line (combined with proxy ARP) is the
>> only convenient way to get Internet access. A multiplexing getty, _once it's set
>> up_ :), makes debugging issues _a lot_ easier.
> Um, what's involved in setting it up?
>
> I've added it to my todo list (actually a comment in toys/pending/gettty.c) but
> I haven't used this before so have to research what success looks like. I'm
> guessing from https://tools.ietf.org/html/rfc1661#section-3.4 the handoff is
> basically recognizing a link configure packet and calling the ppp daemon, but
> the last time I set up ppp was actually pppoe and it was last decade.)
>
> Rob
>
>> -----Original Message----- From: Rob Landley
>> Sent: Friday, December 06, 2019 3:09 PM
>> To: wjones at wdj-consulting.com
>> Cc: j-core at lists.j-core.org
>> Subject: Re: [J-core] Checking in.
>>
>> On 12/6/19 6:48 AM, wjones at wdj-consulting.com wrote:
>>> While this is on my mind...
>>>
>>> How many UARTs are available on TurtleBoard?
>> In the existing bitstream? One. The USB-A charge connection thingy has a serial
>> port on it, which the kernel serial console defaults to. (I.E. plug it into a
>> laptop or powered hub and it's both the power source and a serial data connection.)
>>
>> It's got 4 standard USB ports, each of which can have a serial adapter plugged
>> into it, or add a USB hub and I think you can have 127 devices?
>>
>> Here's an old post about modifying the bitstream to put serial ports on the GPIO
>> pins:
>>
>>   http://lists.j-core.org/pipermail/j-core/2016-April/000070.html
>>
>> You might need an i2c to uart converter chip depending on what electrical
>> signals you want to hook it to at the other end, but Jeff didn't use one when he
>> slapped one of those together on a numato board that had a bad serial connector
>> so he rebuilt the bitstream for a demo an hour beforehand. (He just stuck wires
>> on the pins and it worked for him? You need the stty command to disable
>> hardaware flow control, but you needed that on numato anyway. Unless you wire up
>> the 4 pin version in the bitstream...)
>>
>>> I don't actually plan to use the
>>> Ethernet on my TurtleBoard. Instead, I plan use PPP to connect it to the
>>> Internet (it'll connect a UART to a wifi-enabled board's secondary UART). If
>>> there is only room for one UART plus Ethernet, is it possible to accommodate my
>>> requirement and replace Ethernet with a second UART in the bitstream?
>> UARTs are tiny and even the _small_ turtle is LX25: that's almost 3 times the
>> size of the LX9 in the numato board. And the LX45 version is 5 times the size of
>> the LX9.
>>
>> We have a TODO item to hook up DMA to the serial port in the kernel, but haven't
>> done it yet.
>>
>>> The (Net)BSD getty is smart enough to multiplex pppd and login when only a
>>> single UART is available, but I don't believe any Linux getty implementations
>>> have this feature...
>> I could add a getty to toybox that does it, I just didn't know there was demand?
>>
>> Jeff flew to Japan yesterday and I haven't heard from him since (probably
>> collapsed as soon as he got there, 10 hour time difference from Ontario and he
>> flew out after noon), but he's the guy to ask about the ship schedule. The
>> hardware's here, the blocker is us fleshing out the bitstream and doing the
>> packaging and documentation and such...
>>
>> Rob
>>
>> -- 
>> William D. Jones
>> wjones at wdj-consulting.com
>>

-- 
William D. Jones
wjones at wdj-consulting.com