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

Wed Dec 23 18:29:46 CET 2020

> Am 23.12.2020 um 17:18 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Wednesday, 23 December 2020 15:56:01 CET H. Nikolaus Schaller wrote:
>> Hi all,
>> having had an inspiration, I switched my rootfs from Bullseye to Jessie.
>> And now I can boot up to a login!
>> 
>> The boot process is painfully slow, but finally succeeds. Operation on
>> command line feels quick.
>> 
>> First collection of impressions:
>> - MMC is working (even w/o DMA)
> 
> It looks like I got the address wrong for the DMA and it was staring me in the 
> face the whole time. Instead of 0x10020000, the registers are at 0x13020000. 

The same for me using bootargs with root=/dev/mmcblk1p2...

> I've updated the documentation to reflect this.
> 
> So, the device tree will need updating as indicated by the accompanying patch. 
> Since the erroneous addresses were in the MMC region, it is likely that the 
> mistake was having other undesirable effects, but at least any problems from 
> now on will be genuine ones!

I have checked but the boot now hangs at
 Waiting for root device

There is some __mmc_start_req() and mmc_wait_for_cmd() activity but the card
type and size is not decoded. So it appears as if DMA is initialized but not
running. BTW: the register dump at 13020000 is still almost 0 although
I now have

[    0.056651] jz4780-dma 13020000.dma: JZ4780 DMA controller initialised

which indicates that the address is ok.

Well, this is low priority at the moment since we have a workaround.

> 
>> - date is counting in 1 second steps, so only the timing info in dmesg is
>> wrong (maybe the 1 second timer is ok, but the µs or ns count wrong)
> 
> I will still take a look at the OST peripheral. I'm still not sure whether to 
> keep making the TCU driver pretend that it has TCU timers, as is done now, or 
> whether to support multiple OST timers instead. But the width of the timers 
> will need to be configurable.

Ok.

> 
>> - TCP/IP works on loopback
>> - some device drivers are not successfully loaded
>>  (some of them are part of the default Letux setup and make no sense, e.g.
>> g-ether, bluetooth)
>> - keyboard /dev/input exists and evtest lists the keys but it reports a
>> KEY_FN autorepeat...
>> - USB is not working
> 
> USB host support should be relatively straightforward to achieve, since 
> previous investigations suggested that a generic OHCI driver would work, and 
> that is why the device tree is as it is.
> 
> The device tree has the USB peripheral disabled in the JZ4730, and we 

> introduced a GPIO-gated clock in the Mipsbook device tree to allow the 
> external 48MHz clock signal to be fed into the SoC, this then being selected 
> to provide the USB peripheral clock.
> 
> So, I guess that if we were to "override" the uhc definition in the Mipsbook 
> device tree, indicating that the peripheral is enabled (status = "okay"), the 
> necessary events might occur to propagate the external 48MHz clock signal into 
> the SoC and for the USB peripheral to get that signal. But this may be based 
> on a flawed mental model of how this stuff works.

Yes, indeed that enables USB :)

It even finds the Zydas trackpad controller and the WiFi module...
Even firmware loads and I can see at least 3 networks.
So it now seems possible to do apt-get update :)

[    0.432490] usb 1-2.3: new low-speed USB device number 3 using ohci-platform
[    0.451844] usb 1-2.3: New USB device found, idVendor=0a81, idProduct=0205, bcdDevice= 0.10
[    0.443047] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    0.450690] usb 1-2.3: Product: PS2 to USB Converter
[    0.455871] usb 1-2.3: Manufacturer: CHESEN
[    0.455193] input: CHESEN PS2 to USB Converter as /devices/platform/13030000.uhc/usb1/1-2/1-2.3/1-2.3:1.0/0003:0A81:0205.0001/input/input2
[    0.458786] hid-generic 0003:0A81:0205.0001: input: USB HID v1.10 Keyboard [CHESEN PS2 to USB Converter] on usb-13030000.uhc-2.3/input0
[    0.465241] input: CHESEN PS2 to USB Converter Mouse as /devices/platform/13030000.uhc/usb1/1-2/1-2.3/1-2.3:1.1/0003:0A81:0205.0002/input/input3
[    0.464119] input: CHESEN PS2 to USB Converter System Control as /devices/platform/13030000.uhc/usb1/1-2/1-2.3/1-2.3:1.1/0003:0A81:0205.0002/input/input4
[    0.466069] input: CHESEN PS2 to USB Converter Consumer Control as /devices/platform/13030000.uhc/usb1/1-2/1-2.3/1-2.3:1.1/0003:0A81:0205.0002/input/input5

