[Letux-kernel] [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel

[H. Nikolaus Schaller]

Hi Paul,
looks as if we lost CC to the ML...

> Am 17.12.2020 um 22:05 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Thursday, 17 December 2020 20:09:28 CET H. Nikolaus Schaller wrote:
>>> Am 17.12.2020 um 19:25 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> 
>>>> Am 17.12.2020 um 01:12 schrieb Paul Boddie <paul at boddie.org.uk>:
>>>> 
>>>> Meanwhile, if you are looking for programming manuals, I did notice that
>>>> someone had uploaded a collection of them to GitHub:
>>>> 
>>>> https://github.com/jz47xx/jz47xx.github.io/tree/master/manuals
>>> 
>>> Cool!
>>> 
>>> Unfortunately our baby is missing :(
> 
> My theory is that the JZ4730 was the first product they made in this series, 
> and as a result they didn't finish or release a manual for it.

Or did not translate it.

> Looking at 
> various peripherals, they differ somewhat from even the other, older SoCs such 
> as the JZ4740. The DMA register arrangement doesn't support descriptors due, 
> in part, to the way the command and status registers are combined, but this is 
> different on, and apparently consistent between, later SoCs. If it was a first 
> product, at least some of the things they did seem to work fairly well first 
> time, like the LCD controller.

I am quite sure that they did have several engineering tapeouts of the VHDL
for the first SoC. But after it was successful they added new requirements
which did extend functions which needed new registers.

> 
> [...]
> 
>>> I think someone just uses github as the backend...
> 
> Yes, probably.
> 
> [...]
> 
>> There is
>> 
>> jz_serial_setup() in arch/mips/jz4730/setup.c
>> 
>> Depends on CONFIG_SERIAL_8250 but that is enabled.
>> 
>> The old SD card says
>> 
>> serial8250: ttyS0 at MMIO 0x (irq = 9) is a 16550A
>> serial8250: ttyS1 at MMIO 0x (irq = 8) is a 16550A
>> serial8250: ttyS2 at MMIO 0x (irq = 7) is a 16550A
>> serial8250: ttyS3 at MMIO 0x (irq = 6) is a 16550A
>> 
>> Still I do not see any /dev/ttyS*. Maybe the device nodes are simply
>> missing? I think this system is so old that there is no udev, although
>> there is uevent. And I can find entries in /sys/class/tty - and ttyS0/dev =
>> 4:64
>> If I find more time I can try to translate that into some mknod.
> 
> I have only used the UART on the CI20, so I really can't say very much about 
> these earlier SoCs. It is possible that I put code into the Fiasco microkernel 
> to handle the UART, but it is entirely possible that I have used the wrong 
> driver. Then again, the JZ4740 manual claims that the UART is based on the 
> 16550 standard, and it is this code I have enabled in Fiasco, so perhaps it 
> might work. At one time I was trying to debug the Ben NanoNote by holding 
> wires against the UART pads and did get U-Boot to send data, but that was not 
> convenient. I haven't been inclined to try again with Fiasco.
> 
> Wikipedia indicates that the 16550 UART is backwards compatible with the 8250 
> UART, so maybe the right driver is being used, as your output indicates. 
> However, the MMIO values obviously seem wrong, if they are meant to be 
> informative. The UART0 I/O memory is at 0x10030000, with the other UART 
> channels at offsets of 0x1000.

Yes, the UARTs work well with the 5.10 kernel - at least I can type something
and it is echoed...

The current challenge (on the detour to success) is with the old 2.6 kernel
where I need some mechanism to be able to log the printk() I want to add to
mmc_probe()...

I have studied https://landley.net/kdocs/pending/hotplug.txt and my Lenny
seems to lack the /sbin/hotplug daemon...

But

mknod /dev/ttyS0 c 4 64; echo hello world >/dev/ttyS0

Initially did not work. Nor did S1/65, S2/66, S3/67.
Until I used stty to set the serial speed to 115200. It defaults to 9600.

So this proves that the old 2.6 kernel can emit something on the serial
console port. The remaining challenge is to find how to make the printk
log appear (before user-space is loaded)...

On OMAP3/ARM these old 2.6 kernels did have some config option which
could choose the UART for early printk, but I haven't found something
similar in our l400-2.6 tree. Maybe needs more research.

BR and thanks,
Nikolaus