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

[H. Nikolaus Schaller]

Hi Paul,

> Am 05.12.2020 um 22:19 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Saturday, 5 December 2020 20:27:27 CET H. Nikolaus Schaller wrote:
>> Ok, first finding
>> 
>> So I tried the assumption that memory layout is more similar to the
>> JZ475 and JZ4740 than the JZ4780.
>> 
>>> 	dma: dma at 10020000 {
>>> 	
>>> 		compatible = "ingenic,jz4730-dma";
>>> 		reg = <0x10020000 0x100>, <0x10020300 0x14>;
>> 
>> Unfortunately it has an effect - which is that boot hangs after
>> 
>> [    0.009935] Console: colour dummy device 80x25
>> [    0.014479] printk: console [tty0] enabled
>> [    0.001103] printk: bootconsole [jz4740_uart0] disabled
>> 
>> Maybe something in the dma driver is hanging.
>> 
>> Questionable is the 0x100 - but it is usually not a problem to allocate
>> a little more as long as there is no overlap.
> 
> The 0x100 covers 6 channels each having a bank of 0x20, so it is just a 
> rounding up to a more readable amount, and this is probably done everywhere in 
> device tree files.
> 
> The 0x14 is the control registers. This should actually be something else, as 
> discussed below.
> 
>> Or does someone have a JZ4730 programmer's manual?
> 
> One has never been seen, maybe not even inside Ingenic. :-)

I still think to remember one or two documents / excerpts / application notes
for the I2C controller. I had used this to rewrite the I2C code for 2.6.

Ah, it was the jz4740-i2c which happened to be the same...

> 
>> Probably we also could dig out this from the older kernels or U-Boot.
> 
> Yes, it looks like the register layout is different. I missed this when 
> powering through the drivers. In particular...
> 
> * The descriptor address register is where the other SoCs put the target
>  address register (0x04 * channel), but fortunately the driver doesn't use
>  the target address register.

Ok.

> * The command register (0x14 * channel) is not provided, but this isn't used
>  by the driver, either.

Ok.

> 
> * The global control register is at 0xfc, not 0x300, and it appears to have
>  the same layout between the different SoCs.

Ok, so my guess was wrong that it is similar. Different address explains a lot.

> * The global interrupt pending register is at 0xf8, not 0x304. Although I
>  cannot find any particular layout for the JZ4730, it probably uses the same
>  scheme mapping channels to bits in the appropriate positions: bit 0 for
>  channel 0, and so on.

Yes, that is very likely. And if not we can add a printk and may see what is
going on.

> 
> So, what we might want to provide in the device tree is this:
> 
> reg = <0x10020000 0xc0>, <0x100200f8 0x08>;

Ok, I tried and ...

voila ...

[    0.034587] jz4780_dma_probe
[    0.028305] jz4780_dma_probe 1 res=839820a0
[    0.028497] jz4780_dma_probe 1b chn_base=b0020000
[    0.028626] jz4780_dma_probe 1c ctrl_base=b00200f8
[    0.028739] jz4780_dma_probe 2
[    0.029010] jz4780_dma_probe 3
[    0.029249] jz4780_dma_probe 4
[    0.029454] jz4780_dma_probe 5
[    0.029645] jz4780_dma_probe 6
[    0.029833] jz4780_dma_probe 7
[    0.030024] jz4780_dma_probe 8
[    0.030289] jz4780_dma_probe 9
[    0.030592] jz4780_dma_probe 10
[    0.034030] jz4780_dma_probe 11
[    0.034288] jz4780-dma 10020000.dma: JZ4780 DMA controller initialised

but still:

[    0.175120] pinctrl-ingenic 10010000.pin-controller: invalid group "PC0" for function "mmc"
[    0.167752] pinctrl-ingenic 10010000.pin-controller: invalid group "PC2" for function "mmc"
[    0.176580] pinctrl-ingenic 10010000.pin-controller: invalid group "PA21" for function "mmc"
[    0.170640] jz4740-mmc 10021000.mmc: Got CD GPIO
[    0.175726] jz4740-mmc 10021000.mmc: Got WP GPIO
[    0.180716] jz4740-mmc 10021000.mmc: Looking up vmmc-supply from device tree
[    0.172317] jz4740-mmc 10021000.mmc: Looking up vqmmc-supply from device tree
[    0.184387] jz4740-mmc 10021000.mmc: Failed to get dma_tx channel

So the failed dma_tx channel is something else. Next bunch of printk() in the next days :)

Do you have your machine in reach? Then I can describe how to skip digging into the boot
process and create a new bootable SD card... Then you can fully focus on the kernel.
And also have something to test.

BR and thanks,
Nikolaus