[    0.469955] usb 1-2.4: new full-speed USB device number 4 using ohci-platform
[    0.483202] usb 1-2.4: New USB device found, idVendor=0ace, idProduct=1215, bcdDevice=48.10
[    0.474409] usb 1-2.4: New USB device strings: Mfr=16, Product=32, SerialNumber=0
[    0.482228] usb 1-2.4: Product: USB2.0 WLAN
[    0.486626] usb 1-2.4: Manufacturer: ZyDAS

[    1.307372] zd1211rw 1-2.4:1.0: firmware version 4725
[    1.307995] zd1211rw 1-2.4:1.0: zd1211b chip 0ace:1215 v4810 full 00-fd-07 UW2453_RF pa0 g7---

root at letux:~# lsusb
Bus 001 Device 004: ID 0ace:1215 ZyDAS ZD1211B 802.11g
Bus 001 Device 003: ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter
Bus 001 Device 002: ID 058f:9254 Alcor Micro Corp. Hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root at letux:~# 

root at letux:~# iwconfig
lo        no wireless extensions.

wlan0     IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

root at letux:~# 

> 
>> - Ethernet and WiFi are obviously not working (expected)
> 
> Since we have documentation for the Ethernet peripheral now, there is a chance 
> of making this work, I guess.
> 
>> - I2C only reports timeouts for i2cdetect
> 
> I guess another review of the code cannot hurt. It is likely that this not 
> working will prevent the RTC from working.

Yes. RTC, Power Management Chip and Audio all need I2C.

> 
>> - LCD is not working (expected)
> 
> Also for this.

Another finding: there is a pwm backlight in /sys/class/backlight but it does
not respond. Maybe another pinctrl issue.

> 
>> - no sound card (expected)
> 
> This will take some more investigation as I've never done anything with the 
> sound support.

I think we can work on this if the other parts are fixed.

What was easy to fix was a DTC warning about missing #sound-dai-cells which also
was reported by the boot log.

But we need to fix I2C so that the sound codec is found.

> 
>> - there are 3 rtc devices (/dev/rtc, /dev/rtc0, /dev/rtc1) and none is
>> working
> 
> A review of what we were doing with the CI20 might be required given the 
> presence of the PCF8563T, which is accessed using I2C (noted above).
> 
>> - only 2 out of the 3 caps/num/scroll lock LEDs are working (wrong gpio
>> assigned?)
> 
> According to the schematic, Num Lock is GP86 (PC22), Caps Lock is GP27 (PA27), 
> both consistent with the device tree. Scroll Lock is not on the schematic, but 
> "LANLED" appears at GP9 (PA27) which is given for Scroll Lock in the device 
> tree. I think we need to track this down.

I have found that the right trackpad mouse button was also hooked up for GP9
which gave a conflict. It should be GP13.

But the LAN_LED/GP9 (scroll lock) still remains dark on my machine. Could also
be broken...

> 
>> - trackpad not working (AFAIR it is USB)
> 
> Might it not be PS/2, accessible via the KBC (keyboard controller) peripheral? 
> On the schematic, the mousepad is connected to the PS2_KDATA and PS2_KCLK 
> lines.

Our device tree tries to set them up as GP16 and GP13 (after the fix). At
least these are going from J501 to the jz4730. I now get a new /dev/input/event1
device but the buttons don't respond. Rather they report once that both are pressed.

BTW: the keyboard no longer reports FN keys. Maybe a common issue? Pinmux setup?

Great that I can now boot to a shell and with the full programming manual I can play
with devmem2 to read/modify the pinmux registers... That likely speeds up fixing
all the remaining issues.

So the (priority) list boils down to:
- µs timer
- boot speed
- i2c
- lcd and backlight pwm
- keyboard, buttons
- rtc
- powerdown/reboot/suspend?
- dma for mmc
- ethernet
- sound
- nand

I think I will next focus on i2c since I already had made it work 10 years ago:
https://git.goldelico.com/?p=letux-400.git;a=commit;h=3df7a8077465d5aa75106b6373ecfb8b7f58b3ec

> 
>> Despite all these issues it is IMHO a nice Xmas present to have the Letux
>> 400 back to some operation :)
> 
> Great news, despite all the failures. ;-)
> 
> Merry Christmas!

Same to you and everyone reading these mails,
Nikolaus