Skip to contentSkip to conversation

Breakage on gw_ventana

U-Boot Stefano Babic 3 participants 11 messages May 19, 2016 – May 20, 2016

lore
Share & tools
lore

Stefano Babic

author
#0 lore raw

Hi Tim,

last changes break build for the gw_ventana board. In fact, in case kernel is on a fs, we need to pass the name for kernel. These two defines should be set into gw_ventana.h:

CONFIG_SPL_FS_LOAD_KERNEL_NAME
CONFIG_SPL_FS_LOAD_ARGS_NAME

I could simply fix it, but it does not make sense without asking you :-)

I have also seen that SPL for gw_ventana raises an exception because SPL is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the mx6 with smaller SRAM has at least 128KB.

Best regards,
Stefano

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
#1 lore raw
Quoted 9 lines · Stefano Babic

Hi Tim,

last changes break build for the gw_ventana board. In fact, in case kernel is on a fs, we need to pass the name for kernel. These two defines should be set into gw_ventana.h:

CONFIG_SPL_FS_LOAD_KERNEL_NAME
CONFIG_SPL_FS_LOAD_ARGS_NAME

Quoted 7 lines

I could simply fix it, but it does not make sense without asking you :-)

I have also seen that SPL for gw_ventana raises an exception because SPL is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the mx6 with smaller SRAM has at least 128KB.

Stefano,

Thanks for the heads-up. I have to admit I haven't looked at mainline u-boot on Ventana for quite some time - I'm still using a 2015-04 branch with some patches on top that I haven't had time to mainline yet.

When you say 'last changes' was there something specific? Something must of grown the size of the SPL code quite a bit.

Your right that the smallest imx6 SRAM has 128KB although we have to be careful not to clobber the SRAM being used by the boot ROM. The reference manual indicates (IMX6*RM Figure 8-3) that there is only free area 68KB available after you carve out the 28KB reserved section, the 24KB MMU table, and the 8K stack. Admittedly I don't know if the BOOT rom code really uses all of these areas in such a way that it cant load the SPL into any of them. Take a look at my comments at the top of include/configs/imx6_spl.h and let me know if you find something wrong with my analysis that led to a 64KB max.

Regards,

Tim

author
#2 lore raw

Hi Tim,

Quoted 20 lines · Tim Harvey
Quoted 9 lines · Stefano Babic

Hi Tim,

last changes break build for the gw_ventana board. In fact, in case kernel is on a fs, we need to pass the name for kernel. These two defines should be set into gw_ventana.h:

CONFIG_SPL_FS_LOAD_KERNEL_NAME
CONFIG_SPL_FS_LOAD_ARGS_NAME

Quoted 7 lines

I could simply fix it, but it does not make sense without asking you :-)

I have also seen that SPL for gw_ventana raises an exception because SPL is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the mx6 with smaller SRAM has at least 128KB.

Stefano,

Quoted 7 lines

Thanks for the heads-up. I have to admit I haven't looked at mainline u-boot on Ventana for quite some time - I'm still using a 2015-04 branch with some patches on top that I haven't had time to mainline yet.

When you say 'last changes' was there something specific? Something must of grown the size of the SPL code quite a bit.

I think (but I am not sure) the biggest increase was done by allowing to load image directly from filesystem, and then the size increased.

But I admit I did not take a closer look before - it looks like that gw_ventana is the first to fail, just because it supports more methods for booting. Most boards boots just from one media,

Quoted 8 lines

Your right that the smallest imx6 SRAM has 128KB although we have to be careful not to clobber the SRAM being used by the boot ROM. The reference manual indicates (IMX6*RM Figure 8-3) that there is only free area 68KB available after you carve out the 28KB reserved section, the 24KB MMU table, and the 8K stack. Admittedly I don't know if the BOOT rom code really uses all of these areas in such a way that it cant load the SPL into any of them.

I do not know as well - maybe some NXP developers can tell something more.

Quoted 3 lines

Take a look at my comments at
the top of include/configs/imx6_spl.h and let me know if you find something wrong with my analysis that led to a 64KB max.

