From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by mx.groups.io with SMTP id smtpd.web12.22284.1591974678570023445 for ; Fri, 12 Jun 2020 08:11:18 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=nWNC8Kki; spf=pass (domain: nuviainc.com, ip: 209.85.128.66, mailfrom: leif@nuviainc.com) Received: by mail-wm1-f66.google.com with SMTP id y20so8633301wmi.2 for ; Fri, 12 Jun 2020 08:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EhaRomPZNs6k1FUAmldiqmWNf/NpCeovNPpc90Wu5Sg=; b=nWNC8Kki0q3F5D69DFXwQaki5v4RNssfvAaSoVnKS8qYh46uQeeWuY8rLdKr1BWPJV ZjuMqj+h0OEYtVxzDzl5+A7TVZ2VC3fYo0bUpLzURuWEvmloU4CghDt9o7T9fhPoKIbT uYdLwOQk+szwKdFEDApb31kYJJMQM4HU8a+hQD5Bz0sdv/ruILOewC+0xq2YsXaa+kls nYCk0aRYwU0rFUiFATj3x2Hbbhv4CBFJsfJL6iOZYyqRQIebBpMUAVCuF5dMMek+Y9F/ dVl+Rh0VSGzMxGezxs3+otLj8DWx5c2zyZoDT5JQdW8+0dkFlFg919bajsa3GPmwO1WQ bB3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=EhaRomPZNs6k1FUAmldiqmWNf/NpCeovNPpc90Wu5Sg=; b=X2BCnUqTyCHoRNFhIjaBsTs2BsDK+MTsK8PfNhVHF1vNdMpmTAquYJbCwjRMp1EnH9 2B31LHDmS2duLP7U05HIuDkK6acgxh2KJQky6gO03i0ihftrxddZVOwgrIt3VcAS7CqG DkHycT5/1mPT/7TevhNZe1O0Vkxe3h19mt1HqPOeJDVIoyc/4oVdByV+Qo8blREGuxCL r0ddgXJa8K0aR7ph2iR41PTAnsnSfpkTm0fKNw/pJDFbhYMTMU+QsbmNFbeqMWhUWVAE 4w+dj3ijTagBnB5lLd7Q4POkIxaH9cjZUqpPtCwMvlGC9ncGvH7z/JNHyEbHW0d6YcZA D1Ag== X-Gm-Message-State: AOAM533v723Mlz6266zLsP8XQZNrJrH7BUxsxCdNT4FEB8Z0gJxkvltf i4/4vvvZ0XEsizmY8kwRYlwObw== X-Google-Smtp-Source: ABdhPJyepmjOXElULi9LTjClQPC0iGyMWEaNwgdZINYZTliueW4bcD3A/0fGfXRmJPAS6XeE8fkr3Q== X-Received: by 2002:a1c:4b0f:: with SMTP id y15mr14681854wma.83.1591974677107; Fri, 12 Jun 2020 08:11:17 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id d24sm9097289wmb.45.2020.06.12.08.11.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2020 08:11:16 -0700 (PDT) Date: Fri, 12 Jun 2020 16:11:14 +0100 From: "Leif Lindholm" To: "Pankaj Bansal (OSS)" Cc: Meenakshi Aggarwal , Michael D Kinney , "devel@edk2.groups.io" , Varun Sethi , Samer El-Haj-Mahmoud , Augustine Philips , Ard Biesheuvel , Arokia Samy , kuldip dwivedi Subject: Re: [PATCH edk2-platforms 1/5] Silicon/NXP/LS1043A: Fix the Platform PLL calculation Message-ID: <20200612151114.GG28566@vanye> References: <20200602132503.27154-1-pankaj.bansal@oss.nxp.com> <20200602132503.27154-2-pankaj.bansal@oss.nxp.com> <20200605140028.GH28566@vanye> <20200608142224.GN28566@vanye> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Pankaj, Apologies for delay in responding, this message got lost from my inbox. On a sidenote, I think this has something to do with the email moderation. Could you possibly subscribe the @oss.nxp.com address to the list? You can set it not to deliver email, under https://edk2.groups.io/g/devel/editsub, but I can't whitelist addresses that are not subscribed. On Mon, Jun 08, 2020 at 19:56:35 +0000, Pankaj Bansal (OSS) wrote: > > > > OK, now I'm confused. > > > > DCFG is read using the DcfgRead32 function, which is supposed to > > > > handle the endianness issue. > > > > > > > > Ls1043a builds with > > > > gNxpQoriqLsTokenSpaceGuid.PcdDcfgBigEndian|TRUE > > > > which means GetMmioOperations() returns the byte-swapping versions. > > > > > > > > Please clarify. > > > > > > OK. so this might be little confusing, so bear with me. > > > The reset configuration word (RCW) is 512 bits (1024 bits in LS2088 > > > / LS2160) long and contains all necessary configuration information > > > for the chip. RCW data is read from external memory (Nor flash or > > > SD/eMMC card or I2c eeprom) and written to the RCW status registers > > > (RCWSR) contained in the Device Configuration and Pin Control module > > > (DCSR), after which the device is configured as specified in the > > > RCW. > > > > > > The PreBoot Loader (PBL) fetches RCW data from the source memory > > > device and writes it to the RCW status registers. > > > Now the PBL fetches the data from flash in little endian format and > > > writes it to the DCSR registers in little endian format always. > > > This steps is same for all SOCs (LX2160 / LS1043 / LS1046 / LS2088). > > > > This PBL is a ROM executing before the EDK2 code? > > Yes > > > > > > Now in SOCs where DCSR space is big endian (LS1043 / LS1046), we > > > read the RCWSR registers in big endian fashion. > > > This causes the bit position to be reversed. > > > > I'm still not following. > > > > We've set up this elaborate Rube Goldberg machine to be able to *not* > > have to carry separate header files for devices with individual > > components with registers that may be big- or little-endian depending > > on which SoC/version they are in. > > > > And now we have an implementation that states that its DcfgRead > > operations need to happan as big-endian. And the *only* time the Dcfg > > registers are accessed, we immediately need to change the header file > > to treat it as little-endian? > > The RCW Status registers are a special case and a subset of DCFG > address space. The whole DCFG address space is big endian itself, > and should be read as such. So the RCW status registers are in effect just temporary storage for data, as opposed to having any effect on the hw? Whereas other parts of DCFG *do* affect (and reflect) hw, and are big-endian? If so, ok, I understand. And I think your platform designers owe me (and you, if so inclined) a beer. > if it makes more sense, then I can swap the RCW status registers > after being read from DCFG space. > And I can put the explanation I wrote above in the code where I swap > RCW SR registers ? Yes, I think manually swapping the words make more sense. This is a *weird* thing - it helps to call it out explicitly rather than try to make it look normal. Please do that, and drop the .h change, and I'm happy with that. > > What is the situation where Dcfg accesses *need* to be big-endian? > > Apart from RCWSR registers the DCFG space contains following > registers as well, which we need to access in boot firmware: > > - SVR (SOC Version Register) > - to retrieve Core and Cluster Information (which I plan to send shortly) > - To set the ICID of DMA connected devices like USB, SATA, SD/EMMC > - to retrieve the clock frequency of serial flash controller (qspi/flexspi) Understood - thanks! / Leif