On 2/20/20 3:02 AM, Ang, Chee Hong wrote: [...] >>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) >>> +u32 socfpga_secure_reg_read32(phys_addr_t reg_addr); void >>> +socfpga_secure_reg_write32(u32 val, phys_addr_t reg_addr); void >>> +socfpga_secure_reg_update32(phys_addr_t reg_addr, u32 mask, u32 val); >>> +#else >>> +#define socfpga_secure_reg_read32 readl >>> +#define socfpga_secure_reg_write32 writel >>> +#define socfpga_secure_reg_update32 clrsetbits_le32 >>> +#endif >> >> I think I don't understand how this is supposed to work. Would every place >> in U- >> Boot have to be patched to call these functions now ? > > Not every register access need this. Only those accessing registers in secure > zone such > as 'System Manager' registers need to call this. It's basically determine > whether the driver > should issue SMC/PSCI call if it's running in EL2 (non-secure) or access the > registers directly > by simply using readl/writel and etc if it's running in EL3 (secure). > Accessing those registers in secure zone in non-secure mode (EL2) will cause > SError exception. > So we can determine this behaviour in compile time: > SPL always running in EL3. So it just simply fallback to use > readl/writel/clrsetbits_le32. > > For U-Boot proper (SSBL), there are 2 scenarios: > 1) If CONFIG_SPL_ATF is defined, it means ATF is supported. It implies that > U-Boot proper will be > running in EL2 (non-secure), then it will use SMC/PSCI calls to access the > secure registers. > > 2) CONFIG_SPL_ATF is not defined, no ATF support. U-Boot proper will be > running in EL3 which > will fall back to simply using the direct access functions (readl/writel and > etc).
I would expect the standard IO accessors would or should handle this stuff ?