Nothing wrong, but as far as I know in start.S cache and muu are turned off, and they are turned on later again. This could let us to reuse maybe the 24KB space previously set by the Bootrom

Best regards,
Stefano

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
#3 lore raw
Quoted 31 lines · Stefano Babic

Hi Tim,

Quoted 20 lines · Tim Harvey
Quoted 9 lines · Stefano Babic

Hi Tim,

last changes break build for the gw_ventana board. In fact, in case kernel is on a fs, we need to pass the name for kernel. These two defines should be set into gw_ventana.h:

CONFIG_SPL_FS_LOAD_KERNEL_NAME
CONFIG_SPL_FS_LOAD_ARGS_NAME

Quoted 7 lines

I could simply fix it, but it does not make sense without asking you :-)

I have also seen that SPL for gw_ventana raises an exception because SPL is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the mx6 with smaller SRAM has at least 128KB.

Stefano,

Quoted 7 lines

Thanks for the heads-up. I have to admit I haven't looked at mainline u-boot on Ventana for quite some time - I'm still using a 2015-04 branch with some patches on top that I haven't had time to mainline yet.

When you say 'last changes' was there something specific? Something must of grown the size of the SPL code quite a bit.

Quoted 7 lines

I think (but I am not sure) the biggest increase was done by allowing to load image directly from filesystem, and then the size increased.

But I admit I did not take a closer look before - it looks like that gw_ventana is the first to fail, just because it supports more methods for booting. Most boards boots just from one media,

That makes sense.

Looking at my notes (again this is based on 2015.04) I found the following increases in SPL:

base+serial+i2c: 23K
+mmc: +12K
+nand: +8K
+gpio: +4K
+env: +12K (big!)
+fat: +4K
+ext: +8K
+fastboot: +4K

These numbers were with backported thumb binary support (without it they get much more inflated).

My SPL is at 63K currently but that is largely because I'm including nand+mmc and env (both env from nand and from mmc) with the help of a patch to allow either env that didn't get accepted upstream (because of the desire to re-write the env code for DM). I was after a single SPL that could handle a NAND or MMC boot device.

I don't include fs support simply because I didn't have the room so if that truly was added I can see how that through it over the edge.

I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to me that should be in the board config file(s) where needed and not in the general SPL config file, otherwise your adding support that some boards (like ventana!) don't have room for.

Quoted 11 lines
Quoted 8 lines

Your right that the smallest imx6 SRAM has 128KB although we have to be careful not to clobber the SRAM being used by the boot ROM. The reference manual indicates (IMX6*RM Figure 8-3) that there is only free area 68KB available after you carve out the 28KB reserved section, the 24KB MMU table, and the 8K stack. Admittedly I don't know if the BOOT rom code really uses all of these areas in such a way that it cant load the SPL into any of them.

I do not know as well - maybe some NXP developers can tell something more.

Quoted 7 lines
Quoted 3 lines

Take a look at my comments at
the top of include/configs/imx6_spl.h and let me know if you find something wrong with my analysis that led to a 64KB max.

Nothing wrong, but as far as I know in start.S cache and muu are turned off, and they are turned on later again. This could let us to reuse maybe the 24KB space previously set by the Bootrom

they may be turned off by the time we get to U-Boot SPL or within U-Boot SPL but the question is 'does the boot ROM need them?'. I suppose its not too difficult to test by artificially growing the SPL with random/zero'd data and letting it clobber the 24KB shown for the MMU table.

Tim

author
#4 lore raw

Hi Tim,

Quoted 63 lines · Tim Harvey
Quoted 31 lines · Stefano Babic

Hi Tim,

Quoted 20 lines · Tim Harvey
Quoted 9 lines · Stefano Babic

Hi Tim,

last changes break build for the gw_ventana board. In fact, in case kernel is on a fs, we need to pass the name for kernel. These two defines should be set into gw_ventana.h:

CONFIG_SPL_FS_LOAD_KERNEL_NAME
CONFIG_SPL_FS_LOAD_ARGS_NAME

