Re: [U-Boot] [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
On Sat, Dec 29, 2018 at 11:10:36PM +0100, Olliver Schinagl wrote:
> Luckily we have had no problem with this on our boards, but its sad to see
> this patch reverted due to the buggy ddr implementation ...
>
> Curiosity is getting the better of me and I cant seem to be able to reproduce
> the problem. So could you be a little bit more specific on the bug please?
It broke on some H2+ devices.
Just tested this also on H3 Orange Pi PC Plus and here it works fine.
>
> On December 29, 2018 7:53:49 PM GMT+01:00, Jagan Teki
> wrote:
> >On Wed, Dec 19, 2018 at 6:32 PM Andre Przywara
> >wrote:
> >>
> >> From: "From: Karl Palsson"
> >>
> >> Commit a8011eb84dfa("sunxi: board: Print error after power
> >initialization
> >> fails") moved the DRAM init after the increase of the CPU clock
> >> frequency. This lead to various DRAM initialisation failures on some
> >> boards (hangs or wrong size reported, on a NanoPi Duo2 and OrangePi
> >> Zero, for instance). Lowering the CPU frequency significantly (for
> >instance
> >> to 408 MHz) seems to work around the problem, so this points to some
> >timing
> >> issues in the DRAM code.
> >>
> >> Debugging this sounds like a larger job, so let's just revert this
> >patch
> >> to bring back those boards.
> >> Beside this probably unintended change the patch just moved the error
> >> message around, so reverting this is not a real loss.
> >
> >Better mark this as TODO somewhere, may be some one look it later.
> >
> >>
> >> This reverts commit a8011eb84dfac5187cebf00ed8bc981bdb5c1fa1.
> >>
> >> Tested-By: Priit Laes
> >> Signed-off-by: Karl Palsson
> >> Signed-off-by: Andre Przywara
> >
> >Applied to u-boot-sunxi/master
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] misc: fs_loader: Add support for initializing MMC
From: Tien Fong Chee
Firmware loader would encounter problem if the MMC is accessed before
initializing it. This patch would adding the support of probing block
device and initializing MMC before the MMC is accessed by firmware loader.
Signed-off-by: Tien Fong Chee
---
Changes in v2:
- Initializing MMC through probing the blk device
---
drivers/misc/fs_loader.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
index 57a14a3..5858073 100644
--- a/drivers/misc/fs_loader.c
+++ b/drivers/misc/fs_loader.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -252,6 +253,38 @@ static int fs_loader_ofdata_to_platdata(struct udevice
*dev)
static int fs_loader_probe(struct udevice *dev)
{
+#if defined(CONFIG_DM_MMC) && defined(CONFIG_BLK)
+ int ret;
+ struct device_platdata *plat = dev->platdata;
+
+ ret = mmc_initialize(NULL);
+ if (ret) {
+ debug("MMC: could not initialize mmc. error: %d\n", ret);
+
+ return ret;
+ }
+
+ if (plat->phandlepart.phandle) {
+ ofnode node = ofnode_get_by_phandle(plat->phandlepart.phandle);
+
+ struct udevice *mmc_dev = NULL;
+
+ ret = device_get_global_by_ofnode(node, _dev);
+ if (!ret) {
+ struct mmc *mmc = mmc_get_mmc_dev(mmc_dev);
+ struct udevice *dev;
+
+ ret = blk_get_from_parent(mmc->dev, );
+ if (ret) {
+ debug("MMC: No block device: %d\n",
+ ret);
+
+ return ret;
+ }
+ }
+ }
+#endif
+
return 0;
};
--
2.2.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add support for initializing MMC
On Sun, 2018-12-30 at 00:28 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> Firmware loader would encounter problem if the MMC is accessed before
> initializing it. This patch would adding the support of probing block
> device and initializing MMC before the MMC is accessed by firmware
> loader.
>
> Signed-off-by: Tien Fong Chee
>
> ---
> Changes in v2:
> - Initializing MMC through probing the blk device
Please ignore this patch, just realized missing a line status checking
code. I would resend another patch.
> ---
> drivers/misc/fs_loader.c | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index 57a14a3..d981b5a 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> DECLARE_GLOBAL_DATA_PTR;
> @@ -252,6 +253,37 @@ static int fs_loader_ofdata_to_platdata(struct
> udevice *dev)
>
> static int fs_loader_probe(struct udevice *dev)
> {
> +#if defined(CONFIG_DM_MMC) && defined(CONFIG_BLK)
> + int ret;
> + struct device_platdata *plat = dev->platdata;
> +
> + ret = mmc_initialize(NULL);
> + if (ret) {
> + debug("MMC: could not initialize mmc. error: %d\n",
> ret);
> +
> + return ret;
> + }
> +
> + if (plat->phandlepart.phandle) {
> + ofnode node = ofnode_get_by_phandle(plat-
> >phandlepart.phandle);
> +
> + struct udevice *mmc_dev = NULL;
> +
> + ret = device_get_global_by_ofnode(node, _dev);
> + if (!ret) {
> + struct mmc *mmc = mmc_get_mmc_dev(mmc_dev);
> + struct udevice *dev;
> +
> + if (blk_get_from_parent(mmc->dev, ))
> + {
> + debug("MMC: No block device: %d\n",
> + ret);
> +
> + return ret;
> + }
> + }
> + }
> +#endif
> return 0;
> };
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx8mq_evk_defconfig: Move file system options to Kconfig
Hi Fabio, Joris Offouga Le 29 déc. 2018 à 05:58, Peng Fan a écrit : >> -Original Message- >> From: Fabio Estevam [mailto:feste...@gmail.com] >> Sent: 2018年12月28日 3:14 >> To: sba...@denx.de >> Cc: dl-uboot-imx ; u-boot@lists.denx.de; >> spence...@gmail.com; Fabio Estevam >> Subject: [PATCH] imx8mq_evk_defconfig: Move file system options to Kconfig >> >> Chris Spencer reports that when enabling ext4 read support without also >> enabling write support the following error is seen: >> >> fs/fs.c:198:12: error: 'ext4_write_file' undeclared here (not in a >> function); did >> you mean 'ext4_read_file'? >> .write = ext4_write_file, >>^~~ >> Fix this problem by moving these options to Kconfig. >> >> Reported-by: Chris Spencer >> Signed-off-by: Fabio Estevam > > Acked-by: Peng Fan > >> --- >> configs/imx8mq_evk_defconfig | 5 + >> include/configs/imx8mq_evk.h | 6 -- >> 2 files changed, 5 insertions(+), 6 deletions(-) >> >> diff --git a/configs/imx8mq_evk_defconfig b/configs/imx8mq_evk_defconfig >> index f216d46a8f..b473fcd61b 100644 >> --- a/configs/imx8mq_evk_defconfig >> +++ b/configs/imx8mq_evk_defconfig >> @@ -15,6 +15,11 @@ CONFIG_SPL_LOAD_FIT=y CONFIG_SPL=y >> CONFIG_SPL_BOARD_INIT=y CONFIG_HUSH_PARSER=y >> +CONFIG_DOS_PARTITION=y >> +CONFIG_CMD_EXT2=y >> +CONFIG_CMD_EXT4=y >> +CONFIG_CMD_EXT4_WRITE=y >> +CONFIG_CMD_FAT= You forgot "y" to this line, correct this in CONFIG_CMD_FAT=y >> CONFIG_CMD_GPIO=y >> CONFIG_CMD_I2C=y >> CONFIG_CMD_CACHE=y >> diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h >> index 35f81152f2..f0430224cb 100644 >> --- a/include/configs/imx8mq_evk.h >> +++ b/include/configs/imx8mq_evk.h >> @@ -226,12 +226,6 @@ >> #define CONFIG_SYS_FSL_USDHC_NUM2 >> #define CONFIG_SYS_FSL_ESDHC_ADDR 0 >> >> -#define CONFIG_DOS_PARTITION >> -#define CONFIG_CMD_EXT2 >> -#define CONFIG_CMD_EXT4 >> -#define CONFIG_CMD_EXT4_WRITE >> -#define CONFIG_CMD_FAT >> - >> #define CONFIG_SUPPORT_EMMC_BOOT/* eMMC specific */ >> #define CONFIG_SYS_MMC_IMG_LOAD_PART1 >> >> -- >> 2.17.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
Luckily we have had no problem with this on our boards, but its sad to see this
patch reverted due to the buggy ddr implementation ...
Curiosity is getting the better of me and I cant seem to be able to reproduce
the problem. So could you be a little bit more specific on the bug please?
On December 29, 2018 7:53:49 PM GMT+01:00, Jagan Teki
wrote:
>On Wed, Dec 19, 2018 at 6:32 PM Andre Przywara
>wrote:
>>
>> From: "From: Karl Palsson"
>>
>> Commit a8011eb84dfa("sunxi: board: Print error after power
>initialization
>> fails") moved the DRAM init after the increase of the CPU clock
>> frequency. This lead to various DRAM initialisation failures on some
>> boards (hangs or wrong size reported, on a NanoPi Duo2 and OrangePi
>> Zero, for instance). Lowering the CPU frequency significantly (for
>instance
>> to 408 MHz) seems to work around the problem, so this points to some
>timing
>> issues in the DRAM code.
>>
>> Debugging this sounds like a larger job, so let's just revert this
>patch
>> to bring back those boards.
>> Beside this probably unintended change the patch just moved the error
>> message around, so reverting this is not a real loss.
>
>Better mark this as TODO somewhere, may be some one look it later.
>
>>
>> This reverts commit a8011eb84dfac5187cebf00ed8bc981bdb5c1fa1.
>>
>> Tested-By: Priit Laes
>> Signed-off-by: Karl Palsson
>> Signed-off-by: Andre Przywara
>
>Applied to u-boot-sunxi/master
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Add NFC register definitions for Allwinner A20 SoC
On Wed, Dec 26, 2018 at 4:49 PM Nikolai Zhubr wrote: > > And while at it, why not finally add the DT register definitions for > Allwinner A20 NFC. I'm certainly not the author of these, and they have > been around for many years already. Its quite unlikely they will > suddenly change, or vary between different A20-based devices. The A20 > SoC is gradually becoming obsolete, so why wait any more. Note: one > whould typically need to also add NFC node definition on top of this in > order to actually use it. > > Signed-off-by: Nikolai Zhubr > --- > arch/arm/dts/sun7i-a20.dtsi | 69 dts(i) changes need to be synced from Linux,we don't encourage to add them explicitly. Better sync from Linux if required. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Hynix H27UBG8T2BTR id
29.12.2018 21:51, Jagan Teki: On Wed, Dec 26, 2018 at 4:20 PM Nikolai Zhubr wrote: Add Hynix H27UBG8T2BTR nand chip identification. These chips are sometimes present in e.g. older A20-olinuxino-micro boards. So the older boards were broken these releases? Those with H27UBG8T2BTR chip -- yes: ECC init failed: -22 failed to init nand chips Thank you, Regards, Nikolai ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SPL variant of sunxi nand module
Hi, Its just to remind sunxi_nand_spl.c is still broken. (And probably has been for a couple releases or so). I'm unable to fix it myself (other than reverting the mentioned commit locally.) Thank you, Regards, Nikolai 24.12.2018 0:47, Nikolai Zhubr: Hi again, The following commit (titled "use PIO instead of DMA") apparently broke actual reading of nand pages in SPL at least for A20: http://git.denx.de/?p=u-boot.git;a=commit;h=6ddbb1e936c78cdef1e7395039fa7020c5c75326 Instead of reading page contents, non-dma (current) version just feeds zeroes here. Tested on A20-olinuxino-micro with a Hynix 4GB nand chip. It'd be nice to somehow fix it back eventually :) Other than that, nand boot seems usable (with added necessary chip id). Thank you, Regards, Nikolai ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
On Wed, Dec 19, 2018 at 6:32 PM Andre Przywara wrote:
>
> From: "From: Karl Palsson"
>
> Commit a8011eb84dfa("sunxi: board: Print error after power initialization
> fails") moved the DRAM init after the increase of the CPU clock
> frequency. This lead to various DRAM initialisation failures on some
> boards (hangs or wrong size reported, on a NanoPi Duo2 and OrangePi
> Zero, for instance). Lowering the CPU frequency significantly (for instance
> to 408 MHz) seems to work around the problem, so this points to some timing
> issues in the DRAM code.
>
> Debugging this sounds like a larger job, so let's just revert this patch
> to bring back those boards.
> Beside this probably unintended change the patch just moved the error
> message around, so reverting this is not a real loss.
Better mark this as TODO somewhere, may be some one look it later.
>
> This reverts commit a8011eb84dfac5187cebf00ed8bc981bdb5c1fa1.
>
> Tested-By: Priit Laes
> Signed-off-by: Karl Palsson
> Signed-off-by: Andre Przywara
Applied to u-boot-sunxi/master
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Hynix H27UBG8T2BTR id
On Wed, Dec 26, 2018 at 4:20 PM Nikolai Zhubr wrote: > > Add Hynix H27UBG8T2BTR nand chip identification. > These chips are sometimes present in e.g. older A20-olinuxino-micro boards. So the older boards were broken these releases? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki wrote:
>
> On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot wrote:
> >
>
> Better to have proper commit head that tells the real issue.
>
> > Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget
> > devices")
> >
> > The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared
> > even for platforms that do not enable DM_USB_GADGET. Otherwise the driver
> > for their usb peripheral controller fails to bind.
>
> Sorry this is unclear, you are trying to skip DM_USB_GADGET code even
> though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Any response on this?
We need the fix asap since the release is about a week.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now
Simon, As an alternative, you can turn this off by setting CONFIG_BOOT_MODE_REG=0 in your defconfig. We’ve done the same for our RK3399-Q7 module: configs/puma-rk3399_defconfig:CONFIG_ROCKCHIP_BOOT_MODE_REG=0x0 If this works for you, we can avoid removing this feature this late in the cycle and defeature/remove it in the next release, unless moved into a DTS-controlled driver. Thanks, Philipp. > On 29.12.2018, at 18:57, Philipp Tomsich > wrote: > > > >> On 29.12.2018, at 14:16, Simon Glass wrote: >> >> This function causes a 5-second delay and stops the display working on >> minnie. This code should be in a driver and should only be enabled by >> a device-tree property, so that it does not affect devices which do not >> have this feature. >> >> Signed-off-by: Simon Glass > > Reviewed-by: Philipp Tomsich > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now
> On 29.12.2018, at 14:16, Simon Glass wrote: > > This function causes a 5-second delay and stops the display working on > minnie. This code should be in a driver and should only be enabled by > a device-tree property, so that it does not affect devices which do not > have this feature. > > Signed-off-by: Simon Glass Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] Add support for initializing MMC
From: Tien Fong Chee
Firmware loader would encounter problem if the MMC is accessed before
initializing it. This patch would adding the support of probing block
device and initializing MMC before the MMC is accessed by firmware loader.
Signed-off-by: Tien Fong Chee
---
Changes in v2:
- Initializing MMC through probing the blk device
---
drivers/misc/fs_loader.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
index 57a14a3..d981b5a 100644
--- a/drivers/misc/fs_loader.c
+++ b/drivers/misc/fs_loader.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -252,6 +253,37 @@ static int fs_loader_ofdata_to_platdata(struct udevice
*dev)
static int fs_loader_probe(struct udevice *dev)
{
+#if defined(CONFIG_DM_MMC) && defined(CONFIG_BLK)
+ int ret;
+ struct device_platdata *plat = dev->platdata;
+
+ ret = mmc_initialize(NULL);
+ if (ret) {
+ debug("MMC: could not initialize mmc. error: %d\n", ret);
+
+ return ret;
+ }
+
+ if (plat->phandlepart.phandle) {
+ ofnode node = ofnode_get_by_phandle(plat->phandlepart.phandle);
+
+ struct udevice *mmc_dev = NULL;
+
+ ret = device_get_global_by_ofnode(node, _dev);
+ if (!ret) {
+ struct mmc *mmc = mmc_get_mmc_dev(mmc_dev);
+ struct udevice *dev;
+
+ if (blk_get_from_parent(mmc->dev, ))
+ {
+ debug("MMC: No block device: %d\n",
+ ret);
+
+ return ret;
+ }
+ }
+ }
+#endif
return 0;
};
--
2.2.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] tools: mkimage: Add missing names for imx8mimage and loadables
On Fri, 21 Dec 2018 at 18:36, Andre Przywara wrote: > > At the moment "mkimage -T list" starts with two unknown entries, because > their IH_TYPE_ name is not listed in the uimage_type table. > > Add those two entries to get an OCD-compatible image type listing. > > Signed-off-by: Andre Przywara > --- > common/image.c | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Simon Glass Would be good to have some tests for mkimage ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] fs: cbfs: Fix out of bound access during CBFS walking through
On Sat, 22 Dec 2018 at 02:50, Bin Meng wrote: > > The call to file_cbfs_fill_cache() is given with the parameter > 'start' pointing to the offset by the CBFS base address, but > with the parameter 'size' that equals to the whole CBFS size. > During CBFS walking through, it checks files one by one and > after it pass over the end of the CBFS which is 4GiB boundary > it tries to check files from address 0 and so on, until the > overall size the codes checked hits to the given 'size'. > > Fix this by passing 'start' pointing to the CBFS base address. > > Signed-off-by: Bin Meng > --- > > fs/cbfs/cbfs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] fs: cbfs: Make all CBFS_TYPE_xxx macros consistent
On Sat, 22 Dec 2018 at 02:50, Bin Meng wrote: > > At present there are 2 macros that are named as CBFS_COMPONENT_xxx. > Change them to CBFS_TYPE_xxx for consistency. > > Signed-off-by: Bin Meng > --- > > cmd/cbfs.c | 4 ++-- > include/cbfs.h | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] fs: cbfs: Add missing standard CBFS component types
On Sat, 22 Dec 2018 at 02:50, Bin Meng wrote: > > Current CBFS component type list is incomplete. Add missing ones. > > Signed-off-by: Bin Meng > --- > > cmd/cbfs.c | 30 ++ > include/cbfs.h | 10 ++ > 2 files changed, 40 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] tools: mkimage: Add Allwinner eGON support
On Fri, 21 Dec 2018 at 18:36, Andre Przywara wrote: > > So far we used the separate mksunxiboot tool for generating a bootable > image for Allwinner SPLs, probably just for historical reasons. > > Use the mkimage framework to generate a so called eGON image the > Allwinner BROM expects. > The new image type is called "sunxi_egon", to differentiate it > from the (still to be implemented) secure boot TOC0 image. > > Signed-off-by: Andre Przywara > --- > common/image.c | 1 + > include/image.h| 1 + > tools/Makefile | 1 + > tools/sunxi_egon.c | 136 > + > 4 files changed, 139 insertions(+) > create mode 100644 tools/sunxi_egon.c Good idea. Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cmd: add exception command
Hi Heinrich, On Wed, 26 Dec 2018 at 09:20, Heinrich Schuchardt wrote: > > The 'exception' command allows to test exception handling. > > This implementation supports ARM, x86, RISC-V and the following exceptions: > * 'breakpoint' - prefetch abort exception (ARM 32bit only) > * 'unaligned' - data abort exception (ARM only) > * 'undefined' - undefined instruction exception > > Signed-off-by: Heinrich Schuchardt > --- > v2: > Split architecture specific code into separate files. > Provide include for common code. > Update MAINTAINERS file. > --- > MAINTAINERS | 3 +++ > cmd/Kconfig | 6 + > cmd/Makefile | 2 ++ > cmd/arm/Makefile | 7 + > cmd/arm/exception.c | 61 +++ > cmd/arm/exception64.c | 33 +++ > cmd/riscv/Makefile| 3 +++ > cmd/riscv/exception.c | 29 > cmd/x86/Makefile | 1 + > cmd/x86/exception.c | 29 > include/exception.h | 58 > 11 files changed, 232 insertions(+) > create mode 100644 cmd/arm/Makefile > create mode 100644 cmd/arm/exception.c > create mode 100644 cmd/arm/exception64.c > create mode 100644 cmd/riscv/Makefile > create mode 100644 cmd/riscv/exception.c > create mode 100644 cmd/x86/exception.c > create mode 100644 include/exception.h This needs something like Series-version: 2 (if you use patman) to set the version number in the header. Did you look at using a uclass and driver, like sysreset? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] sunxi: Use mkimage -T sunxi_egon for SPL boot image generation
On Fri, 21 Dec 2018 at 18:36, Andre Przywara wrote: > > Switch the SPL boot image generation from using mksunxiboot to the new > sunxi_egon format of mkimage. > > Verified to create identical results for all 144 Allwinner boards. > > Signed-off-by: Andre Przywara > --- > scripts/Makefile.spl | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] fs: cbfs: remove wrong header validation
On Sat, 22 Dec 2018 at 02:50, Bin Meng wrote: > > From: Christian Gmeiner > > cbfs_fileheader.len indicates the content size of the file in the > cbfs, and it has nothing to do with cbfs_fileheader.offset which > is the starting address of the file in the cbfs. > > Remove such check in file_cbfs_next_file(). Before this change > 'cbfsinit' failed with 'Bad CBFS file'. After this change all cbfs > commands are working as expected. > > Signed-off-by: Christian Gmeiner > [bmeng: keep the necessary header sanity check] > Signed-off-by: Bin Meng > > --- > > fs/cbfs/cbfs.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] include: configs: Add gunzip size for HiKey board
On Thu, 27 Dec 2018 at 06:34, Manivannan Sadhasivam wrote: > > From: Manivannan Sadhasivam > > Default 8MB gunzip size is not enough to load the release kernel, hence > fix 64MB size for uncompressing the kernel. > > Signed-off-by: Manivannan Sadhasivam > Reviewed-by: Simon Glass > --- > > Changes in v2: Added Simon's Reviewed-by tag. > > include/configs/hikey.h | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/8] dm: pinctrl: Add pinctrl_decode_pin_config_dm().
Hi Christoph, On Tue, 25 Dec 2018 at 14:49, Christoph Müllner wrote: > > On 12/20/18 10:16 PM, Simon Glass wrote: > > Hi Christoph, > > > > On Mon, 17 Dec 2018 at 06:30, Christoph Muellner > > wrote: > >> > >> pinctrl_decode_pin_config_dm() is basically a feature-equivalent > >> implementation of pinctrl_decode_pin_config(), which operates > >> on struct udevice devices and uses the dev_read_*() API. > > > > So is it possible to remove the old function and avoid the _dm suffix here? > > Seems like the right way to go for me. > But I don't have the option to test on devices, which > need this function (RK3188 and RK3288) and I don't want > to risk touching drivers, which I cannot test outside > of the regular merge window. > > My plan was to do this early during the next merge window > (together with dropping the old RK3399 pinctrl driver and > the refactoring of the RK3399 pinctrl driver into a generic > RK pinctrl driver and a RK3399 mini-driver). > > Acceptable? Yes that's fine with me. Could you add a comment saying that this function is temporary for this release and will be removed in patches by February? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] rockchip: sound: Add support for sound on chromebook_jerry
Hi Philipp, On Fri, 28 Dec 2018 at 12:07, Philipp Tomsich wrote: > > > > > On 28.12.2018, at 04:15, Simon Glass wrote: > > > > Sound support for jerry was never included in the initial port. Now that > > sound has been converted to driver model it seems like a good opportunity > > to fill this gap. Jerry uses an audio codec that is already supported by > > U-Boot. > > > > Add the required drivers and enable the config so that > > 'sound play 500 400' can be used to play a beep. Also enable logging for > > this board. > > I hope to find time to add support for the RK3399 (which has a sufficiently > closely related I2S controller)—and possibly even the RK3368—and for > the SGTL5000 codec that we have on the Haikou reference baseboard. Sounds good! Really interested to see how the API works out. I have been meaning to add support for kevin but have not got to it. - Simon > > If you don’t hear anything by mid-January, feel free to poke me. > Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] power: regulator: Return success on attempt to disable an always-on regulator
Hi Lokesh,
On Thu, 27 Dec 2018 at 22:33, Lokesh Vutla wrote:
>
> Hi Simon,
>
> On 28/12/18 3:57 AM, Simon Glass wrote:
> > Hi Lokesh,
> >
> > On Mon, 24 Dec 2018 at 04:08, Lokesh Vutla wrote:
> >>
> >> commit 4f86a724e82c0 ("power: regulator: denied disable on always-on
> >> regulator") throws an error when requested to disable an always-on
> >> regulator. It is right that an always-on regulator should not be
> >> attempted to be disabled. But at the same time regulator framework
> >> should not return an error when such request is received. Instead
> >> it should just return success without attempting to disable the
> >> specified regulator. This is because the requesting driver will
> >> not have the idea if the regulator is always-on or not. The
> >> requesting driver will always try to enable/disable regulator as
> >> per the required flow. So it is upto regulator framework to not
> >> break such scenarios.
> >
> > Can the caller not check the error code? It is -EACCES in this case.
>
> We considered this an one of the option but I ended up fixing regulator
> framework due to the following reasons:
> - If regulator framework returns -EACCES on this scenario then:
> - -EACCES should be checked in all the existing usage of the api[1]
> or else
> someone else might encounter the same problem.
Yes. Some already check for -ENOSYS, e.g. omap_hsmmc.c
> - Any future usage of the api should take of handling this error.
Yes, and it should be commented too.
> - From a client driver perspective it is not really an error. It is
> doing the
> right thing and receiving an error might be confusing.
The error means that the request was not handled. There is no way to
find out that requesting this was actually wrong.
>
> Hope this is clear. Also just to add one more point, I adapted this error
> handling from Linux kernel[2].
The only question for me whether anything would need to detect that
the request to disable a regulator is not supported.
Your linux link appears to lead me to regulator_ena_gpio_ctrl(),
related to regulator GPIOs. Is that right? It's hard for me to
understand what the code there is doing.
Once we make this change we will not be able to go back without breaking things.
I am not really convinced that this patch is the best approach. I do
understand your point though. It just worries me that we are hiding
something and it will be hard to unhide it later.
What do you think about adding something like
regulator_disable_if_allowed() which silently ignored -ENOSYS and
-EACCES?
Thanks for the detailed response.
Regards,
Simon
>
> [1] ➜ u-boot git:(master) git grep -in "regulator_set_enable(.*, false)"
> cmd/regulator.c:410:ret = regulator_set_enable(dev, false);
> drivers/mmc/mmc.c:2552: int ret = regulator_set_enable(mmc->vmmc_supply,
> false);
> drivers/mmc/omap_hsmmc.c:473: ret = regulator_set_enable(priv->pbias_supply,
> false);
> drivers/mmc/omap_hsmmc.c:478: ret = regulator_set_enable(mmc->vqmmc_supply,
> false);
> drivers/net/fec_mxc.c:1414: regulator_set_enable(priv->phy_supply, false);
> drivers/phy/meson-gxl-usb2.c:174: int ret =
> regulator_set_enable(priv->phy_supply, false);
> drivers/phy/phy-rcar-gen3.c:101:return
> regulator_set_enable(priv->vbus_supply, false);
> drivers/phy/phy-stm32-usbphyc.c:251:ret =
> regulator_set_enable(usbphyc_phy->vdda1v1, false);
> drivers/phy/phy-stm32-usbphyc.c:257:ret =
> regulator_set_enable(usbphyc_phy->vdda1v8, false);
> drivers/phy/phy-stm32-usbphyc.c:263:ret =
> regulator_set_enable(usbphyc_phy->vdd, false);
> drivers/usb/host/dwc2.c:199:ret =
> regulator_set_enable(priv->vbus_supply, false);
> drivers/usb/host/ehci-generic.c:60: return
> regulator_set_enable(priv->vbus_supply, false);
> drivers/usb/host/xhci-rockchip.c:161: ret =
> regulator_set_enable(plat->vbus_supply, false);
> drivers/video/pwm_backlight.c:160: ret =
> regulator_set_enable(priv->reg, false);
> test/dm/adc.c:74: ut_assertok(regulator_set_enable(supply, false));
>
> [2] [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/core.c#n2333
>
> Thanks and regards,
> Lokesh
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] rockchip: sdram-common: fix wrong size for 4GB in 32bit SoC
On Thu, 27 Dec 2018 at 18:57, Kever Yang wrote: > > This is workaround for issue we can't get correct size for 4GB ram > in 32bit system and available before we really need ram space > out of 4GB, eg.enable ARM LAPE(rk3288 supports 8GB ram). > The size of 4GB is '0x1 ', and this value will be truncated > to 0 in 32bit system, and system can not get correct ram size. > Rockchip SoCs reserve a blob of space for peripheral near 4GB, > and we are now setting SDRAM_MAX_SIZE as max available space for > ram in 4GB, so we can use this directly to workaround the issue. > > Signed-off-by: Kever Yang > --- > > Changes in v2: > - update the commit message and comment to show this is a workaround. > > arch/arm/mach-rockchip/sdram_common.c | 18 ++ > 1 file changed, 18 insertions(+) Reviewed-by: Simon Glass Tested on chromebook_minnie: Tested-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] rockchip: chromebook_minnie: Enable sound
Enable sound for this board, which has the same codec as jerry.
Signed-off-by: Simon Glass
---
arch/arm/dts/rk3288-veyron-minnie.dts | 12
configs/chromebook_minnie_defconfig | 5 +
2 files changed, 17 insertions(+)
diff --git a/arch/arm/dts/rk3288-veyron-minnie.dts
b/arch/arm/dts/rk3288-veyron-minnie.dts
index 0a2915fba09..646f6ae7424 100644
--- a/arch/arm/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/dts/rk3288-veyron-minnie.dts
@@ -85,6 +85,18 @@
regulator-boot-on;
vin-supply = <_wl>;
};
+
+ sound {
+ compatible = "rockchip,audio-max98090-jerry";
+
+ cpu {
+ sound-dai = < 0>;
+ };
+
+ codec {
+ sound-dai = < 0>;
+ };
+ };
};
{
diff --git a/configs/chromebook_minnie_defconfig
b/configs/chromebook_minnie_defconfig
index b0428740736..93e40c02101 100644
--- a/configs/chromebook_minnie_defconfig
+++ b/configs/chromebook_minnie_defconfig
@@ -31,6 +31,7 @@ CONFIG_CMD_USB=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIME=y
+CONFIG_CMD_SOUND=y
CONFIG_CMD_PMIC=y
CONFIG_CMD_REGULATOR=y
# CONFIG_SPL_DOS_PARTITION is not set
@@ -75,6 +76,10 @@ CONFIG_RAM=y
CONFIG_SPL_RAM=y
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_ROCKCHIP_SERIAL=y
+CONFIG_SOUND=y
+CONFIG_I2S=y
+CONFIG_I2S_ROCKCHIP=y
+CONFIG_SOUND_MAX98090=y
CONFIG_ROCKCHIP_SPI=y
CONFIG_SYSRESET=y
CONFIG_USB=y
--
2.20.1.415.g653613c723-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now
This function causes a 5-second delay and stops the display working on
minnie. This code should be in a driver and should only be enabled by
a device-tree property, so that it does not affect devices which do not
have this feature.
Signed-off-by: Simon Glass
---
arch/arm/mach-rockchip/boot_mode.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/boot_mode.c
b/arch/arm/mach-rockchip/boot_mode.c
index f32b3c4ce56..d7997d71e30 100644
--- a/arch/arm/mach-rockchip/boot_mode.c
+++ b/arch/arm/mach-rockchip/boot_mode.c
@@ -61,7 +61,13 @@ int setup_boot_mode(void)
void *reg = (void *)CONFIG_ROCKCHIP_BOOT_MODE_REG;
int boot_mode = readl(reg);
- rockchip_dnl_mode_check();
+ /*
+* This should be handled using a driver-tree property and a suitable
+* driver which can read the appropriate settings. As it is, this
+* breaks chromebook_minnie.\
+*
+* rockchip_dnl_mode_check();
+*/
boot_mode = readl(reg);
debug("%s: boot mode 0x%08x\n", __func__, boot_mode);
--
2.20.1.415.g653613c723-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx8mq_evk_defconfig: Move file system options to Kconfig
Hi Joris, On Sat, Dec 29, 2018 at 3:59 AM Offouga Joris wrote: > You forgot "y" to this line, correct this in CONFIG_CMD_FAT=y Thanks! I have just sent a corrected v2. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] imx8mq_evk_defconfig: Move file system options to Kconfig
Chris Spencer reports that when enabling ext4 read support without also enabling write support the following error is seen: fs/fs.c:198:12: error: 'ext4_write_file' undeclared here (not in a function); did you mean 'ext4_read_file'? .write = ext4_write_file, ^~~ Fix this problem by moving these options to Kconfig. Reported-by: Chris Spencer Acked-by: Peng Fan Signed-off-by: Fabio Estevam --- Changes since v1: - Added missing y to CONFIG_CMD_FAT configs/imx8mq_evk_defconfig | 5 + include/configs/imx8mq_evk.h | 6 -- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/configs/imx8mq_evk_defconfig b/configs/imx8mq_evk_defconfig index f216d46a8f..b473fcd61b 100644 --- a/configs/imx8mq_evk_defconfig +++ b/configs/imx8mq_evk_defconfig @@ -15,6 +15,11 @@ CONFIG_SPL_LOAD_FIT=y CONFIG_SPL=y CONFIG_SPL_BOARD_INIT=y CONFIG_HUSH_PARSER=y +CONFIG_DOS_PARTITION=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_CACHE=y diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h index 35f81152f2..f0430224cb 100644 --- a/include/configs/imx8mq_evk.h +++ b/include/configs/imx8mq_evk.h @@ -226,12 +226,6 @@ #define CONFIG_SYS_FSL_USDHC_NUM 2 #define CONFIG_SYS_FSL_ESDHC_ADDR 0 -#define CONFIG_DOS_PARTITION -#define CONFIG_CMD_EXT2 -#define CONFIG_CMD_EXT4 -#define CONFIG_CMD_EXT4_WRITE -#define CONFIG_CMD_FAT - #define CONFIG_SUPPORT_EMMC_BOOT /* eMMC specific */ #define CONFIG_SYS_MMC_IMG_LOAD_PART 1 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: soft_spi: Fix null ptr when probing soft_spi.
Am Mi., 19. Dez. 2018 um 15:10 Uhr schrieb Horatiu Vultur : > > When probing soft_spi the result of dev_get_parent_priv(dev) in probe > function is null ptr because the spi is on the ahb bus which has > per_child_auto_alloc_size set to 0. Therefore it would generate an Ooops > messages when accessing spi_slave structure. > > The fix consist of delaying the read of dm_spi_slave_platdata until a > child under the spi is probed, to be able to read SPI mode. Therefore > implement .child_pre_probe in which updates soft_spi_platdata based on > child dm_spi_slave_platdata. > > Signed-off-by: Horatiu Vultur > --- > drivers/spi/soft_spi.c | 24 +--- > 1 file changed, 17 insertions(+), 7 deletions(-) > Reviewed-by: Daniel Schwierzeck ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] mips: mscc_sgpio: Add the MSCC serial GPIO device (SIO)
Am Do., 27. Dez. 2018 um 12:51 Uhr schrieb Lars Povlsen
:
>
> This add support for the the MSCC serial GPIO driver in MSCC
> VCoreIII-based SOCs.
>
> By using a serial interface, the SIO controller significantly extends
> the number of available GPIOs with a minimum number of additional pins
> on the device. The primary purpose of the SIO controller is to connect
> control signals from SFP modules and to act as an LED controller.
>
> This adds the base driver.
>
> Signed-off-by: Lars Povlsen
> ---
> MAINTAINERS | 1 +
> drivers/gpio/Kconfig | 11 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/mscc_sgpio.c | 274 ++
> 4 files changed, 287 insertions(+)
> create mode 100644 drivers/gpio/mscc_sgpio.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ae825014bd..494962e9b3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -523,6 +523,7 @@ F: arch/mips/dts/mscc*
> F: arch/mips/dts/ocelot*
> F: board/mscc/
> F: configs/mscc*
> +F: drivers/gpio/mscc_sgpio.c
> F: include/configs/vcoreiii.h
>
> MIPS JZ4780
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index c8c6c60623..aa55ff43c4 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -106,6 +106,17 @@ config MSCC_BITBANG_SPI_GPIO
> Support controlling the GPIO used for SPI bitbang by software. Can
> be used by the VCoreIII SoCs, but it was mainly useful for Luton.
>
> +config MSCC_SGPIO
> + bool "Microsemi Serial GPIO driver"
> + depends on DM_GPIO && SOC_VCOREIII
> + help
> + Support for the VCoreIII SoC serial GPIO device. By using a
> + serial interface, the SIO controller significantly extends
> + the number of available GPIOs with a minimum number of
> + additional pins on the device. The primary purpose of the
> + SIO controller is to connect control signals from SFP
> + modules and to act as an LED controller.
> +
> config MSM_GPIO
> bool "Qualcomm GPIO driver"
> depends on DM_GPIO
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 61feda1537..be2b3c792f 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -60,3 +60,4 @@ obj-$(CONFIG_$(SPL_)PCF8575_GPIO) += pcf8575_gpio.o
> obj-$(CONFIG_PM8916_GPIO) += pm8916_gpio.o
> obj-$(CONFIG_MT7621_GPIO) += mt7621_gpio.o
> obj-$(CONFIG_MSCC_BITBANG_SPI_GPIO)+= gpio-mscc-bitbang-spi.o
> +obj-$(CONFIG_MSCC_SGPIO) += mscc_sgpio.o
> diff --git a/drivers/gpio/mscc_sgpio.c b/drivers/gpio/mscc_sgpio.c
> new file mode 100644
> index 00..134d36066c
> --- /dev/null
> +++ b/drivers/gpio/mscc_sgpio.c
> @@ -0,0 +1,274 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Microsemi SoCs serial gpio driver
> + *
> + * Author:
> + *
> + * Copyright (c) 2018 Microsemi Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MSCC_SGPIOS_PER_BANK 32
> +#define MSCC_SGPIO_BANK_DEPTH 4
> +
> +enum {
> + REG_INPUT_DATA,
> + REG_PORT_CONFIG,
> + REG_PORT_ENABLE,
> + REG_SIO_CONFIG,
> + REG_SIO_CLOCK,
> + MAXREG
> +};
> +
> +struct mscc_sgpio_bf {
> + u8 beg;
> + u8 end;
> +};
> +
> +struct mscc_sgpio_props {
> + u8 regoff[MAXREG];
> + struct mscc_sgpio_bf auto_repeat;
> + struct mscc_sgpio_bf port_width;
> + struct mscc_sgpio_bf clk_freq;
> + struct mscc_sgpio_bf bit_source;
> +};
> +
> +#define __M(bf)GENMASK((bf).end, (bf).beg)
> +#define __F(bf, x) (__M(bf) & ((x) << (bf).beg))
> +#define __X(bf, x) (((x) >> (bf).beg) & GENMASK(((bf).end - (bf).beg),
> 0))
> +
> +#define MSCC_M_CFG_SIO_AUTO_REPEAT(p) BIT(p->props->auto_repeat.beg)
> +#define MSCC_F_CFG_SIO_PORT_WIDTH(p, x)
> __F(p->props->port_width, x)
> +#define MSCC_M_CFG_SIO_PORT_WIDTH(p) __M(p->props->port_width)
> +#define MSCC_F_CLOCK_SIO_CLK_FREQ(p, x)
> __F(p->props->clk_freq, x)
> +#define MSCC_M_CLOCK_SIO_CLK_FREQ(p) __M(p->props->clk_freq)
> +#define MSCC_F_PORT_CFG_BIT_SOURCE(p, x) __F(p->props->bit_source, x)
> +#define MSCC_X_PORT_CFG_BIT_SOURCE(p, x) __X(p->props->bit_source, x)
> +
> +const struct mscc_sgpio_props props_luton = {
> + .regoff = { 0x00, 0x09, 0x29, 0x2a, 0x2b },
> + .auto_repeat = { 5, 5 },
> + .port_width = { 2, 3 },
> + .clk_freq= { 0, 11 },
> + .bit_source = { 0, 11 },
> +};
> +
> +const struct mscc_sgpio_props props_ocelot = {
> + .regoff = { 0x00, 0x06, 0x26, 0x04, 0x05 },
> + .auto_repeat = { 10, 10 },
> + .port_width = { 7, 8 },
> + .clk_freq= { 8, 19 },
> + .bit_source = { 12, 23 },
> +};
> +
> +struct mscc_sgpio_priv {
> + u32 bitcount;
> + u32 ports;
> + u32 clock;
> + u32 mode[MSCC_SGPIOS_PER_BANK];
> +
[U-Boot] Re : Re: please pull u-boot-samsung master
Hi,
- Minkyu Kang a écrit :
> Dear Guillaume GARDET,
>
> On 28/12/18 00:41, Tom Rini wrote:
> > On Thu, Dec 27, 2018 at 12:49:53PM +0900, Minkyu Kang wrote:
> >
> >> Dear Tom,
> >>
> >> The following changes since commit
> >> 1f2e948d6d53f77a2ddb2dde3531b0d5bc2815ad:
> >>
> >> Prepare v2019.01-rc2 (2018-12-17 20:25:24 -0500)
> >>
> >> are available in the git repository at:
> >>
> >> git://git.denx.de/u-boot-samsung master
> >>
> >> for you to fetch changes up to c96d90367a6a229210b8b16681cfe9e5c8aeced1:
> >>
> >> exynos: imply SYS_THUMB_BUILD (2018-12-26 11:57:48 +0900)
> >>
> >>
> >> Anand Moon (2):
> >> exynos5-dt-types: add missing dtb file for Odroid HC1/HC2
> >> odroid: Update README.odroid for support of Odroid HC1
> >>
> >> Guillaume GARDET (1):
> >> exynos: imply SYS_THUMB_BUILD
> >>
> >> Seung-Woo Kim (1):
> >> Revert "arm: config: fix default console only to specify the device"
> >>
> >> arch/arm/Kconfig| 1 +
> >> doc/README.odroid | 7 +--
> >> include/configs/odroid.h| 4 ++--
> >> include/configs/odroid_xu3.h| 5 +++--
> >> include/configs/s5p_goni.h | 4 ++--
> >> include/configs/s5pc210_universal.h | 4 ++--
> >> include/configs/trats.h | 4 ++--
> >> include/configs/trats2.h| 4 ++--
> >> 8 files changed, 19 insertions(+), 14 deletions(-)
> >
> > NAK:
> > 18: Merge branch 'master' of git://git.denx.de/u-boot-samsung
> >arm: + peach-pi smdk5420 peach-pit
> > +(peach-pi,smdk5420,peach-pit) {standard input}: Assembler messages:
> > +(peach-pi,smdk5420,peach-pit) {standard input}:117: Error: Thumb encoding
> > does not support an immediate here -- `msr cpsr_c,#0x13|0xC0'
> > +(peach-pi,smdk5420,peach-pit) {standard input}:325: Error: Thumb encoding
> > does not support an immediate here -- `msr cpsr_c,#0x13|0xC0'
> > +(peach-pi,smdk5420,peach-pit) make[3]: *** [../scripts/Makefile.build:279:
> > spl/arch/arm/mach-exynos/lowlevel_init.o] Error 1
> > +(peach-pi,smdk5420,peach-pit) make[2]: *** [../scripts/Makefile.spl:383:
> > spl/arch/arm/mach-exynos] Error 2
> > +(peach-pi,smdk5420,peach-pit) make[1]: *** [Makefile:1597: spl/u-boot-spl]
> > Error 2
> > +(peach-pi,smdk5420,peach-pit) make: *** [Makefile:148: sub-make] Error 2
> >
>
> Because of this, thumb build feature cannot applied.
> Do you have an idea?
We should disable thumb explicitly for this board.
I will not be in front of a computer for the next days, so please wait until
2nd of January, or you can do it, if you want.
Thanks,
Guillaume
>
> Thanks,
> Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
