Reprogrammed the board here using my patch (
https://github.com/kratsg/meta-l1calo/commit/2ddfbfa7a1d6c2a11c3035e3b0e504be793352fc)
and u-boot still hangs at the MMC line. Is there something I missed?
Giordon
On Sat, Nov 18, 2017 at 12:26 PM Giordon Stark wrote:
> After a bit
After a bit of hunting down, I did the modifications using the devtool
helper and wrote my procedure down since I couldn't find a good guide
online (
https://github.com/kratsg/meta-l1calo/wiki/Creating-a-patch-for-an-existing-recipe-source-file
)
Thanks!
Giordon
On Sat, Nov 18, 2017 at 11:36 AM
That said, I found the config here:
https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/xilinx_zynqmp_zcu102.h#L13
and
just need to generate a bbappends that's only applied for a specific
machine.
Giordon
On Sat, Nov 18, 2017 at 11:16 AM Giordon Stark wrote:
>
I'm also unable to run `bitbake -c menuconfig "virtual/bootloader". I think
I run into a similar error as this SO post (
https://stackoverflow.com/questions/43211384/how-to-get-to-menuconfig-for-u-boot-in-yocto-environment
)
ERROR: Task do_menuconfig does not exist for target virtual/bootloader
(resending with right email, sorry for spam) Incredibly naive question
since I've been wondering about these things. Is it not possible to write
this as a patch or a .bbappends and put it in my meta layer (where?). I
assume the u-boot config is defined in meta-xilinx/classes or
meta-xilinx/conf as
Incredibly naive question since I've been wondering about these things. Is
it not possible to write this as a patch or a .bbappends and put it in my
meta layer (where?). I assume the u-boot config is defined in
meta-xilinx/classes or meta-xilinx/conf as Xilinx maintains their own fork
of u-boot I
Basically boils down to disabling SD support in u-boot.
In OE/Yocto, run "bitbake -c menuconfig virtual/bootloader" and remove
the MMC option (and whatever other options you like). Save the
configuration as /tmp/defconfig, and exit. Copy the defconfig to the
u-boot recipe location and add a
On 16 November 2017 at 11:12, Manjukumar Matha
wrote:
> After reworking the kmeta data based on kernel-cache merge, these
> configurations are not valid anymore. Delete the error causing kernel
> fargments.
>
> Signed-off-by: Manjukumar Matha