Quoted 7 lines

I could simply fix it, but it does not make sense without asking you :-)

I have also seen that SPL for gw_ventana raises an exception because SPL is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the mx6 with smaller SRAM has at least 128KB.

Stefano,

Quoted 7 lines

Thanks for the heads-up. I have to admit I haven't looked at mainline u-boot on Ventana for quite some time - I'm still using a 2015-04 branch with some patches on top that I haven't had time to mainline yet.

When you say 'last changes' was there something specific? Something must of grown the size of the SPL code quite a bit.

Quoted 7 lines

I think (but I am not sure) the biggest increase was done by allowing to load image directly from filesystem, and then the size increased.

But I admit I did not take a closer look before - it looks like that gw_ventana is the first to fail, just because it supports more methods for booting. Most boards boots just from one media,

That makes sense.

Looking at my notes (again this is based on 2015.04) I found the following increases in SPL:

base+serial+i2c: 23K

(quoted diff) +7 -0
+mmc: +12K
+nand: +8K
+gpio: +4K
+env: +12K (big!)
+fat: +4K
+ext: +8K
+fastboot: +4K

These numbers were with backported thumb binary support (without it they get much more inflated).

My SPL is at 63K currently but that is largely because I'm including nand+mmc and env (both env from nand and from mmc) with the help of a patch to allow either env that didn't get accepted upstream (because of the desire to re-write the env code for DM). I was after a single SPL that could handle a NAND or MMC boot device.

Quoted 9 lines

I don't include fs support simply because I didn't have the room so if that truly was added I can see how that through it over the edge.

I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to me that should be in the board config file(s) where needed and not in the general SPL config file, otherwise your adding support that some boards (like ventana!) don't have room for.

Yes, agree - this should be splitted and moved to board config files.

Quoted 8 lines
Quoted 7 lines
Quoted 3 lines

Take a look at my comments at
the top of include/configs/imx6_spl.h and let me know if you find something wrong with my analysis that led to a 64KB max.

Nothing wrong, but as far as I know in start.S cache and muu are turned off, and they are turned on later again. This could let us to reuse maybe the 24KB space previously set by the Bootrom

Quoted 5 lines

they may be turned off by the time we get to U-Boot SPL or within U-Boot SPL but the question is 'does the boot ROM need them?'. I suppose its not too difficult to test by artificially growing the SPL with random/zero'd data and letting it clobber the 24KB shown for the MMU table.

Right - and it should be very nice to know what happens to the "reserved" area (0x900000 - 0x96FFFF). From some simple tests, it looks like that the Boot ROM does not use it - but it is marked as reserved in the manual, and for this reason it was never used, but I am now speculating if the space can be taken for our purposes.

Stefano

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
#5 lore raw
Quoted 92 lines · Stefano Babic

Hi Tim,

Quoted 63 lines · Tim Harvey
Quoted 31 lines · Stefano Babic

Hi Tim,

Quoted 20 lines · Tim Harvey
Quoted 9 lines · Stefano Babic

Hi Tim,

last changes break build for the gw_ventana board. In fact, in case kernel is on a fs, we need to pass the name for kernel. These two defines should be set into gw_ventana.h:

CONFIG_SPL_FS_LOAD_KERNEL_NAME
CONFIG_SPL_FS_LOAD_ARGS_NAME

Quoted 7 lines

I could simply fix it, but it does not make sense without asking you :-)

I have also seen that SPL for gw_ventana raises an exception because SPL is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the mx6 with smaller SRAM has at least 128KB.

Stefano,

Quoted 7 lines

Thanks for the heads-up. I have to admit I haven't looked at mainline u-boot on Ventana for quite some time - I'm still using a 2015-04 branch with some patches on top that I haven't had time to mainline yet.

When you say 'last changes' was there something specific? Something must of grown the size of the SPL code quite a bit.

Quoted 7 lines

I think (but I am not sure) the biggest increase was done by allowing to load image directly from filesystem, and then the size increased.

