Please increase the image size for km boards
Valentin,
We are seeing the image size of kmcoge4 and kmlion1 are on the edge. Attempts to add new features cause overflow. Would you consider to increase the image size for km boards. You may have noticed several patches doing this for selected boards (search git log for 768K).
Thanks,
York
Hi York,
Quoted 7 lines · York Sun
Valentin,
We are seeing the image size of kmcoge4 and kmlion1 are on the edge. Attempts to add new features cause overflow. Would you consider to increase the image size for km boards. You may have noticed several patches doing this for selected boards (search git log for 768K).
I am going to have a look at it and see what the impact is for us. Basically I have nothing against changing this value, especially for kmcoge4/kmlion1.
Valentin
Quoted 5 lines · Valentin Longchamp
Hi York,
Quoted 2 lines · York Sun
Valentin,
Quoted 9 lines
Quoted 5 lines
We are seeing the image size of kmcoge4 and kmlion1 are on the edge. Attempts to add new features cause overflow. Would you consider to increase the image size for km boards. You may have noticed several patches doing this for selected boards (search git log for 768K).
I am going to have a look at it and see what the impact is for us. Basically I have nothing against changing this value, especially for kmcoge4/kmlion1.
Thanks. I can anticipate some chaos on the flash memory map. The environmental variables are stored before u-boot in flash, if FMan ucode if the SoC requires it.
York
Hi York,
Quoted 12 lines · York Sun
Quoted 11 lines · Valentin Longchamp
Hi York,
Quoted 7 lines · York Sun
Valentin,
We are seeing the image size of kmcoge4 and kmlion1 are on the edge. Attempts to add new features cause overflow. Would you consider to increase the image size for km boards. You may have noticed several patches doing this for selected boards (search git log for 768K).
Quoted 7 lines
Quoted 3 lines
I am going to have a look at it and see what the impact is for us. Basically I have nothing against changing this value, especially for kmcoge4/kmlion1.
Thanks. I can anticipate some chaos on the flash memory map. The environmental variables are stored before u-boot in flash, if FMan ucode if the SoC requires it.
I have finally had time to look at this point. For kmcoge4, we are lucky to have enough space on our boot SPI Flash and I had reserved 1M for u-boot when doing the layout to have some reserve. So in my case I am avoiding the possible flash memory map chaos.
If I have understood correctly, for the powerpc boards, the default value was changed from 512K to 768K. What do you think makes more sense, stay on line with the other powerpc boards with 768K or go directly to 1M since this space is avaible ? I prefer to stay on line.
Another question: am I right that the two things that need to be adjusted are:
- CONFIG_SYS_TEXT_BASE
- CONFIG_SYS_MONITOR_LEN
or am I missing something ?
Thank you very much
Valentin
Quoted 28 lines · Valentin Longchamp
Hi York,
Quoted 12 lines · York Sun
Quoted 11 lines · Valentin Longchamp
Hi York,
Quoted 7 lines · York Sun
Valentin,
We are seeing the image size of kmcoge4 and kmlion1 are on the edge. Attempts to add new features cause overflow. Would you consider to increase the image size for km boards. You may have noticed several patches doing this for selected boards (search git log for 768K).
Quoted 7 lines
Quoted 3 lines
I am going to have a look at it and see what the impact is for us. Basically I have nothing against changing this value, especially for kmcoge4/kmlion1.
Thanks. I can anticipate some chaos on the flash memory map. The environmental variables are stored before u-boot in flash, if FMan ucode if the SoC requires it.
I have finally had time to look at this point. For kmcoge4, we are lucky to have enough space on our boot SPI Flash and I had reserved 1M for u-boot when doing the layout to have some reserve. So in my case I am avoiding the possible flash memory map chaos.
Quoted 4 lines
If I have understood correctly, for the powerpc boards, the default value was changed from 512K to 768K. What do you think makes more sense, stay on line with the other powerpc boards with 768K or go directly to 1M since this space is avaible ? I prefer to stay on line.
I agree.
Quoted 7 lines
Another question: am I right that the two things that need to be adjusted are:
-CONFIG_SYS_TEXT_BASE
-CONFIG_SYS_MONITOR_LENor am I missing something ?
You don't have other than NOR flash boot, do you? If yes, you need to take care of them, too. You can find some example by looking into git log, search for 768K.
York
Quoted 41 lines · York Sun
Quoted 28 lines · Valentin Longchamp
Hi York,
Quoted 12 lines · York Sun
Quoted 11 lines · Valentin Longchamp
Hi York,
Quoted 7 lines · York Sun
Valentin,
We are seeing the image size of kmcoge4 and kmlion1 are on the edge. Attempts to add new features cause overflow. Would you consider to increase the image size for km boards. You may have noticed several patches doing this for selected boards (search git log for 768K).
Quoted 7 lines
Quoted 3 lines
I am going to have a look at it and see what the impact is for us. Basically I have nothing against changing this value, especially for kmcoge4/kmlion1.
Thanks. I can anticipate some chaos on the flash memory map. The environmental variables are stored before u-boot in flash, if FMan ucode if the SoC requires it.
I have finally had time to look at this point. For kmcoge4, we are lucky to have enough space on our boot SPI Flash and I had reserved 1M for u-boot when doing the layout to have some reserve. So in my case I am avoiding the possible flash memory map chaos.
Quoted 4 lines
If I have understood correctly, for the powerpc boards, the default value was changed from 512K to 768K. What do you think makes more sense, stay on line with the other powerpc boards with 768K or go directly to 1M since this space is avaible ? I prefer to stay on line.
I agree.
Quoted 5 lines
Another question: am I right that the two things that need to be adjusted are:
-CONFIG_SYS_TEXT_BASE
-CONFIG_SYS_MONITOR_LEN
Quoted 6 lines
Quoted 2 lines
or am I missing something ?
You don't have other than NOR flash boot, do you? If yes, you need to take care of them, too. You can find some example by looking into git log, search for 768K.
No we don't. SPI NOR Flash is the only boot flash supported on this design. So I think the above changes should be enough. I will give them a try and send the patch when tested.
Valentin