ces where I might
find additional help or similar cases?
Any guidance or suggestions would be greatly appreciated. Thank you in
advance for your assistance!
Best regards,
Mike
ces where I might
find additional help or similar cases?
Any guidance or suggestions would be greatly appreciated. Thank you in
advance for your assistance!
Best regards,
Mike
When an XXX_BOOTCOMMAND isn't defined, the result is that bootcmd is set
to some random memory content. Fix it so that the function does nothing
in that case and leaves the bootcmd environment unmodified.
Signed-off-by: Mike Looijmans
---
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 5 +++
bin"
- 0x0010-0x0200 : "qspi-rootfs"
So what are the "magic" words I need to pass to sqfsload to make it read
the flash device?
--
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl
other language-specific
distro tool out there (e.g. Python pip, Perl cpan, Go, etc...).
maybe you'd like more guarantees on top (e.g. signature verification)
which is reasonable.
but to be clear, this script is already merged & in the tree, so your
feedback doesn't block this patch.
-mike
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
-mike
Looks fine to me,
Acked-by: Mike Looijmans
(PS: Sorry for top-posting, but otherwise our M$ mailserver will mangle it)
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E
clude/configs/rpi.h fixes the problem. Let me know if you need any
additional information.
Thanks,
Mike
--- rpi.h.orig 2021-10-25 23:02:36.92852 -0500
+++ rpi.h 2021-10-25 16:05:16.140924000 -0500
@@ -173,7 +173,8 @@
#if CONFIG_IS_ENABLED(CMD_MMC)
#d
ns.
Fixes: 1025bd098aa8 "xilinx: zynqmp: Add support for saving variables"
Signed-off-by: Mike Looijmans
---
board/xilinx/zynq/board.c| 6 +++---
board/xilinx/zynqmp/zynqmp.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/board/xilinx/zynq/board.c b/board/xilin
Booting using the fdt blob at 0x2eff4100
Using Device Tree in place at 2eff4100, end 2f002fed
Starting kernel ...
Is this a U-Boot problem? I hope I provided enough information and this
helps the U-Boot project.
Best regards,
Mike (Miviho)
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com
Please consider the environment before printing this e-mail
On
flash
that this controller cannot read front to end in 10 seconds in a reasonable
configuration (i.e. a speed of 100MHz or more).
Signed-off-by: Mike Looijmans
---
drivers/spi/zynqmp_gqspi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/zynqmp_gqspi.c b/dr
SPL boot is slow on the ZynqMP because of this delay. The initialization done
in psu_init no longer requires an external delay, so this can be removed to
speed up the SPL boot flow considerably.
Signed-off-by: Mike Looijmans
---
board/xilinx/zynqmp/zynqmp.c | 4
1 file changed, 4 deletions
have different supplies. Xilinx' tech
support reported this undocumented register to be the cause, and
this patch applies a fix for all boards by programming the correct
value.
Signed-off-by: Mike Looijmans
---
board/xilinx/zynqmp/zynqmp.c | 6 ++
1 file changed, 6 insertions(+)
diff --g
On 04-04-19 09:56, Michal Simek wrote:
> On 04. 04. 19 9:52, Luca Ceresoli wrote:
>> Hi Mike, Michal,
>>
>> On 04/04/19 08:49, Michal Simek wrote:
>> [...]
>>>>>>>>> +#ifdef ZYNQMP_LOAD_PM_CFG_OBJ
>>>>&g
On 03-04-19 23:18, Luca Ceresoli wrote:
> Hi Mike,
>
> On 03/04/19 13:24, Mike Looijmans wrote:
>> On 29-03-19 13:22, Luca Ceresoli wrote:
>>> Hi Michal,
>>>
>>> thanks for the feedback.
>>>
>>> On 27/03/19 16:03, Michal Simek wrote:
>
On 29-03-19 13:22, Luca Ceresoli wrote:
> Hi Michal,
>
> thanks for the feedback.
>
> On 27/03/19 16:03, Michal Simek wrote:
>> On 21. 03. 19 16:48, Luca Ceresoli wrote:
>>> Optionally allow U-Boot to load at the PMU firmware configuration object
>>> into the Power Management Unit (PMU) on Xilinx
It would even be better to adopt the Linux kernel way of storing MAC address
through nvmem. That works for basically any board - and you get rid of the
vendor prefix. Any nvmem provider can store the data, not just I2C eeproms. It
reduces the total code size since all gem drivers can call the sa
CADENCE=y
>> CONFIG_MMC_SDHCI=y
>> CONFIG_MMC_SDHCI_ZYNQ=y
>> CONFIG_SPI_FLASH=y
>> diff --git a/configs/topic_miamiplus_defconfig
>> b/configs/topic_miamiplus_defconfig
>> index d820fff501d1..f742838d7c1f 100644
>> --- a/configs/topic_miamiplus_defconfig
>>
On 07-09-18 11:30, Michal Simek wrote:
> On 24.8.2018 14:00, Mike Looijmans wrote:
>> To reduce board cost, the topic-miamilite board hardware was adapted. It now
>> only has single QSPI NOR flash and a single DDR RAM chip. This reduces the
>> memory interface to 16-bit and
The miamiplus contains a speedgrade-2 device, which may run the CPU at 800MHz.
Change the PLL setting to 800MHz, and adapt the setpoints in the devicetree.
Signed-off-by: Mike Looijmans
---
arch/arm/dts/zynq-topic-miamiplus.dts| 9 +
board/topic/zynq/zynq-topic-miamiplus
Patches rebased for re-submission, were sent earlier as part of a longer
series.
This improves performance and functionality for the topic-miamiplus
boards with Zynq 7035/7045/7100.
Mike Looijmans (2):
topic-miamiplus: Run CPU at 800MHz for speedgrade-2
board: topic-miamiplus: Run IO PLL at
The miamiplus can use GEM0 through MIO pins, which requires a 125 MHz TX
clock to be generated. With the IO PLL at 1200 MHz this isn't possible, so
change it to run at 1000 and adjust the divisors accordingly. Also set the
GEM0 clock source to MIO instead of EMIO.
Signed-off-by: Mike Looi
d resort to zlib or gzip. But these libraries are not built by
>> default.
>
> Yeah, and that only adds to more overhead.
>
>> Most urgently we will need the capitalization table for generating and
>> checking short FAT filenames, so we could create a configuration switc
The miamiplus can use GEM0 through MIO pins, which requires a 125 MHz TX
clock to be generated. With the IO PLL at 1200 MHz this isn't possible, so
change it to run at 1000 and adjust the divisors accordingly. Also set the
GEM0 clock source to MIO instead of EMIO.
Signed-off-by: Mike Looi
To reduce board cost, the topic-miamilite board hardware was adapted. It now
only has single QSPI NOR flash and a single DDR RAM chip. This reduces the
memory interface to 16-bit and halves the available RAM and flash.
Signed-off-by: Mike Looijmans
---
arch/arm/dts/zynq-topic-miamilite.dts
The miamiplus contains a speedgrade-2 device, which may run the CPU at 800MHz.
Change the PLL setting to 800MHz, and adapt the setpoints in the devicetree.
Signed-off-by: Mike Looijmans
---
arch/arm/dts/zynq-topic-miamiplus.dts| 9 +
board/topic/zynq/zynq-topic-miamiplus
Use the same partitioning as the SD card by default. This allows to
insert an SD card into a USB reader or use an USB drive with the same
partitioning and boot using that instead of requiring a ramdisk image.
Signed-off-by: Mike Looijmans
---
include/configs/topic_miami.h | 12 ++--
1
be great if they could be
included there as well.
Mike Looijmans (4):
topic-miamiplus: Run CPU at 800MHz for speedgrade-2
board: topic_miamilite: Support cost-reduced version
configs/topic_miami.h: Use same partitioning for USB boot as for SD
board: topic-miamiplus: Run IO PLL at 1000 MHz
On 16-03-18 16:56, David Lechner wrote:
On 03/16/2018 01:26 AM, Mike Looijmans wrote:
On 15-03-18 02:36, David Lechner wrote:
commit 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
changed the PLL0 frequency to 456MHz, which is needed for the LCDC IP
block. However
850_PLL0_PLLM 37
+/* Requires CONFIG_SYS_DA850_PLL0_POSTDIV=0, set in Kconfig */
+#define CONFIG_SYS_DA850_PLL0_PLLM 18
#define CONFIG_SYS_DA850_PLL1_PLLM 21
/*
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0
ility to change your MAC address at will.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the
delete mode 100644 board/xilinx/zynq/zynq-zed/ps7_init_gpl.h
delete mode 100644 board/xilinx/zynq/zynq-zybo/ps7_init_gpl.h
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike
Hi,
u-boot 2016.05/09/11 & 2017.x hangs on reboot with sunxi-next on my Allwinner
A20 olimex-micro-emmc.
All looks good and stable but on reboot u-boot hangs. I can't figure out why.
U-boot 2016.03 works.
Has anybody some ideas?
___
U-Boot mailing li
2017 - 08:12:07)
DR
The version u-boot-v2016.03 reboots fine and always.
Any ideas or hints?
Thx Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
The miamiplus contains a speedgrade-2 device, which may run the CPU at 800MHz.
Change the PLL setting to 800MHz, and adapt the setpoints in the devicetree.
Signed-off-by: Mike Looijmans
---
arch/arm/dts/zynq-topic-miamiplus.dts| 9 +
board/topic/zynq/zynq-topic-miamiplus
Move the only use of CONFIG_SF_DUAL_FLASH to defconfig. This makes the
associated topic_miamiplus.h header obsolete, so remove that as well.
Signed-off-by: Mike Looijmans
---
README| 6 --
configs/topic_miamiplus_defconfig | 3 ++-
drivers/mtd/spi/Kconfig
These two patches add support for the topic-miamilite board.
v2: Rebased, no change
v3: Added missing Kconfig
v2: Moved CONFIG_SF_DUAL_FLASH to defconfig
v3: No change, resend as series
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.d
The topic-miamilite SoM contains a Zynq xc7z010 SoC, 1GB DDR3L RAM,
64MB dual-parallel QSPI NOR flash and clock sources.
Signed-off-by: Mike Looijmans
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/zynq-topic-miamilite.dts | 17 ++
.../topic/zynq/zynq
The topic-miamilite SoM contains a Zynq xc7z010 SoC, 1GB DDR3L RAM,
64MB dual-parallel QSPI NOR flash and clock sources.
Signed-off-by: Mike Looijmans
---
v2: Move CONFIG_SF_DUAL_FLASH to defconfig
arch/arm/dts/Makefile | 1 +
arch/arm/dts/zynq-topic
Move the only use of CONFIG_SF_DUAL_FLASH to defconfig. This makes the
associated topic_miamiplus.h header obsolete, so remove that as well.
Signed-off-by: Mike Looijmans
---
configs/topic_miamiplus_defconfig | 3 ++-
include/configs/topic_miamiplus.h | 2 --
scripts/config_whitelist.txt
On 29-05-17 17:34, Michal Simek wrote:
On 29.5.2017 15:41, Mike Looijmans wrote:
The topic-miamilite SoM contains a Zynq xc7z010 SoC, 1GB DDR3L RAM,
64MB dual-parallel QSPI NOR flash and clock sources.
Signed-off-by: Mike Looijmans
---
arch/arm/dts/Makefile
The topic-miamilite SoM contains a Zynq xc7z010 SoC, 1GB DDR3L RAM,
64MB dual-parallel QSPI NOR flash and clock sources.
Signed-off-by: Mike Looijmans
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/zynq-topic-miamilite.dts | 17 ++
.../topic/zynq/zynq
Fixes the following problem:
zynq-uboot> run dfu_ram
Setting bus to 1
g_dnl_register: failed!, error: -19
The cause appears to be that the USB framework is looking for a usbotg aliases,
so add the alias to point to our USB device.
Signed-off-by: Mike Looijmans
---
arch/arm/dts/zynq-to
On Thursday, March 9, 2017 at 12:36:31 AM UTC+1, Jernej Škrabec wrote:
>
> Designware HDMI controller and phy are used in other SoCs as well. Split
> out platform independent code.
>
> DW HDMI has 8 bit registers but they can be represented as 32 bit
> registers as well. Add support to select
____
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.denx.de%2Fmailman%2Flistinfo%2Fu-boot&data=01%7C01%7Cmike.caraman%40nxp.com%7C5b4875265c7348d80f7a08d449aea415%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=Pqm0QAUf%2Bizcqz%2FzzZjHMELGZjrWLuK0xbPI%2FcNNwiA%3D&reserved=0
-Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
diff --git a/include/configs/ls2080a_common.h
> b/include/configs/ls2080a_common.h
> index 7aef43f..e120f6e 100644
> --- a/include/configs/ls2080a_common.h
> +++ b/include/configs/ls2080a_common.h
> @@ -13,7 +13,7 @@
> #define CONFIG_GICV3
> #define CONFIG_FSL_TZPC_BP147
>
> -#include
> +#include
> #include
>
> /* Link Definitions */
> --
> 1.9.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.denx.de%2Fmailman%2Flistinfo%2Fu-boot&data=01%7C01%7Cmike.caraman%40nxp.com%7Cfafbac9ba11c430b306a08d449ae8aeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=MuOAnhSTP9PjNCCG%2BjbTunzD4ap%2BR0xJnhViMYhYWn8%3D&reserved=0
>
-Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Allow sending firmware to RAM. Without this, the DFU support was not
of much use.
Signed-off-by: Mike Looijmans
---
configs/topic_miami_defconfig | 1 +
configs/topic_miamiplus_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/configs/topic_miami_defconfig b/configs
On the miami board, ethernet is accessed via logic. To use it, one
would have to program logic first and then set up the rgmii conversion
block as well. Not likely to ever be used, so disable network support
by default to save some space.
---
configs/topic_miami_defconfig | 5 +++--
1 file changed
On 17-01-17 15:15, Michal Simek wrote:
Hi,
On 17.1.2017 09:54, Mike Looijmans wrote:
Three patches to fix these issues:
- Network support in u-boot is only useful on the topic-miamiplus board
- DFU boot does not work, missing DFU_RAM config
- QSPI boot did not work because of wrong
The kernel partition in QSPI is 0x44 large, not 0x40. Fix this
in the environment, otherwise the kernel will fail to boot if it occupies
more space.
Signed-off-by: Mike Looijmans
---
include/configs/topic_miami.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Three patches to fix these issues:
- Network support in u-boot is only useful on the topic-miamiplus board
- DFU boot does not work, missing DFU_RAM config
- QSPI boot did not work because of wrong kernel_size environment
v2: Rebased on current master
Mike Looijmans (3):
topic_miami_defconfig
Allow sending firmware to RAM. Without this, the DFU support was not
of much use.
Signed-off-by: Mike Looijmans
---
configs/topic_miami_defconfig | 1 +
configs/topic_miamiplus_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/configs/topic_miami_defconfig b/configs
On the miami board, ethernet is accessed via logic. To use it, one
would have to program logic first and then set up the rgmii conversion
block as well. Not likely to ever be used, so disable network support
by default to save some space.
---
configs/topic_miami_defconfig | 5 +++--
1 file changed
The kernel partition in QSPI is 0x44 large, not 0x40. Fix this
in the environment, otherwise the kernel will fail to boot if it occupies
more space.
Signed-off-by: Mike Looijmans
---
include/configs/topic_miami.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Three patches to fix these issues:
- Network support in u-boot is only useful on the topic-miamiplus board
- DFU boot does not work, missing DFU_RAM config
- QSPI boot did not work because of wrong kernel_size environment
Mike Looijmans (3):
topic_miami_defconfig: Remove NFS and NET support
Ah, missed that. I noticed that "run $modeboot" didn't work for QSPI in the
2017.1 tag, hadn't seen that one yet.
On 13-01-17 14:18, Michal Simek wrote:
Hi,
On 13.1.2017 14:04, Mike Looijmans wrote:
The Zynq can also boot from QSPI or NAND, and environment scripting
The Zynq can also boot from QSPI or NAND, and environment scripting
uses "qspiboot" and "nandboot" already. Add these to the board init
routines so that modeboot is properly set to one of these values when
the mode bits indicate so.
Signed-off-by: Mike Looijmans
---
board
Add a string description for SYS_VENDOR to allow configuring boards from
other vendors than just "xilinx".
---
arch/arm/cpu/armv8/zynqmp/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig
b/arch/arm/cpu/armv8/zynqmp/Kconfig
index e175e6e..499e1dd 100644
+ printf(" Programming %s bitstream... OK", name);
break;
default:
printf("The given image format is not supported (corrupt?)\n");
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ
the kernel's
final devicetree. That includes changing pinmuxing and clocks and stuff, which
is easy to do.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@
On 12-12-16 08:46, Michal Simek wrote:
Hi Mike,
On 22.11.2016 12:00, Michal Simek wrote:
On 21.11.2016 09:30, Mike Looijmans wrote:
Miami boards can have memory sizes of 256M, 512M or 1GB. To prevent requiring
separate bootloaders for each variant, just detect the RAM size at boot time
nfig etc.
Thanks,
Michal
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment be
1043 don't need.
Do LS1043A boards still work with this feature on?
I have tested it on LS1046ARDB and LS1012ARDB.
The bottom of line is, if all existing and future boards work fine with
this feature, you don't need the condition macro. If some board/flash
cannot work without this fea
sing ECC on the Zynq platform, all the DDR
RAM must be written to before it's read, otherwise the system will cause
a bus error and hang. Without CONFIG_USE_ARCH_MEMSET it takes over 5
seconds to clear 256MB, enabling CONFIG_USE_ARCH_MEMSET reduces that time
to less than 3 seconds.
Signed-off-by:
On 22-11-16 12:00, Michal Simek wrote:
On 21.11.2016 09:30, Mike Looijmans wrote:
Miami boards can have memory sizes of 256M, 512M or 1GB. To prevent requiring
separate bootloaders for each variant, just detect the RAM size at boot time
instead of relying on the devicetree information.
Signed
On 21-11-16 10:04, Michal Simek wrote:
Hi Mike,
On 21.11.2016 09:30, Mike Looijmans wrote:
Miami boards can have memory sizes of 256M, 512M or 1GB. To prevent requiring
separate bootloaders for each variant, just detect the RAM size at boot time
instead of relying on the devicetree
Miami boards can have memory sizes of 256M, 512M or 1GB. To prevent requiring
separate bootloaders for each variant, just detect the RAM size at boot time
instead of relying on the devicetree information.
Signed-off-by: Mike Looijmans
---
board/topic/zynq/board.c | 39
On 17-11-16 13:34, Mike Looijmans wrote:
We have some Zynq based boards still in the field that have only 512MB RAM
instead of 1GB. The memory chips are compatible and use the same settings
apart from that one extra address bit.
So what works is just configure the DDR controller for 1GB and
he ram_size variable.
The problem I'm seeing now is that this new ram_size does not get passed to
the kernel. Apparently in modern versions of u-boot I need to somehow patch
the "live" devicetree blob as well? How does that work?
Kind regards,
Mike Looijmans
System Expert
TO
On 11-10-16 13:00, Dan Handley wrote:
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the
t; carrier boards add SD, USB, ethernet and other interfaces.
Signed-off-by: Mike Looijmans
---
Note: Requires these patches:
mach-zynq/Kconfig: Make SYS_VENDOR configurable
tools: mkimage: Add support for initialization table for Zynq and ZynqMP
arch/arm/dts/Makefile
Add a string description for SYS_VENDOR to allow configuring boards from
other vendors than just "xilinx".
Signed-off-by: Mike Looijmans
---
This patch is needed to support a set of Zynq and ZynqMP boards
arch/arm/mach-zynq/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
lines are simply skipped. The file can be passed to mkimage using the
"-R" parameter.
It is recommended to add reg init file to board folder.
For example:
CONFIG_BOOT_INIT_FILE="board/xilinx/zynqmp/xilinx_zynqmp_zcu102/reg.int
Signed-off-by: Mike Looijmans
Signed-off-by: Michal Sim
Add a string description for SYS_VENDOR to allow configuring boards from
other vendors than just "xilinx".
Signed-off-by: Mike Looijmans
---
arch/arm/mach-zynq/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
ind
On 22-09-16 11:25, Michal Simek wrote:
From: Mike Looijmans
The Zynq/ZynqMP boot.bin file contains a region for register initialization
data. Filling in proper values in this table can reduce boot time
(e.g. about 50ms faster on QSPI boot) and also reduce the size of
the SPL binary.
The
On 15-09-16 09:41, Mike Looijmans wrote:
On 15-09-16 08:54, Michal Simek wrote:
Hi Mike,
On 15.9.2016 08:02, Mike Looijmans wrote:
These patches add support for the Miami range of boards from TOPIC.
The boards are based on Xilinx Zynq SoCs, these two patches are for
the 7-series, the
On 15-09-16 08:54, Michal Simek wrote:
Hi Mike,
On 15.9.2016 08:02, Mike Looijmans wrote:
These patches add support for the Miami range of boards from TOPIC.
The boards are based on Xilinx Zynq SoCs, these two patches are for
the 7-series, the Ultrascale MPSOC boards are to be added later
On 15-09-16 09:41, Mike Looijmans wrote:
On 15-09-16 08:54, Michal Simek wrote:
Hi Mike,
On 15.9.2016 08:02, Mike Looijmans wrote:
These patches add support for the Miami range of boards from TOPIC.
The boards are based on Xilinx Zynq SoCs, these two patches are for
the 7-series, the
result of that, contain many style issues.
Mike Looijmans (2):
Add topic-miami board support
Add topic_miamiplus board
arch/arm/dts/Makefile |2 +
arch/arm/dts/zynq-topic-miami.dts | 98 +
arch/arm/dts/zynq-topic-miamiplus.dts
<<< image/jpeg: Unrecognized >>>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
<<< image/jpeg: Unrecognized >>>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
The devicetrees for various platforms already exceed 16k. Add a define
CONFIG_SYS_FDT_SIZE to specify the FDT size, and set to 16k for the
two boards that define this CONFIG_SYS_FDT_BASE parameter. This
allows platforms with larger devicetree blobs to boot from NOR.
Signed-off-by: Mike Looijmans
The devicetrees for various platforms already exceed 16k. Add a define
CONFIG_SYS_FDT_SIZE to specify the FDT size, and default to 16k. This
allows platforms with larger devicetree blobs to boot from NOR.
Signed-off-by: Mike Looijmans
---
common/spl/spl_nor.c | 9 +++--
1 file changed, 7
dicate that the UART Enable and Startup deals with pin
multiplexing, defaults, and clock selection. I'm wondering if that's
causing our issues. We're using 15200/n/8/1 for Linux and uBoot. I'm
using a vendor provided version of uBoot.
Thanks,
Mike
___
dicate that the UART Enable and Startup deals with pin
multiplexing, defaults, and clock selection. I'm wondering if that's
causing our issues. We're using 15200/n/8/1 for Linux and uBoot. I'm
using a vendor provided version of uBoot.
Thanks,
Mike
___
/s; which is completely counterintuitive.
Please let me know if I can be of any help, I would really like to get
to the bottom of this.
-Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Because it is possible for the MTD number to change, causing a
filesystem mount failure, we should use the volume name instead
of the MTD number and let Linux resolve the correct one.
Signed-off-by: Mike Scherban
---
Changes for v2:
-Use volume name rather than number
-Update
On Sunday, December 7, 2014 9:27:37 PM UTC+1, Hans de Goede wrote:
> Hi,
>
> This is still a bit rough around the edges, I'll clean it up as
> time permits and then post it upstream.
Hip, Hip Hooray. Thank you.
How did you pull it off? Did you find documentation somewhere? Or by piecing
things
Hi Simon,
Thanks and to Heiko also.
Mike
On 09/05/2014 11:54 PM, Simon Glass wrote:
Hi,
On 6 May 2014 00:38, Heiko Schocher wrote:
Hello Mike,
Am 05.05.2014 16:27, schrieb Mike Pearce:
Please help as I am confused.
I implemented verified boot on 2014.04 using CONFIG_OF_SEPARATE and it
then you
leave a security hole.
In my last email I also discussed my confusion regard the 'required'
variable. Similar argument to the above plus some other thoughts.
Thanks,
Mike.
On 05/08/2014 01:05 PM, Heiko Schocher wrote:
Disabling legacy image format is useful when using
CONFIG_OF_LIBFDT
#define CONFIG_CMD_HASH
#define CONFIG_HASH_VERIFY
#define CONFIG_FIT_SIGNATURE
#define CONFIG_RSA
Thanks,
Mike.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
nst string by hand.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
02:80:ad:20:31:e8 */
> -
> +#define CONFIG_LIB_RAND
this should be in bfin_adi_common.h instead. i think that replaces the
majority of your config updates (if not all).
-mike
signature.asc
Description: This is a digitally signed message part.
_
to relocate the adapter itself,
> > but at this time i2c_adap_p is already relocated.
>
> Which toolchain?
>
> > Can anybody confirm this?
>
> Added Mike Frysinger, Sonic Zhang (for blackfin) Jason Jin (for m68k)
> and Macpaul Lin (for nds32) to Cc ...
>
> >
est support on NDS32 architecture.
> > Kuan-Yu Kuo (a.k.a. Ken Kuo) will be the next custodian of u-boot-nds32
> > branch.
> >
> > Thanks for the great support and co-working guide from Wolfgang, Tom,
> > Po-Yu Chuang, Mike, Marek and many people.
>
On 07/01/2013 12:51 PM, Wolfgang Denk wrote:
> Dear Mike Dunn,
>
> In message <51d1c455.9010...@newsguy.com> you wrote:
>>
>> But there's a good motivation for wanting to turn off optimization.
>
> I disagree here. If you are hunting down a problem, you
turning off optimization.
But there's a good motivation for wanting to turn off optimization.
Single-stepping with a debugger at the C source level is almost useless. I've
since gotten better at single-stepping at the assembly level while using the
mixed c and assembly view of gdb.
Mike
Newer gcc versions warn about unused variables. This patch corrects a few of
those warnings that popped up in a build for the palmtreo680 board.
Signed-off-by: Mike Dunn
---
drivers/mtd/nand/docg4_spl.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a
Newer gcc versions warn about unused variables. This patch corrects a few of
those warnings that popped up in a build for the palmtreo680 board.
Signed-off-by: Mike Dunn
---
drivers/usb/gadget/pxa27x_udc.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a
1 - 100 of 4814 matches
Mail list logo