But I admit I did not take a closer look before - it looks like that gw_ventana is the first to fail, just because it supports more methods for booting. Most boards boots just from one media,

That makes sense.

Looking at my notes (again this is based on 2015.04) I found the following increases in SPL:

base+serial+i2c: 23K

(quoted diff) +7 -0
+mmc: +12K
+nand: +8K
+gpio: +4K
+env: +12K (big!)
+fat: +4K
+ext: +8K
+fastboot: +4K

These numbers were with backported thumb binary support (without it they get much more inflated).

My SPL is at 63K currently but that is largely because I'm including nand+mmc and env (both env from nand and from mmc) with the help of a patch to allow either env that didn't get accepted upstream (because of the desire to re-write the env code for DM). I was after a single SPL that could handle a NAND or MMC boot device.

Quoted 9 lines

I don't include fs support simply because I didn't have the room so if that truly was added I can see how that through it over the edge.

I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to me that should be in the board config file(s) where needed and not in the general SPL config file, otherwise your adding support that some boards (like ventana!) don't have room for.

Yes, agree - this should be splitted and moved to board config files.

Quoted 8 lines
Quoted 7 lines
Quoted 3 lines

Take a look at my comments at
the top of include/configs/imx6_spl.h and let me know if you find something wrong with my analysis that led to a 64KB max.

Nothing wrong, but as far as I know in start.S cache and muu are turned off, and they are turned on later again. This could let us to reuse maybe the 24KB space previously set by the Bootrom

Quoted 5 lines

they may be turned off by the time we get to U-Boot SPL or within U-Boot SPL but the question is 'does the boot ROM need them?'. I suppose its not too difficult to test by artificially growing the SPL with random/zero'd data and letting it clobber the 24KB shown for the MMU table.

Quoted 5 lines

Right - and it should be very nice to know what happens to the "reserved" area (0x900000 - 0x96FFFF). From some simple tests, it looks like that the Boot ROM does not use it - but it is marked as reserved in the manual, and for this reason it was never used, but I am now speculating if the space can be taken for our purposes.

It's it used during HAB ? It might be some area used by the crypto coprocessor or somesuch.

Signature · 2 lines
Best regards,
Marek Vasut
#6 lore raw
Quoted 70 lines · Marek Vasut
Quoted 69 lines · Stefano Babic

Hi Tim,

Quoted 66 lines · Tim Harvey
Quoted 31 lines · Stefano Babic

Hi Tim,

Quoted 20 lines · Tim Harvey
Quoted 9 lines · Stefano Babic

Hi Tim,

last changes break build for the gw_ventana board. In fact, in case kernel is on a fs, we need to pass the name for kernel. These two defines should be set into gw_ventana.h:

CONFIG_SPL_FS_LOAD_KERNEL_NAME
CONFIG_SPL_FS_LOAD_ARGS_NAME

Quoted 7 lines

I could simply fix it, but it does not make sense without asking you :-)

I have also seen that SPL for gw_ventana raises an exception because SPL is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the mx6 with smaller SRAM has at least 128KB.

Stefano,

Quoted 7 lines

Thanks for the heads-up. I have to admit I haven't looked at mainline u-boot on Ventana for quite some time - I'm still using a 2015-04 branch with some patches on top that I haven't had time to mainline yet.

When you say 'last changes' was there something specific? Something must of grown the size of the SPL code quite a bit.

Quoted 7 lines

I think (but I am not sure) the biggest increase was done by allowing to load image directly from filesystem, and then the size increased.

But I admit I did not take a closer look before - it looks like that gw_ventana is the first to fail, just because it supports more methods for booting. Most boards boots just from one media,

That makes sense.

Looking at my notes (again this is based on 2015.04) I found the following increases in SPL:

base+serial+i2c: 23K

(quoted diff) +7 -0
+mmc: +12K
+nand: +8K
+gpio: +4K
+env: +12K (big!)
+fat: +4K
+ext: +8K
+fastboot: +4K

These numbers were with backported thumb binary support (without it they get much more inflated).

