Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
On 2024-01-26 14:46, Quentin Schulz wrote: On 1/26/24 12:33, Dragan Simic wrote: On 2024-01-26 12:29, Quentin Schulz wrote: On 1/26/24 12:24, Dragan Simic wrote: On 2024-01-26 12:09, Quentin Schulz wrote: On 1/26/24 12:04, Dragan Simic wrote: On 2024-01-26 11:37, Quentin Schulz wrote: On 1/26/24 03:57, Kever Yang wrote: On 2024/1/25 19:02, Quentin Schulz wrote: We don't have a dedicated CD pin for the SD card connector. https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use. Thanks for your information, but I think you are using the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs. Here are four microSD card connector from the web you provide, all of them have card detect signal available for pcb: https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors None of those fit our requirements. We need a safe system that doesn't break because of vibrations or shocks. Push-pull connectors are out of question for our design. We have had issues with our Q7 devkit with push-pull connector with SD cards slightly smaller or inserted somewhat the wrong way. I can recall also countless of discussions in the early days of the Raspberry Pis where there were a lot of issues related to SD cards. This is basically the mechanism we are using https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg Please, allow me to interject... I'm really curious why don't you use eMMC chips instead of microSD cards? I mean, if the reliability is of utmost importance, I wouldn't even consider microSD cards, not even the high-endurance variants. We have both :) Ah, I see. :) Perhaps my question wasn't precise enough; actually, now I'd like to know what do you use as the primary storage for the operating system installation -- eMMC chip or microSD cards? Is the eMMC chip soldered? I'm just curious. :) Soldered eMMC is the primary (expected) storage. If both eMMC and SD card are inserted and properly flashed, it'll boot from eMMC except if the BIOS button is pressed, in which case SD card will be selected instead. If SD card is missing/improperly flashed, it'll boot into USB flashing mode (rkdeveloptool/rockusb) if the BIOS button is pressed (similar to when no storage media is properly flashed). Thanks for the clarification. Just one more question, please: is the BIOS button handled in software (i.e. in U-Boot), or does it disable the eMMC chip by shorting its clock or a data line to ground? None of those options :) On RK3588, the boot media selection and order is done via the channel 0 of the SARADC. So a specific voltage is provided to boot from eMMC or from SD card. Ah, it's nice to see that RK3588 feature actually used. Thanks for the clarification!
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hi Dragan, On 1/26/24 12:33, Dragan Simic wrote: On 2024-01-26 12:29, Quentin Schulz wrote: On 1/26/24 12:24, Dragan Simic wrote: On 2024-01-26 12:09, Quentin Schulz wrote: On 1/26/24 12:04, Dragan Simic wrote: On 2024-01-26 11:37, Quentin Schulz wrote: On 1/26/24 03:57, Kever Yang wrote: On 2024/1/25 19:02, Quentin Schulz wrote: We don't have a dedicated CD pin for the SD card connector. https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use. Thanks for your information, but I think you are using the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs. Here are four microSD card connector from the web you provide, all of them have card detect signal available for pcb: https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors None of those fit our requirements. We need a safe system that doesn't break because of vibrations or shocks. Push-pull connectors are out of question for our design. We have had issues with our Q7 devkit with push-pull connector with SD cards slightly smaller or inserted somewhat the wrong way. I can recall also countless of discussions in the early days of the Raspberry Pis where there were a lot of issues related to SD cards. This is basically the mechanism we are using https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg Please, allow me to interject... I'm really curious why don't you use eMMC chips instead of microSD cards? I mean, if the reliability is of utmost importance, I wouldn't even consider microSD cards, not even the high-endurance variants. We have both :) Ah, I see. :) Perhaps my question wasn't precise enough; actually, now I'd like to know what do you use as the primary storage for the operating system installation -- eMMC chip or microSD cards? Is the eMMC chip soldered? I'm just curious. :) Soldered eMMC is the primary (expected) storage. If both eMMC and SD card are inserted and properly flashed, it'll boot from eMMC except if the BIOS button is pressed, in which case SD card will be selected instead. If SD card is missing/improperly flashed, it'll boot into USB flashing mode (rkdeveloptool/rockusb) if the BIOS button is pressed (similar to when no storage media is properly flashed). Thanks for the clarification. Just one more question, please: is the BIOS button handled in software (i.e. in U-Boot), or does it disable the eMMC chip by shorting its clock or a data line to ground? None of those options :) On RK3588, the boot media selection and order is done via the channel 0 of the SARADC. So a specific voltage is provided to boot from eMMC or from SD card. Quentin
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
On 2024-01-26 12:29, Quentin Schulz wrote: On 1/26/24 12:24, Dragan Simic wrote: On 2024-01-26 12:09, Quentin Schulz wrote: On 1/26/24 12:04, Dragan Simic wrote: On 2024-01-26 11:37, Quentin Schulz wrote: On 1/26/24 03:57, Kever Yang wrote: On 2024/1/25 19:02, Quentin Schulz wrote: We don't have a dedicated CD pin for the SD card connector. https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use. Thanks for your information, but I think you are using the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs. Here are four microSD card connector from the web you provide, all of them have card detect signal available for pcb: https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors None of those fit our requirements. We need a safe system that doesn't break because of vibrations or shocks. Push-pull connectors are out of question for our design. We have had issues with our Q7 devkit with push-pull connector with SD cards slightly smaller or inserted somewhat the wrong way. I can recall also countless of discussions in the early days of the Raspberry Pis where there were a lot of issues related to SD cards. This is basically the mechanism we are using https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg Please, allow me to interject... I'm really curious why don't you use eMMC chips instead of microSD cards? I mean, if the reliability is of utmost importance, I wouldn't even consider microSD cards, not even the high-endurance variants. We have both :) Ah, I see. :) Perhaps my question wasn't precise enough; actually, now I'd like to know what do you use as the primary storage for the operating system installation -- eMMC chip or microSD cards? Is the eMMC chip soldered? I'm just curious. :) Soldered eMMC is the primary (expected) storage. If both eMMC and SD card are inserted and properly flashed, it'll boot from eMMC except if the BIOS button is pressed, in which case SD card will be selected instead. If SD card is missing/improperly flashed, it'll boot into USB flashing mode (rkdeveloptool/rockusb) if the BIOS button is pressed (similar to when no storage media is properly flashed). Thanks for the clarification. Just one more question, please: is the BIOS button handled in software (i.e. in U-Boot), or does it disable the eMMC chip by shorting its clock or a data line to ground?
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
On 1/26/24 12:24, Dragan Simic wrote: [Some people who received this message don't often get email from dsi...@manjaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On 2024-01-26 12:09, Quentin Schulz wrote: On 1/26/24 12:04, Dragan Simic wrote: On 2024-01-26 11:37, Quentin Schulz wrote: On 1/26/24 03:57, Kever Yang wrote: On 2024/1/25 19:02, Quentin Schulz wrote: We don't have a dedicated CD pin for the SD card connector. https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use. Thanks for your information, but I think you are using the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs. Here are four microSD card connector from the web you provide, all of them have card detect signal available for pcb: https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors None of those fit our requirements. We need a safe system that doesn't break because of vibrations or shocks. Push-pull connectors are out of question for our design. We have had issues with our Q7 devkit with push-pull connector with SD cards slightly smaller or inserted somewhat the wrong way. I can recall also countless of discussions in the early days of the Raspberry Pis where there were a lot of issues related to SD cards. This is basically the mechanism we are using https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg Please, allow me to interject... I'm really curious why don't you use eMMC chips instead of microSD cards? I mean, if the reliability is of utmost importance, I wouldn't even consider microSD cards, not even the high-endurance variants. We have both :) Ah, I see. :) Perhaps my question wasn't precise enough; actually, now I'd like to know what do you use as the primary storage for the operating system installation -- eMMC chip or microSD cards? Is the eMMC chip soldered? I'm just curious. :) Soldered eMMC is the primary (expected) storage. If both eMMC and SD card are inserted and properly flashed, it'll boot from eMMC except if the BIOS button is pressed, in which case SD card will be selected instead. If SD card is missing/improperly flashed, it'll boot into USB flashing mode (rkdeveloptool/rockusb) if the BIOS button is pressed (similar to when no storage media is properly flashed).
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
On 2024-01-26 12:09, Quentin Schulz wrote: On 1/26/24 12:04, Dragan Simic wrote: On 2024-01-26 11:37, Quentin Schulz wrote: On 1/26/24 03:57, Kever Yang wrote: On 2024/1/25 19:02, Quentin Schulz wrote: We don't have a dedicated CD pin for the SD card connector. https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use. Thanks for your information, but I think you are using the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs. Here are four microSD card connector from the web you provide, all of them have card detect signal available for pcb: https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors None of those fit our requirements. We need a safe system that doesn't break because of vibrations or shocks. Push-pull connectors are out of question for our design. We have had issues with our Q7 devkit with push-pull connector with SD cards slightly smaller or inserted somewhat the wrong way. I can recall also countless of discussions in the early days of the Raspberry Pis where there were a lot of issues related to SD cards. This is basically the mechanism we are using https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg Please, allow me to interject... I'm really curious why don't you use eMMC chips instead of microSD cards? I mean, if the reliability is of utmost importance, I wouldn't even consider microSD cards, not even the high-endurance variants. We have both :) Ah, I see. :) Perhaps my question wasn't precise enough; actually, now I'd like to know what do you use as the primary storage for the operating system installation -- eMMC chip or microSD cards? Is the eMMC chip soldered? I'm just curious. :) Just to name one potential use-case, you may want to save some data on SD card for investigation without the need for the system to run to dump data from the eMMC. It's there anyway, so now my job as a SW guy is to support it :) Sure, it needs to be supported, no matter what. The microSD slot is presumably there to be used as the secondary storage, or to perform operating system rescue, debugging and similar operations, as needed.
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hi Dragan, On 1/26/24 12:04, Dragan Simic wrote: [Some people who received this message don't often get email from dsi...@manjaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hello Quentin, On 2024-01-26 11:37, Quentin Schulz wrote: On 1/26/24 03:57, Kever Yang wrote: On 2024/1/25 19:02, Quentin Schulz wrote: We don't have a dedicated CD pin for the SD card connector. https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use. Thanks for your information, but I think you are using the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs. Here are four microSD card connector from the web you provide, all of them have card detect signal available for pcb: https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors None of those fit our requirements. We need a safe system that doesn't break because of vibrations or shocks. Push-pull connectors are out of question for our design. We have had issues with our Q7 devkit with push-pull connector with SD cards slightly smaller or inserted somewhat the wrong way. I can recall also countless of discussions in the early days of the Raspberry Pis where there were a lot of issues related to SD cards. This is basically the mechanism we are using https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg Please, allow me to interject... I'm really curious why don't you use eMMC chips instead of microSD cards? I mean, if the reliability is of utmost importance, I wouldn't even consider microSD cards, not even the high-endurance variants. We have both :) Just to name one potential use-case, you may want to save some data on SD card for investigation without the need for the system to run to dump data from the eMMC. It's there anyway, so now my job as a SW guy is to support it :) Quentin
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hello Quentin, On 2024-01-26 11:37, Quentin Schulz wrote: On 1/26/24 03:57, Kever Yang wrote: On 2024/1/25 19:02, Quentin Schulz wrote: We don't have a dedicated CD pin for the SD card connector. https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use. Thanks for your information, but I think you are using the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs. Here are four microSD card connector from the web you provide, all of them have card detect signal available for pcb: https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors None of those fit our requirements. We need a safe system that doesn't break because of vibrations or shocks. Push-pull connectors are out of question for our design. We have had issues with our Q7 devkit with push-pull connector with SD cards slightly smaller or inserted somewhat the wrong way. I can recall also countless of discussions in the early days of the Raspberry Pis where there were a lot of issues related to SD cards. This is basically the mechanism we are using https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg Please, allow me to interject... I'm really curious why don't you use eMMC chips instead of microSD cards? I mean, if the reliability is of utmost importance, I wouldn't even consider microSD cards, not even the high-endurance variants. I can admit on our pictures of Jaguar and on the Digikey link I provided earlier that it is not clear it is THAT kind of connector and not a push-pull one. It was clear to me, because I've already used hinged microSD slots. :) Also It works just fine in Linux kernel with broken-cd and in U-Boot with this patch, sooo I don't think it is "the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs." :)
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hi Kever, On 1/26/24 03:57, Kever Yang wrote: Hi Quentin, On 2024/1/25 19:02, Quentin Schulz wrote: Hi Kever, On 1/25/24 11:29, Kever Yang wrote: Hi Quentin, On 2024/1/24 18:50, Quentin Schulz wrote: Hi Kever, On 1/24/24 11:19, Kever Yang wrote: Hi Quentin, On 2024/1/23 22:49, Quentin Schulz wrote: From: Quentin Schulz Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't work really well.[00] The Linux kernel disables it for all SoCs[01], so U-Boot needs to do the same in order to fix issues related to SD card on RK3588. This autoswitching is enabled (by default) via the force_jtag bitfield in SYS_GRF_SOC_CON6 in the TRM part1. For some reason, when booting from SD card, the BootROM does mux the SDMMC controller in the proper configuration for the RK3588-Jaguar. But when we don't boot from SD card, U-Boot needs to set it up correctly to allow accessing SD cards in that configuration. Could you share what's the really issue you met in your board? I revert the patch and then I have the following when booting from eMMC: """ DDR V1.11 f1474cf52f cym 23/05/09-11:02:36 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB Manufacturer ID:0x1 CH0 RX Vref:27.1%, TX Vref:21.8%,0.0% CH1 RX Vref:30.1%, TX Vref:20.8%,0.0% CH2 RX Vref:27.9%, TX Vref:21.8%,0.0% CH3 RX Vref:31.4%, TX Vref:19.8%,0.0% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Trying to boot from MMC1 ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang NOTICE: BL31: Built : 10:14:29, May 9 2023 INFO: spec: 0x1 INFO: ext 32k is not valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: system boots from cpu-hwid-0 INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0xa0 INFO: SPSR = 0x3c9 U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Model: Theobroma Systems RK3588-SBC Jaguar DRAM: 4 GiB (effective 3.7 GiB) Core: 327 devices, 26 uclasses, devicetree: separate MMC: mmc@fe2c: 1, mmc@fe2e: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial@feb5 Out: serial@feb5 Err: serial@feb5 Model: Theobroma Systems RK3588-SBC Jaguar Net: eth0: ethernet@fe1b Hit any key to stop autoboot: 0 => mmc dev 1 unable to select a mode => """ The SD card will need to enable SD-DET for SD card function int he hardware design, We do not have an SD-DET on that board, this is not possible (the connector doesn't support it). SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating (the state by default since we expose it on an external connector) but we plan to let customer use it as a GPIO. I didn't follow this issue closely in kernel side before, but I would like to know why this happen. Is it possible to share the schematic of your board? I want to understand why you didn't use SDMMC_DET for the card slot in hardware design, which always need an IO for driver to detect the card. We don't have a dedicated CD pin for the SD card connector. https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use. Thanks for your information, but I think you are using the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs. Here are four microSD card connector from the web you provide, all of them have card detect signal available for pcb: https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors None of those fit our requirements. We need a safe system that doesn't break because of vibrations or shocks. Push-pull
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hi Quentin, On 2024/1/25 19:02, Quentin Schulz wrote: Hi Kever, On 1/25/24 11:29, Kever Yang wrote: Hi Quentin, On 2024/1/24 18:50, Quentin Schulz wrote: Hi Kever, On 1/24/24 11:19, Kever Yang wrote: Hi Quentin, On 2024/1/23 22:49, Quentin Schulz wrote: From: Quentin Schulz Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't work really well.[00] The Linux kernel disables it for all SoCs[01], so U-Boot needs to do the same in order to fix issues related to SD card on RK3588. This autoswitching is enabled (by default) via the force_jtag bitfield in SYS_GRF_SOC_CON6 in the TRM part1. For some reason, when booting from SD card, the BootROM does mux the SDMMC controller in the proper configuration for the RK3588-Jaguar. But when we don't boot from SD card, U-Boot needs to set it up correctly to allow accessing SD cards in that configuration. Could you share what's the really issue you met in your board? I revert the patch and then I have the following when booting from eMMC: """ DDR V1.11 f1474cf52f cym 23/05/09-11:02:36 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB Manufacturer ID:0x1 CH0 RX Vref:27.1%, TX Vref:21.8%,0.0% CH1 RX Vref:30.1%, TX Vref:20.8%,0.0% CH2 RX Vref:27.9%, TX Vref:21.8%,0.0% CH3 RX Vref:31.4%, TX Vref:19.8%,0.0% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Trying to boot from MMC1 ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang NOTICE: BL31: Built : 10:14:29, May 9 2023 INFO: spec: 0x1 INFO: ext 32k is not valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: system boots from cpu-hwid-0 INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0xa0 INFO: SPSR = 0x3c9 U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Model: Theobroma Systems RK3588-SBC Jaguar DRAM: 4 GiB (effective 3.7 GiB) Core: 327 devices, 26 uclasses, devicetree: separate MMC: mmc@fe2c: 1, mmc@fe2e: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial@feb5 Out: serial@feb5 Err: serial@feb5 Model: Theobroma Systems RK3588-SBC Jaguar Net: eth0: ethernet@fe1b Hit any key to stop autoboot: 0 => mmc dev 1 unable to select a mode => """ The SD card will need to enable SD-DET for SD card function int he hardware design, We do not have an SD-DET on that board, this is not possible (the connector doesn't support it). SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating (the state by default since we expose it on an external connector) but we plan to let customer use it as a GPIO. I didn't follow this issue closely in kernel side before, but I would like to know why this happen. Is it possible to share the schematic of your board? I want to understand why you didn't use SDMMC_DET for the card slot in hardware design, which always need an IO for driver to detect the card. We don't have a dedicated CD pin for the SD card connector. https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use. Thanks for your information, but I think you are using the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs. Here are four microSD card connector from the web you provide, all of them have card detect signal available for pcb: https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors This is allowed by the SD spec, c.f. Table 3-1 : SD Memory Card Pad Assignment[1] """ 1 CD/DAT3(2) I/O/PP(3) Card Detect/Data Line [Bit 3] 2) The extended DAT lines
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hi Kever, On 1/25/24 11:29, Kever Yang wrote: Hi Quentin, On 2024/1/24 18:50, Quentin Schulz wrote: Hi Kever, On 1/24/24 11:19, Kever Yang wrote: Hi Quentin, On 2024/1/23 22:49, Quentin Schulz wrote: From: Quentin Schulz Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't work really well.[00] The Linux kernel disables it for all SoCs[01], so U-Boot needs to do the same in order to fix issues related to SD card on RK3588. This autoswitching is enabled (by default) via the force_jtag bitfield in SYS_GRF_SOC_CON6 in the TRM part1. For some reason, when booting from SD card, the BootROM does mux the SDMMC controller in the proper configuration for the RK3588-Jaguar. But when we don't boot from SD card, U-Boot needs to set it up correctly to allow accessing SD cards in that configuration. Could you share what's the really issue you met in your board? I revert the patch and then I have the following when booting from eMMC: """ DDR V1.11 f1474cf52f cym 23/05/09-11:02:36 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB Manufacturer ID:0x1 CH0 RX Vref:27.1%, TX Vref:21.8%,0.0% CH1 RX Vref:30.1%, TX Vref:20.8%,0.0% CH2 RX Vref:27.9%, TX Vref:21.8%,0.0% CH3 RX Vref:31.4%, TX Vref:19.8%,0.0% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Trying to boot from MMC1 ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang NOTICE: BL31: Built : 10:14:29, May 9 2023 INFO: spec: 0x1 INFO: ext 32k is not valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: system boots from cpu-hwid-0 INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0xa0 INFO: SPSR = 0x3c9 U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Model: Theobroma Systems RK3588-SBC Jaguar DRAM: 4 GiB (effective 3.7 GiB) Core: 327 devices, 26 uclasses, devicetree: separate MMC: mmc@fe2c: 1, mmc@fe2e: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial@feb5 Out: serial@feb5 Err: serial@feb5 Model: Theobroma Systems RK3588-SBC Jaguar Net: eth0: ethernet@fe1b Hit any key to stop autoboot: 0 => mmc dev 1 unable to select a mode => """ The SD card will need to enable SD-DET for SD card function int he hardware design, We do not have an SD-DET on that board, this is not possible (the connector doesn't support it). SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating (the state by default since we expose it on an external connector) but we plan to let customer use it as a GPIO. I didn't follow this issue closely in kernel side before, but I would like to know why this happen. Is it possible to share the schematic of your board? I want to understand why you didn't use SDMMC_DET for the card slot in hardware design, which always need an IO for driver to detect the card. We don't have a dedicated CD pin for the SD card connector. https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use. This is allowed by the SD spec, c.f. Table 3-1 : SD Memory Card Pad Assignment[1] """ 1 CD/DAT3(2) I/O/PP(3) Card Detect/Data Line [Bit 3] 2) The extended DAT lines (DAT1-DAT3) are input on power up. They start to operate as DAT lines after SET_BUS_WIDTH command. The Host shall keep its own DAT1-DAT3 lines in input mode, as well, while they are not used. 3) At power up this line has a 50KOhm pull up enabled in the card. This resistor serves two functions Card detection and Mode Selection. For Mode Selection, the host can drive the line high or let it be pulled
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hi Quentin, On 2024/1/24 18:50, Quentin Schulz wrote: Hi Kever, On 1/24/24 11:19, Kever Yang wrote: Hi Quentin, On 2024/1/23 22:49, Quentin Schulz wrote: From: Quentin Schulz Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't work really well.[00] The Linux kernel disables it for all SoCs[01], so U-Boot needs to do the same in order to fix issues related to SD card on RK3588. This autoswitching is enabled (by default) via the force_jtag bitfield in SYS_GRF_SOC_CON6 in the TRM part1. For some reason, when booting from SD card, the BootROM does mux the SDMMC controller in the proper configuration for the RK3588-Jaguar. But when we don't boot from SD card, U-Boot needs to set it up correctly to allow accessing SD cards in that configuration. Could you share what's the really issue you met in your board? I revert the patch and then I have the following when booting from eMMC: """ DDR V1.11 f1474cf52f cym 23/05/09-11:02:36 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB Manufacturer ID:0x1 CH0 RX Vref:27.1%, TX Vref:21.8%,0.0% CH1 RX Vref:30.1%, TX Vref:20.8%,0.0% CH2 RX Vref:27.9%, TX Vref:21.8%,0.0% CH3 RX Vref:31.4%, TX Vref:19.8%,0.0% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Trying to boot from MMC1 ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang NOTICE: BL31: Built : 10:14:29, May 9 2023 INFO: spec: 0x1 INFO: ext 32k is not valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: system boots from cpu-hwid-0 INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0xa0 INFO: SPSR = 0x3c9 U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Model: Theobroma Systems RK3588-SBC Jaguar DRAM: 4 GiB (effective 3.7 GiB) Core: 327 devices, 26 uclasses, devicetree: separate MMC: mmc@fe2c: 1, mmc@fe2e: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial@feb5 Out: serial@feb5 Err: serial@feb5 Model: Theobroma Systems RK3588-SBC Jaguar Net: eth0: ethernet@fe1b Hit any key to stop autoboot: 0 => mmc dev 1 unable to select a mode => """ The SD card will need to enable SD-DET for SD card function int he hardware design, We do not have an SD-DET on that board, this is not possible (the connector doesn't support it). SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating (the state by default since we expose it on an external connector) but we plan to let customer use it as a GPIO. I didn't follow this issue closely in kernel side before, but I would like to know why this happen. Is it possible to share the schematic of your board? I want to understand why you didn't use SDMMC_DET for the card slot in hardware design, which always need an IO for driver to detect the card. What I know is if the SD card using all the IO including SDMMC_DET with its iomux set to sdmmc function, then the force_jtag should work correctly. If you only use IO signal other than SDMMC_DET as sdmmc function, and set SDMMC_DET iomux work as GPIO, then yes, you need to disable the force_jtag. Since SDMMC_DET in rk3588 is an IO only have one function(not like other GPIOs may have more than 2 functions for choice), this IO can always be used as SDMMC_DET without conflict when the board has SDcard support. Thanks, - Kever which is rockchip reference design and followed by most of the customer and boards. This feature works in all the rk3588 boards we known, and no need to disable this auto switching. This is clearly not what people have experienced, c.f. the
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hi Kever, On 1/24/24 11:19, Kever Yang wrote: Hi Quentin, On 2024/1/23 22:49, Quentin Schulz wrote: From: Quentin Schulz Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't work really well.[00] The Linux kernel disables it for all SoCs[01], so U-Boot needs to do the same in order to fix issues related to SD card on RK3588. This autoswitching is enabled (by default) via the force_jtag bitfield in SYS_GRF_SOC_CON6 in the TRM part1. For some reason, when booting from SD card, the BootROM does mux the SDMMC controller in the proper configuration for the RK3588-Jaguar. But when we don't boot from SD card, U-Boot needs to set it up correctly to allow accessing SD cards in that configuration. Could you share what's the really issue you met in your board? I revert the patch and then I have the following when booting from eMMC: """ DDR V1.11 f1474cf52f cym 23/05/09-11:02:36 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB Manufacturer ID:0x1 CH0 RX Vref:27.1%, TX Vref:21.8%,0.0% CH1 RX Vref:30.1%, TX Vref:20.8%,0.0% CH2 RX Vref:27.9%, TX Vref:21.8%,0.0% CH3 RX Vref:31.4%, TX Vref:19.8%,0.0% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Trying to boot from MMC1 ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK INFO:Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang NOTICE: BL31: Built : 10:14:29, May 9 2023 INFO:spec: 0x1 INFO:ext 32k is not valid INFO:ddr: stride-en 4CH INFO:GICv3 without legacy support detected. INFO:ARM GICv3 driver initialized in EL3 INFO:valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO:system boots from cpu-hwid-0 INFO:idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO:dfs DDR fsp_params[0].freq_mhz= 2112MHz INFO:dfs DDR fsp_params[1].freq_mhz= 528MHz INFO:dfs DDR fsp_params[2].freq_mhz= 1068MHz INFO:dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO:BL31: Initialising Exception Handling Framework INFO:BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0xa0 INFO:SPSR = 0x3c9 U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Model: Theobroma Systems RK3588-SBC Jaguar DRAM: 4 GiB (effective 3.7 GiB) Core: 327 devices, 26 uclasses, devicetree: separate MMC: mmc@fe2c: 1, mmc@fe2e: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In:serial@feb5 Out: serial@feb5 Err: serial@feb5 Model: Theobroma Systems RK3588-SBC Jaguar Net: eth0: ethernet@fe1b Hit any key to stop autoboot: 0 => mmc dev 1 unable to select a mode => """ The SD card will need to enable SD-DET for SD card function int he hardware design, We do not have an SD-DET on that board, this is not possible (the connector doesn't support it). SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating (the state by default since we expose it on an external connector) but we plan to let customer use it as a GPIO. which is rockchip reference design and followed by most of the customer and boards. This feature works in all the rk3588 boards we known, and no need to disable this auto switching. This is clearly not what people have experienced, c.f. the Linux kernel patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/rockchip/grf.c?id=6f6878ec6faf16a5f36761c93da6ea9cf09adb33 Note that jtag_switching has been disabled for all Rockchip SoCs in the kernel, for a long long time already, c.f. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/rockchip/grf.c?id=4c58063d4258f6beb4fd5647db6b58f49e337c8f Cheers, Quentin
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hi Quentin,
On 2024/1/23 22:49, Quentin Schulz wrote:
From: Quentin Schulz
Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
work really well.[00] The Linux kernel disables it for all SoCs[01], so
U-Boot needs to do the same in order to fix issues related to SD card on
RK3588. This autoswitching is enabled (by default) via the force_jtag
bitfield in SYS_GRF_SOC_CON6 in the TRM part1.
For some reason, when booting from SD card, the BootROM does mux the
SDMMC controller in the proper configuration for the RK3588-Jaguar. But
when we don't boot from SD card, U-Boot needs to set it up correctly to
allow accessing SD cards in that configuration.
Could you share what's the really issue you met in your board?
The SD card will need to enable SD-DET for SD card function int he
hardware design,
which is rockchip reference design and followed by most of the customer
and boards.
This feature works in all the rk3588 boards we known, and no need to
disable this auto switching.
Thanks,
- Kever
Therefore, let's disable the JTAG mode for the SDMMC pins so that the SD
controller can be used either as a fallback mechanism to find U-Boot
proper when the boot medium used to load TPL/SPL cannot find U-Boot
proper, or to be used in U-Boot CLI.
Note that soc_con[0] is reserved. But considering that it's way more
user-friendly to access soc_con1 from the TRM with soc_con[1] than
soc_con[0], and that soc_con0 would actually be located at 4 bytes
before soc_con1, let's just make soc_con0 part of the soc_con array.
[00]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c9b75d51c940c25587a2ad72ec7ec60490abfb6c
[01]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/rockchip/grf.c
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
arch/arm/include/asm/arch-rockchip/grf_rk3588.h | 24
arch/arm/mach-rockchip/rk3588/rk3588.c | 7 +++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
index e0694068bb1..f0ecff97f0b 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
@@ -32,4 +32,28 @@ struct rk3588_pmu1grf {
check_member(rk3588_pmu1grf, sd_detect_cnt, 0x03b0);
+#define SYS_GRF_BASE 0xfd58c000
+
+struct rk3588_sysgrf {
+ unsigned int wdt_con0;
+ unsigned int reserved0[(0x0010 - 0x) / 4 - 1];
+ unsigned int uart_con[2];
+ unsigned int reserved1[(0x00c0 - 0x0014) / 4 - 1];
+ unsigned int gic_con0;
+ unsigned int reserved2[(0x0200 - 0x00c0) / 4 - 1];
+ unsigned int memcfg_con[32];
+ unsigned int reserved3[(0x0300 - 0x027c) / 4 - 1];
+ /* soc_con0 is reserved */
+ unsigned int soc_con[14];
+ unsigned int reserved4[(0x0380 - 0x0334) / 4 - 1];
+ unsigned int soc_status[4];
+ unsigned int reserved5[(0x0500 - 0x038c) / 4 - 1];
+ unsigned int otp_key08;
+ unsigned int otp_key0d;
+ unsigned int otp_key0e;
+ unsigned int reserved6[(0x0600 - 0x0508) / 4 - 1];
+ unsigned int chip_id;
+};
+
+check_member(rk3588_sysgrf, chip_id, 0x0600);
#endif /*__SOC_ROCKCHIP_RK3588_GRF_H__ */
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index 38e95a6e2b2..c5eeda9d751 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#define FIREWALL_DDR_BASE 0xfe03
#define FW_DDR_MST5_REG 0x54
@@ -35,6 +36,8 @@
#define BUS_IOC_GPIO2D_IOMUX_SEL_H0x5c
#define BUS_IOC_GPIO3A_IOMUX_SEL_L0x60
+#define SYS_GRF_FORCE_JTAG BIT(14)
+
/**
* Boot-device identifiers used by the BROM on RK3588 when device is booted
* from SPI flash. IOMUX used for SPI flash affect the value used by the BROM
@@ -134,6 +137,7 @@ void rockchip_stimer_init(void)
int arch_cpu_init(void)
{
#ifdef CONFIG_SPL_BUILD
+ static struct rk3588_sysgrf * const sys_grf = (void *)SYS_GRF_BASE;
int secure_reg;
/* Set the SDMMC eMMC crypto_ns FSPI access secure area */
@@ -168,6 +172,9 @@ int arch_cpu_init(void)
secure_reg = readl(FIREWALL_SYSMEM_BASE + FW_SYSM_MST27_REG);
secure_reg &= 0x;
writel(secure_reg, FIREWALL_SYSMEM_BASE + FW_SYSM_MST27_REG);
+
+ /* Disable JTAG exposed on SDMMC */
+ rk_clrreg(_grf->soc_con[6], SYS_GRF_FORCE_JTAG);
#endif
return 0;
[PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
From: Quentin Schulz
Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
work really well.[00] The Linux kernel disables it for all SoCs[01], so
U-Boot needs to do the same in order to fix issues related to SD card on
RK3588. This autoswitching is enabled (by default) via the force_jtag
bitfield in SYS_GRF_SOC_CON6 in the TRM part1.
For some reason, when booting from SD card, the BootROM does mux the
SDMMC controller in the proper configuration for the RK3588-Jaguar. But
when we don't boot from SD card, U-Boot needs to set it up correctly to
allow accessing SD cards in that configuration.
Therefore, let's disable the JTAG mode for the SDMMC pins so that the SD
controller can be used either as a fallback mechanism to find U-Boot
proper when the boot medium used to load TPL/SPL cannot find U-Boot
proper, or to be used in U-Boot CLI.
Note that soc_con[0] is reserved. But considering that it's way more
user-friendly to access soc_con1 from the TRM with soc_con[1] than
soc_con[0], and that soc_con0 would actually be located at 4 bytes
before soc_con1, let's just make soc_con0 part of the soc_con array.
[00]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c9b75d51c940c25587a2ad72ec7ec60490abfb6c
[01]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/rockchip/grf.c
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
arch/arm/include/asm/arch-rockchip/grf_rk3588.h | 24
arch/arm/mach-rockchip/rk3588/rk3588.c | 7 +++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
index e0694068bb1..f0ecff97f0b 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
@@ -32,4 +32,28 @@ struct rk3588_pmu1grf {
check_member(rk3588_pmu1grf, sd_detect_cnt, 0x03b0);
+#define SYS_GRF_BASE 0xfd58c000
+
+struct rk3588_sysgrf {
+ unsigned int wdt_con0;
+ unsigned int reserved0[(0x0010 - 0x) / 4 - 1];
+ unsigned int uart_con[2];
+ unsigned int reserved1[(0x00c0 - 0x0014) / 4 - 1];
+ unsigned int gic_con0;
+ unsigned int reserved2[(0x0200 - 0x00c0) / 4 - 1];
+ unsigned int memcfg_con[32];
+ unsigned int reserved3[(0x0300 - 0x027c) / 4 - 1];
+ /* soc_con0 is reserved */
+ unsigned int soc_con[14];
+ unsigned int reserved4[(0x0380 - 0x0334) / 4 - 1];
+ unsigned int soc_status[4];
+ unsigned int reserved5[(0x0500 - 0x038c) / 4 - 1];
+ unsigned int otp_key08;
+ unsigned int otp_key0d;
+ unsigned int otp_key0e;
+ unsigned int reserved6[(0x0600 - 0x0508) / 4 - 1];
+ unsigned int chip_id;
+};
+
+check_member(rk3588_sysgrf, chip_id, 0x0600);
#endif /*__SOC_ROCKCHIP_RK3588_GRF_H__ */
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index 38e95a6e2b2..c5eeda9d751 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#define FIREWALL_DDR_BASE 0xfe03
#define FW_DDR_MST5_REG0x54
@@ -35,6 +36,8 @@
#define BUS_IOC_GPIO2D_IOMUX_SEL_H 0x5c
#define BUS_IOC_GPIO3A_IOMUX_SEL_L 0x60
+#define SYS_GRF_FORCE_JTAG BIT(14)
+
/**
* Boot-device identifiers used by the BROM on RK3588 when device is booted
* from SPI flash. IOMUX used for SPI flash affect the value used by the BROM
@@ -134,6 +137,7 @@ void rockchip_stimer_init(void)
int arch_cpu_init(void)
{
#ifdef CONFIG_SPL_BUILD
+ static struct rk3588_sysgrf * const sys_grf = (void *)SYS_GRF_BASE;
int secure_reg;
/* Set the SDMMC eMMC crypto_ns FSPI access secure area */
@@ -168,6 +172,9 @@ int arch_cpu_init(void)
secure_reg = readl(FIREWALL_SYSMEM_BASE + FW_SYSM_MST27_REG);
secure_reg &= 0x;
writel(secure_reg, FIREWALL_SYSMEM_BASE + FW_SYSM_MST27_REG);
+
+ /* Disable JTAG exposed on SDMMC */
+ rk_clrreg(_grf->soc_con[6], SYS_GRF_FORCE_JTAG);
#endif
return 0;
--
2.43.0
