rk3399-gru-kevin: issues on bringup

Sun Nov 7 18:26:09 CET 2021

On 06/11/2021 06:16, Simon Glass wrote:
> On Tue, 2 Nov 2021 at 17:05, Simon Glass <sjg at chromium.org> wrote:
>> On Mon, 1 Nov 2021 at 17:25, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
>>> Most of the patches are small config and dts changes that I've grouped
>>> by whatever effect they have. Should I squash them into one commit each
>>> for config/dts?
>>
>> Probably best.

I did so and updated the branches, now the series goes like this:

  rockchip: gru: Set up SoC IO domain registers
  rockchip: gru: Add more devicetree settings
  rockchip: bob: Enable more configs
  rockchip: rk3399: Add support for chromebook_kevin

>>> Marty, your (second) chromebook_kevin support patch didn't have your
>>> sign-off. Is it OK to add it? See:

I still didn't add a sign-off for this patch. There is an earlier
version with one [1]. I'm not sure if I can add the sign-off citing
that, or send the patches without a sign-off. I guess I'll wait a bit
more for a reply?

[1] https://patchwork.ozlabs.org/patch/1053386/

>> I actually have bob in my lab but I have not tried the Chrome OS boot
>> script on it. I could probably add kevin.

Booting the Chrome OS way would be an interesting experiment. I might
eventually work on it, but not exactly a priority for me right now
unless if it makes it easier for you to test things on these boards :D .

>> $ do-try-int.sh bob
>> Revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a, board bob

(I notice this was on a recent u-boot/master instead of my branch)

> Just to note that I have a kevin in my lab now and it boots into
> U-Boot with your
> 
> https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks
> 
> I also tried Bob and got this:
> 
> $ do-try-int.sh bob
> Revision 6a549d02fc43408cf4f000cc97688e7a64948572, board bob
> 
> Checking revision 6a549d02fc43408cf4f000cc97688e7a64948572
> /vid/software/devel/ubtest
> tbot starting ...
> ├─Parameters:
> │     rev        = '6a549d02fc43408cf4f000cc97688e7a64948572'
> │     clean      = False
> ├─Calling uboot_build_and_flash ...
> │   ├─bob is on port 9904 and uses /dev/pts/37
> │   ├─POWERON (bob)
> │   ├─Calling uboot_build ...
> │   │   ├─Calling uboot_checkout ...
> │   │   │   ├─Builder: bob
> │   │   │   └─Done. (0.195s)
> │   │   ├─Configuring build ...
> │   │   ├─Calling uboot_make ...
> │   │   │   └─Done. (9.943s)
> │   │   └─Done. (10.329s)
> │   ├─Calling uboot_flash ...
> │   │   └─Done. (2.209s)
> │   ├─POWEROFF (bob)
> │   └─Done. (13.305s)
> ├─────────────────────────────────────────
> └─SUCCESS (13.438s)
> tbot starting ...
> ├─Calling interactive_board ...
> │   ├─bob is on port 9904 and uses /dev/pts/37
> │   ├─POWERON (bob)
> │   ├─Entering interactive shell (CTRL+D to exit) ...
> Channel 0: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> Channel 1: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> 256B stride
> 
> U-Boot SPL 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)
> Trying to boot from SPI
> rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19
> rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19
> ns16550_serial serial at ff1a0000: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19

I have a feeling that this is because the SPL devicetree filters out
pinctrl subnodes while some other included nodes might be referring to
those. That might be what's causing the same messages in sandbox as well...

> U-Boot 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)
> 
> Model: Google Bob
> DRAM:  3.9 GiB
> MMC:   mmc at fe320000: 1, mmc at fe330000: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default environment
> 
> In:    cros-ec-keyb
> Out:   vidconsole
> Err:   vidconsole
> Model: Google Bob
> Net:   No ethernet found.

Could you manually confirm that the display and keyboard works?

> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0(part 0) is current device
> Scanning mmc 0:c...
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Scanning disk mmc at fe320000.blk...
> Disk mmc at fe320000.blk not ready
> Scanning disk mmc at fe330000.blk...
> fs_devread read outside partition 2
> Failed to mount ext2 filesystem...
> fs_devread read outside partition 2
> Failed to mount ext2 filesystem...
> fs_devread read outside partition 2
> Failed to mount ext2 filesystem...
> fs_devread read outside partition 2
> Failed to mount ext2 filesystem...
> Found 13 disks
> [...]
> =>

This starts with mmc1 (microSD card) for me and gives an error for mmc0
(eMMC) which I have to prevent with a hack to skip its re-init. Nice to
see that Bob doesn't need that. Other than that I see the same output
with Chrome OS installed on eMMC.

I would greatly appreciate it if you could try booting into any Linux
really, to have some logs of what goes wrong while doing so. Debian's
installer images [2] should be somewhat working on Kevin/Bob.
Booting after USB is initialized requires a patch [3] to fix a hang though.

[2]
https://deb.debian.org/debian/dists/bullseye/main/installer-arm64/current/images/netboot/gtk/SD-card-images/

[3]
https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icenowy@aosc.io/

> Having both in my lab will make it much easier to test.

Thanks for the tests so far!