My SPL is at 63K currently but that is largely because I'm including nand+mmc and env (both env from nand and from mmc) with the help of a patch to allow either env that didn't get accepted upstream (because of the desire to re-write the env code for DM). I was after a single SPL that could handle a NAND or MMC boot device.

I don't include fs support simply because I didn't have the room so if that truly was added I can see how that through it over the edge.

Quoted 8 lines
Quoted 8 lines
Quoted 6 lines

I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to me that should be in the board config file(s) where needed and not in the general SPL config file, otherwise your adding support that some boards (like ventana!) don't have room for.

Yes, agree - this should be splitted and moved to board config files.

Marek,

Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board config? It looks like the novena board was the only one using it and it breaks Ventana build.

Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
Quoted 8 lines
Quoted 4 lines

Take a look at my comments at
the top of include/configs/imx6_spl.h and let me know if you find something wrong with my analysis that led to a 64KB max.

Nothing wrong, but as far as I know in start.S cache and muu are turned off, and they are turned on later again. This could let us to reuse maybe the 24KB space previously set by the Bootrom

they may be turned off by the time we get to U-Boot SPL or within U-Boot SPL but the question is 'does the boot ROM need them?'. I suppose its not too difficult to test by artificially growing the SPL with random/zero'd data and letting it clobber the 24KB shown for the MMU table.

Quoted 8 lines
Quoted 5 lines

Right - and it should be very nice to know what happens to the "reserved" area (0x900000 - 0x96FFFF). From some simple tests, it looks like that the Boot ROM does not use it - but it is marked as reserved in the manual, and for this reason it was never used, but I am now speculating if the space can be taken for our purposes.

It's it used during HAB ? It might be some area used by the crypto coprocessor or somesuch.

That's a good question. Are you using HAB anywhere or anyone else we know of using SPL and HAB that can test setting CONFIG_SPL_TEXT_BASE to 0x00900000?

Regards,

Tim

#7 lore raw
Quoted 80 lines · Tim Harvey
Quoted 70 lines · Marek Vasut
Quoted 69 lines · Stefano Babic

Hi Tim,

Quoted 66 lines · Tim Harvey
Quoted 31 lines · Stefano Babic

Hi Tim,

Quoted 20 lines · Tim Harvey
Quoted 9 lines · Stefano Babic

Hi Tim,

last changes break build for the gw_ventana board. In fact, in case kernel is on a fs, we need to pass the name for kernel. These two defines should be set into gw_ventana.h:

CONFIG_SPL_FS_LOAD_KERNEL_NAME
CONFIG_SPL_FS_LOAD_ARGS_NAME

Quoted 7 lines

I could simply fix it, but it does not make sense without asking you :-)

I have also seen that SPL for gw_ventana raises an exception because SPL is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the mx6 with smaller SRAM has at least 128KB.

Stefano,

Quoted 7 lines

Thanks for the heads-up. I have to admit I haven't looked at mainline u-boot on Ventana for quite some time - I'm still using a 2015-04 branch with some patches on top that I haven't had time to mainline yet.

When you say 'last changes' was there something specific? Something must of grown the size of the SPL code quite a bit.

Quoted 7 lines

I think (but I am not sure) the biggest increase was done by allowing to load image directly from filesystem, and then the size increased.

But I admit I did not take a closer look before - it looks like that gw_ventana is the first to fail, just because it supports more methods for booting. Most boards boots just from one media,

That makes sense.

Looking at my notes (again this is based on 2015.04) I found the following increases in SPL:

base+serial+i2c: 23K

(quoted diff) +7 -0
+mmc: +12K
+nand: +8K
+gpio: +4K
+env: +12K (big!)
+fat: +4K
+ext: +8K
+fastboot: +4K

These numbers were with backported thumb binary support (without it they get much more inflated).

My SPL is at 63K currently but that is largely because I'm including nand+mmc and env (both env from nand and from mmc) with the help of a patch to allow either env that didn't get accepted upstream (because of the desire to re-write the env code for DM). I was after a single SPL that could handle a NAND or MMC boot device.

