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

[H. Nikolaus Schaller]

Hi Paul,

> Am 16.12.2020 um 01:04 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
>> A complex but doable approach: add code to jz4740_mmc_probe
>> to printk mmc controller registers and pinmux registers and
>> perhaps also gpio controller (for cd, wp, SD power).
>> 
>> And hack the same into the 2.6 kernel which we can boot.

I am working on this. It is really challenging...

The key challenge is not to compile the 2.6 kernel or to boot to X11
but get access to the machine to read out the dmesg buffer.

Firstly the boot log on RS232 stops after

Uncompressing Kernel Image ... OK

Starting kernel ...

and continues on the screen as a text console. But scrolls off
screen before I can see anything interesting.

Next, there is no getty on the console. This all is different from the 2.4
kernel where boot messages only go to the serial interface.
With 2.4 I get /proc/cmdline: mem=128M console=ttyS0,115200n8 root=/dev/ssfdca1 rw noatime

With ur 2.6 kernel after a short while the built-in OS starts with X11.
It works to some extent, i.e. X11 works and I can operate the touch - but
the mouse buttons do not work. Only tapping on the trackpad. Next obstacle,
there is no Terminal emulator on this kiosk OS.

Next finding: WiFi is broken but Ethernet works! But again some obstacle:
there is no telnetd or sshd on that rootfs. Only port 6000 is open but blocked
for external access.

I have tried to play with CONFIG_CMDLINE on the 2.6 kernel to switch
the console to serial and boot some newer rootfs from SD card but so far
no success... I think it did work some weeks ago but I have changed my
build process to accommodate the 5.x kernels and that may now influence
the 2.6 kernel build... (For example I can't build the 2.6 multithreaded
i.e. make -j4).

So there is need for more experimentation before I can read out the registers
on this 2.6 kernel as planned...

But at least the OS knows the SD card in the File Manager and I can inspect
the FAT partition. Well, the ext partition is missing. Maybe this is the
hint why I can't boot from it. If the EXT3_FS is not configured properly
or my SD card is damaged...

>> 
>> What I would need help for is a list of register addresses to
>> ioremap and readw/readl and printk. This would work without
>> shell and devmem2.
> 
> I can try and write these up.

Would be nice!

> 
>> PS: can it be that there is no card-detect interrupt?
>> The variable jz4740_mmc_host->card_detect_irq in jz4740_mmc.c
>> is nowhere used. (BTW: there is a similarly stale definition in
>> include/linux/platform_data/mmc-omap.h)
> 
> That does look very suspicious. The legacy kernel does actually request an IRQ 
> for the card detect signal (or "hotplug" as it calls it), and the condition 
> causes a variable to change value in the driver.
> 
> Looking a bit more closely at the current kernel, I can't see how it actually 
> tests for the card detect signal at all. The "cd-gpios" property is only 
> supported in three drivers:
> 
> drivers/mmc/host/mxcmmc.c
> drivers/mmc/host/atmel-mci.c
> drivers/mmc/host/sdhci-s3c.c

Oops. That isn't much. AFAIK there are many other boards which use it.
For example:

https://git.goldelico.com/?p=letux-kernel.git;a=blob;f=arch/arm/boot/dts/am335x-evm.dts;h=12dffccd1ffde00fa3b004b049117616c26526cb;hb=941b4e9e8a5201c36ad23d462ce3039ddbfe2b7f#l732

Maybe all of them now ignore the card-detect?

> 
> The most helpful one of these (to me) is the Atmel one. Here, they obtain the 
> pin details:
> 
> pdata->slot[slot_id].detect_pin = of_get_named_gpio(cnp, "cd-gpios", 0);
> 
> Then, they provide a function for the get_cd "slot" in the mmc_host_ops which 
> tests the pin. They also register an interrupt for the pin and presumably 
> service that when it occurs.

That is what I have not seen. Well, maybe there was another bug blocking it
when I tested last time.

> 
> However, it might be the case that we really want to define a "cd" property 
> instead. The core functionality in drivers/mmc/core/host.c contains the 
> following in the mmc_of_parse function that parses the device tree structure:
> 
> ret = mmc_gpiod_request_cd(host, "cd", 0, false,
>                           cd_debounce_delay_ms * 1000);
> if (!ret)
>        dev_info(host->parent, "Got CD GPIO\n");

Ok, that seems to be right code location.

Well, if you dig into what mmc_gpiod_request_cd() does
it comes to https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib.c#L1967
Where it just looks for a "label".

Most likely the -gpios suffix is stripped off during gpio
initialization so that this ends up in matching "cd" with "cd-gpios"
in the device tree.

BTW: if I remember correctly we did see the "Got CD GPIO\n".

> I don't know how that interacts with any interrupt mechanism, though. But 
> maybe replacing "cd-gpios" with "cd" might help.

I think it is likely that it should be setup as interrupt in mmc_gpiod_request_cd_irq(()
and most work is done inside gpiolib and neither mmc core nor mmc host driver
code. So they have moved all this special irq code from the legacy kernel (which did
repeat everywhere) into some lib. Which is really a good thing...

Anyways CD does not seem to be the biggest road-blocking bug if one at all.

BR and thanks,
Nikolaus