I don't include fs support simply because I didn't have the room so if that truly was added I can see how that through it over the edge.

Quoted 8 lines
Quoted 8 lines
Quoted 6 lines

I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to me that should be in the board config file(s) where needed and not in the general SPL config file, otherwise your adding support that some boards (like ventana!) don't have room for.

Yes, agree - this should be splitted and moved to board config files.

Quoted 6 lines

Marek,

Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board config? It looks like the novena board was the only one using it and it breaks Ventana build.

I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for ventana. If we have FS boot, we should push for filesystems which are not a patent minefield (like fat).

So what about adding this to ventana:
#undef CONFIG_SPL_EXT_SUPPORT

Quoted 21 lines
Quoted 21 lines
Quoted 20 lines
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines

Take a look at my comments at
the top of include/configs/imx6_spl.h and let me know if you find something wrong with my analysis that led to a 64KB max.

Nothing wrong, but as far as I know in start.S cache and muu are turned off, and they are turned on later again. This could let us to reuse maybe the 24KB space previously set by the Bootrom

Quoted 5 lines

they may be turned off by the time we get to U-Boot SPL or within U-Boot SPL but the question is 'does the boot ROM need them?'. I suppose its not too difficult to test by artificially growing the SPL with random/zero'd data and letting it clobber the 24KB shown for the MMU table.

Right - and it should be very nice to know what happens to the "reserved" area (0x900000 - 0x96FFFF). From some simple tests, it looks like that the Boot ROM does not use it - but it is marked as reserved in the manual, and for this reason it was never used, but I am now speculating if the space can be taken for our purposes.

Quoted 6 lines
Quoted 2 lines

It's it used during HAB ? It might be some area used by the crypto coprocessor or somesuch.

That's a good question. Are you using HAB anywhere or anyone else we know of using SPL and HAB that can test setting CONFIG_SPL_TEXT_BASE to 0x00900000?

I am not using HAB on mx6, I think there was only one user of it ever.

Quoted 4 lines

Regards,

Tim

Signature · 2 lines
Best regards,
Marek Vasut
author
#8 lore raw

Hi Marek, Tim,

Quoted 11 lines · Marek Vasut
Quoted 4 lines

Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board config? It looks like the novena board was the only one using it and it breaks Ventana build.

I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for ventana. If we have FS boot, we should push for filesystems which are not a patent minefield (like fat).

So what about adding this to ventana:
#undef CONFIG_SPL_EXT_SUPPORT

Agree. This makes sense. We set as common rules what most boards need, if that let us the way to disable for some boards. The way described by Marek does this.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

It's it used during HAB ? It might be some area used by the crypto coprocessor or somesuch.

That's a good question. Are you using HAB anywhere or anyone else we know of using SPL and HAB that can test setting CONFIG_SPL_TEXT_BASE to 0x00900000?

I am not using HAB on mx6, I think there was only one user of it ever.

HAB remains a use case, but I cannot find in the manual any reference for the IRAM (if any) it needs.

Regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
#9 lore raw
In reply to Marek Vasut
Quoted 7 lines · Marek Vasut
Quoted 6 lines

Marek,

Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board config? It looks like the novena board was the only one using it and it breaks Ventana build.

Quoted 7 lines

I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for ventana. If we have FS boot, we should push for filesystems which are not a patent minefield (like fat).

So what about adding this to ventana:
#undef CONFIG_SPL_EXT_SUPPORT

sounds reasonable - I'll submit that shortly

Regards,

Tim

#10 lore raw
Quoted 12 lines · Tim Harvey
Quoted 11 lines · Marek Vasut
Quoted 6 lines

Marek,

Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board config? It looks like the novena board was the only one using it and it breaks Ventana build.

I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for ventana. If we have FS boot, we should push for filesystems which are not a patent minefield (like fat).

Quoted 5 lines
Quoted 3 lines

So what about adding this to ventana:
#undef CONFIG_SPL_EXT_SUPPORT

sounds reasonable - I'll submit that shortly

Cool, thanks!

Signature · 2 lines
Best regards,
Marek Vasut