[U-Boot-Users] PATCH: RPXlite configuration fixes
The attached patch fixes several bugs in and adds some features to long orphaned RPXlite port.
CHANGELOG
Fix RPXlite board configuration.
- Use correct flash sector size - Use correct memory test end address - Add support for bzip2 compression - Various small fixes
--- Yuli Barcohen yuli@arabellasw.com wrote:
The attached patch fixes several bugs in and adds some features to long orphaned RPXlite port.
CHANGELOG
Fix RPXlite board configuration.
- Use correct flash sector size
It seems that you adjusted CFG_ENV_SECT_SIZE from 0x4000 to 0x40000. Is it your flash sector size?
- Various small fixes
I cannot understand why CFG_RESET_ADDRESS should be set as 0x09900000. Did you test the reset function with this config? Could u shed me a light on it?
Thanks in advance,
Sam
___________________________________________________________ 欢迎注册雅虎超大容量免费邮箱 http://cn.mail.yahoo.com
Sam Song writes:
Sam> It seems that you adjusted CFG_ENV_SECT_SIZE
No, I used CFG_ENV_SECT_SIZE instead of CFG_ENV_SIZE. It's not the same. BTW, the original comment mentioned "Total Size of Environment Sector" which is not CFG_ENV_SIZE.
Sam> from 0x4000 to 0x40000. Is it your flash sector size?
Yes, it is. There are four Am29LV800BB chips so you can't have 0x4000 bytes in sector (this would require 4KB sector on individual flash chip while in fact the smallest sectors are 8KB). The board is configured for high boot (don't know why Embedded Planet designers used high boot with bottom boot block flashes) so the U-Boot "lives" at 0xFFF00000. I put the environment to the next sector. The sector's size is 4x64KB = 0x40000. With the original configuration, saveenv must fail and it indeed failed. Have you got an RPXlite board with different flash configuration?
Sam> I cannot understand why CFG_RESET_ADDRESS should be set as Sam> 0x09900000.
It can be set to any illegal address so that memory access at this address will cause checkstop and then reset. 0x09900000 was used on some other boards, it has no special meaning.
Sam> Did you test the reset function with this config?
Of course, I did. I never send untested patches.
Sam> Could u shed me a light on it?
--- Yuli Barcohen yuli@arabellasw.com wrote:
No, I used CFG_ENV_SECT_SIZE instead of CFG_ENV_SIZE. It's not the same. BTW, the original comment mentioned "Total Size of Environment Sector" which is not CFG_ENV_SIZE.
Ummm, CFG_ENV_SIZE is really a misleading config item. No matter how small the ENV size is, it take up one or several FLASH sectors. I have no idea when we use CFG_ENV_SIZE:-)
Sam> from 0x4000 to 0x40000. Is it your flash
sector size?
Yes, it is. There are four Am29LV800BB chips so you can't have 0x4000 bytes in sector (this would require 4KB sector on individual flash chip while in fact the smallest sectors are 8KB). The board is configured for high boot (don't know why Embedded Planet designers used high boot with bottom boot block flashes) so the U-Boot "lives" at 0xFFF00000. I put
So they produce other kind of rpxlite to work right in low boot mode with bottom boot block flashes later:-)
the environment to the next sector. The sector's size is 4x64KB = 0x40000. With the original configuration, saveenv must fail and it indeed failed.
Well, it failed on your rpxlite board but doesn't mean it would fail on Yoo.Jonghoon's rpxlite board:-)
Have you got an RPXlite board with different flash configuration?
Yeah, I got one. It uses 4 AM29DL323DB90VI devices (4x8bit) in 16MB(4x4MB) and leaves the u-boot home at 0xff000000. I ported u-boot on this one and named RPXlite DW as 2.4 Linux code did.
From your discussion, you assume there is one standard
rpxlite board. Actually, there are at least five different combination boards known as RPXlite CW.
So your changelog on FLASH size could use update rather than correct.
Sam> I cannot understand why CFG_RESET_ADDRESS
should be set as 0x09900000.
It can be set to any illegal address so that memory access at this address will cause checkstop and then reset. 0x09900000 was used on some other boards, it has no special meaning.
Thanks for your notes,
Sam
___________________________________________________________ 雅虎免费G邮箱－中国最强免费防毒反垃圾超大邮箱 http://cn.mail.yahoo.com/?id=77072
In message 20050606131237.32918.qmail@web15906.mail.cnb.yahoo.com you wrote:
Ummm, CFG_ENV_SIZE is really a misleading config item.
Ummm... and which part of the documentation in the README did you fail to understand?
No matter how small the ENV size is, it take up one or several FLASH sectors. I have no idea when we use CFG_ENV_SIZE:-)
You did read the README, didn't you?
Best regards,
Wolfgang Denk
Sam Song writes:
Yuli> No, I used CFG_ENV_SECT_SIZE instead of CFG_ENV_SIZE. It's not Yuli> the same. BTW, the original comment mentioned "Total Size of Yuli> Environment Sector" which is not CFG_ENV_SIZE.
Sam> Ummm, CFG_ENV_SIZE is really a misleading config item. No Sam> matter how small the ENV size is, it take up one or several Sam> FLASH sectors. I have no idea when we use CFG_ENV_SIZE:-)
This is explained in details in the README.
Sam> from 0x4000 to 0x40000. Is it your flash sector size?
Yuli> Yes, it is. There are four Am29LV800BB chips so you can't have Yuli> 0x4000 bytes in sector (this would require 4KB sector on Yuli> individual flash chip while in fact the smallest sectors are Yuli> 8KB). The board is configured for high boot (don't know why Yuli> Embedded Planet designers used high boot with bottom boot Yuli> block flashes) so the U-Boot "lives" at 0xFFF00000. I put
Sam> So they produce other kind of rpxlite to work right in low boot Sam> mode with bottom boot block flashes later:-)
Do you mean the DW series?
Yuli> the environment to the next sector. The sector's size is Yuli> 4x64KB = 0x40000. With the original configuration, saveenv Yuli> must fail and it indeed failed.
Sam> Well, it failed on your rpxlite board but doesn't mean it would Sam> fail on Yoo.Jonghoon's rpxlite board:-)
Don't know. If the saveenv works OK, why to have hard-coded environment in the configuration file? Anyway, if anybody knows for what board old values are correct, I'd be happy to add appropriate #ifdefs. Maybe there are configurations using only two flash chips? In any case, new configuration should cover them all.
Yuli> Have you got an RPXlite board with different flash Yuli> configuration?
Sam> Yeah, I got one. It uses 4 AM29DL323DB90VI devices (4x8bit) in Sam> 16MB(4x4MB) and leaves the u-boot home at 0xff000000. I ported Sam> u-boot on this one and named RPXlite DW as 2.4 Linux code did.
But it's a different board family though I'm not sure having two separate ports is justified. Probably it's possible to handle the differences in the Makefile.
Sam> From your discussion, you assume there is one standard rpxlite Sam> board.
No, I don't, I work with different Embedded Planet boards and know their product range, more or less. In any case, if there are four flash chips, minimal sector size usually is 32KB unless there really is some flash with 4KB sectors. And if the U-Boot is configured for high boot (the original port is), why should the environment be placed in the middle of the flash (offset 0x8000 from the flash base)?
Sam> Actually, there are at least five different combination boards Sam> known as RPXlite CW.
Yes, but AFAIK in the case of high boot it does not matter.
Sam> So your changelog on FLASH size could use update rather than Sam> correct.
Sam> I cannot understand why CFG_RESET_ADDRESS Sam> should be set as 0x09900000.
Yuli> It can be set to any illegal address so that memory access at Yuli> this address will cause checkstop and then reset. 0x09900000 Yuli> was used on some other boards, it has no special meaning.
--- Yuli Barcohen yuli@arabellasw.com wrote:
I have no idea when we use CFG_ENV_SIZE:-)
This is explained in details in the README.
Thanks. Wolfgang also suggested. But I use :-) is for joking with CFG_ENV_SIZE in the old code of RPXlite. It confused me at that time:-)
So they produce other kind of rpxlite to work right in low boot mode with bottom boot block flashes later:-)
Do you mean the DW series?
Yeah.
Maybe there are configurations using only two flash chips?
Ummm, I amn't sure about it.
In any case, new configuration should cover them all.
That would be Great! In addition, this code also need to upgrade to new state.
But it's a different board family though I'm not sure having two separate ports is justified. Probably it's possible to handle the differences in the Makefile.
EP uses plantcore to implement one image for all rpxlite board. Its flexible characteristic impressed me a lot. It's possible to combine these two ports.
product range, more or less. In any case, if there are four flash chips, minimal sector size usually is 32KB unless there really is some flash with 4KB sectors. And if the U-Boot is configured for high boot (the original port is), why should the environment be placed in the middle of the flash (offset 0x8000 from the flash base)?
Good point. I come to know that you have the same board as Yoo.'s. Both have 4 AM29LV800BB chips. If so, this is really a long orphaned fix.
Thanks for this clarification,
Sam
__________________________________________________ 赶快注册雅虎超大容量免费邮箱? http://cn.mail.yahoo.com
Sam Song writes:
...
Yuli> In any case, new configuration should cover them all.
Sam> That would be Great! In addition, this code also need to Sam> upgrade to new state.
I don't mean it already covers DW boards (I haven't got one) though no significant modifications should be necessary. IIRC, DW boards use CFI-compliant flash so common CFI driver can be used instead of the board-specific one.
Yuli> But it's a different board family though I'm not sure having Yuli> two separate ports is justified. Probably it's possible to Yuli> handle the differences in the Makefile.
Sam> EP uses plantcore to implement one image for all rpxlite Sam> board. Its flexible characteristic impressed me a lot. It's Sam> possible to combine these two ports.
PlanetCore saves its environment in the I2C EEPROM so it's not affected by the flash configuration. Also, the EEPROM contains exact board hardware configuration (board version, RAM size, flash size, etc.) probably burned there during manufacturing process so PlanetCore can initialise the board accordingly. It's possible to use this information in the U-Boot but some hard-coded values still remain. CFG_MONITOR_LEN and CFG_ENV_SECT_SIZE are a problem, especially now when we've got universal CFI driver. In theory, CFI driver detects the flash configuration automatically so the same U-Boot image can work on different boards. In real world, CFG_MONITOR_LEN and CFG_ENV_SECT_SIZE must be specified in compile time so different flashes can result in different images. I'd like to remove these compile time values. Any ideas if and how it's possible?
...
Dear Yuli,
in message 17060.29833.578253.397330@astp0002.localdomain you wrote:
different boards. In real world, CFG_MONITOR_LEN and CFG_ENV_SECT_SIZE must be specified in compile time so different flashes can result in
You can define a CFG_MONITOR_LEN that matches all supported boards; CFG_ENV_SECT_SIZE is more difficult to handle.
different images. I'd like to remove these compile time values. Any ideas if and how it's possible?
The problem is that in the current code a lot of dependency checking is doen at compile time. This is *intentional* to keep the code size minimal. If you can figure out how to avoid #defined CFG_ENV_* settings while *not* increasing the code size your patches will be welcome.
Best regards,
Wolfgang Denk
Wolfgang Denk writes:
Yuli> different boards. In real world, CFG_MONITOR_LEN and Yuli> CFG_ENV_SECT_SIZE must be specified in compile time so Yuli> different flashes can result in
Wolfgang> You can define a CFG_MONITOR_LEN that matches all Wolfgang> supported boards;
It's what I do in my ports.
Wolfgang> CFG_ENV_SECT_SIZE is more difficult to handle.
Yuli> different images. I'd like to remove these compile time Yuli> values. Any ideas if and how it's possible?
Wolfgang> The problem is that in the current code a lot of Wolfgang> dependency checking is doen at compile time. This is Wolfgang> *intentional* to keep the code size minimal. If you can Wolfgang> figure out how to avoid #defined CFG_ENV_* settings while Wolfgang> *not* increasing the code size
It's what I'm trying to do. I'd like to clarify "increasing the code size" concern which appears from time to time on the list. As we all know, U-Boot occupies entire flash sector (or several sectors). So, IMHO, if the increase does not require additional sector, the increase should not be a problem. Even if you're concerned about RAM size, I'm not sure U-Boot size can be an issue. In most cases, there is at least 8MB of RAM, so if U-Boot is 170K or 200K should not make any difference. I personally never had such an issue with our customers. In cases when such a difference is critical, current method (compile-time CFG_ENV_SECT_SIZE) can be used. In any case, I believe that run-time vs compile-time code size difference can be 2-3K in the worst case.
Wolfgang> your patches will be welcome.
In message 17060.34001.772438.243816@astp0002.localdomain you wrote:
It's what I'm trying to do. I'd like to clarify "increasing the code size" concern which appears from time to time on the list. As we all know, U-Boot occupies entire flash sector (or several sectors). So, IMHO, if the increase does not require additional sector, the increase
You assume that there is flash on a board. There are boards which use a 128 kB ROM, and still are able to use a decent set of features. Of course this requires optimization, and omitting some stuff. It's not a matter of using an additional sector or not, it's as simple as works or does not work.
should not be a problem. Even if you're concerned about RAM size, I'm not sure U-Boot size can be an issue. In most cases, there is at least 8MB of RAM, so if U-Boot is 170K or 200K should not make any difference. I personally never had such an issue with our customers. In
I do, and I will strictly look at the code size. The rules are well known.
cases when such a difference is critical, current method (compile-time CFG_ENV_SECT_SIZE) can be used. In any case, I believe that run-time vs compile-time code size difference can be 2-3K in the worst case.
Maybe. Then it's 2-3k which can be saved, and shall be saved.
Best regards,
Wolfgang Denk
Wolfgang Denk writes:
Yuli> It's what I'm trying to do. I'd like to clarify "increasing Yuli> the code size" concern which appears from time to time on the Yuli> list. As we all know, U-Boot occupies entire flash sector (or Yuli> several sectors). So, IMHO, if the increase does not require Yuli> additional sector, the increase
Wolfgang> You assume that there is flash on a board. There are Wolfgang> boards which use a 128 kB ROM, and still are able to use a Wolfgang> decent set of features. Of course this requires Wolfgang> optimization, and omitting some stuff. It's not a matter Wolfgang> of using an additional sector or not, it's as simple as Wolfgang> works or does not work.
But we're discussing only "environment in flash" case. All the rest is unchanged. The CFG_ENV_SECT_SIZE is relevant for flash only, isn't it? Also, if CFG_ENV_SECT_SIZE is defined, the existing mechanism will work. I'd suggest any changes only for the case when CFG_ENV_SECT_SIZE is undefined so the programmer always can chose between compile-time and run-time approaches.
Yuli> should not be a problem. Even if you're concerned about RAM Yuli> size, I'm not sure U-Boot size can be an issue. In most cases, Yuli> there is at least 8MB of RAM, so if U-Boot is 170K or 200K Yuli> should not make any difference. I personally never had such an Yuli> issue with our customers. In
Wolfgang> I do, and I will strictly look at the code size. The rules Wolfgang> are well known.
Yuli> cases when such a difference is critical, current method Yuli> (compile-time CFG_ENV_SECT_SIZE) can be used. In any case, I Yuli> believe that run-time vs compile-time code size difference can Yuli> be 2-3K in the worst case.
Wolfgang> Maybe. Then it's 2-3k which can be saved, and shall be Wolfgang> saved.
So look at the saveenv code (in common/env_flash.c). The following definition:
#if defined(CFG_ENV_SECT_SIZE) && (CFG_ENV_SECT_SIZE > CFG_ENV_SIZE) ulong flash_offset; uchar env_buffer[CFG_ENV_SECT_SIZE]; #else
allocates CFG_ENV_SECT_SIZE bytes on stack, in many cases this is 256KB. So we don't care for RAM data size but fight for every byte of code size? Anyway, nobody is forced to use new mechanism if and when I develop it. Also, I see no reason why U-Boot should be less convenient or less flexible than, say, PlanetCore.
Unrelated question, also regarding the environment. It looks like CFG_ENV_IS_EMBEDDED is unnecessary because ENV_IS_EMBEDDED is calculated and used. What do you think?
Dear Yuli,
in message 17061.20898.318765.498613@astp0002.localdomain you wrote:
But we're discussing only "environment in flash" case. All the rest is
Yes. I see no reason for a "but" in this sentence, though.
unchanged. The CFG_ENV_SECT_SIZE is relevant for flash only, isn't it?
Yes. And the memory footprint for U-Boot on the boot device is essential.
So look at the saveenv code (in common/env_flash.c). The following definition:
...
allocates CFG_ENV_SECT_SIZE bytes on stack, in many cases this is 256KB. So we don't care for RAM data size but fight for every byte of code size? Anyway, nobody is forced to use new mechanism if and when I
Right. Normally U-Boot is used to boot an OS which requires several megabytes of RAM so we don't have to worry about allocating even bigger temporary buffers in U-Boot.
develop it. Also, I see no reason why U-Boot should be less convenient or less flexible than, say, PlanetCore.
I agree, if it can be avoided. But we have clear priorities. Small memory footprint is much hicher on the list than comparing U-Boot against PlanetCore.
Unrelated question, also regarding the environment. It looks like CFG_ENV_IS_EMBEDDED is unnecessary because ENV_IS_EMBEDDED is calculated and used. What do you think?
It was needed once, and I guess nobody ever spent the effort to actually test all related platforms if it can be savely removed.
Best regards,
Wolfgang Denk
Yuli Barcohen yuli@arabellasw.com wrote:
I don't mean it already covers DW boards (I haven't got one) though no significant modifications should be necessary.
I didn't deem it, either.
DW boards use CFI-compliant flash so common CFI driver can be used instead of the board-specific one.
Well, although DW use CFI-compliant flash, it still work with a board-specific one at least in CVS. I once used CFI driver on DW but failed.
PlanetCore saves its environment in the I2C EEPROM so PlanetCore can initialise the board accordingly. It's possible to use this information
If so, U-Boot and PlanetCore can share one ENV to work??? IMHO, ENV in EEPROM of PlanetCore use it's own definition keyword. Only to change ENV of U-Boot can meet the requirement of PlanetCore. It will decrease u-boot ENV variability.
in the U-Boot but some hard-coded values still remain. CFG_MONITOR_LEN and CFG_ENV_SECT_SIZE
If used EEPROM for ENV home, could we need to set CFG_ENV_SECT_SIZE?
Actually, I am worring about one thing if we wanted to combine CW nad DW port. That's how to deal with HIGH boot mode[DW] and LOW boot mode[CW] in one image.
time values. Any ideas if and how it's possible?
The "possible" I used was really a draft idea. Don't take it seriously. To me, it isn't worthwhile to implement it. CW is too old to be popular nowdays. Take a look at it's main page if avaiable.
http://www.embeddedplanet.com/products/lite.asp
In one word, you fix on RPXlite is a treasure. Just stop and keep that. Those who are interested on RPXlite[C/DW] can get enough hints from exist port work in CVS.
Thanks for your time,
Sam
___________________________________________________________ 雅虎免费G邮箱－中国最强免费防毒反垃圾超大邮箱 http://cn.mail.yahoo.com/?id=77072
Sam Song writes:
...
Yuli> PlanetCore saves its environment in the I2C EEPROM so Yuli> PlanetCore can initialise the board accordingly. It's possible Yuli> to use this information
Sam> If so, U-Boot and PlanetCore can share one ENV to work??? IMHO, Sam> ENV in EEPROM of PlanetCore use it's own definition Sam> keyword. Only to change ENV of U-Boot can meet the requirement Sam> of PlanetCore. It will decrease u-boot ENV variability.
U-Boot and PlanetCore can't share the same environment but board-specific code in U-Boot can use PlanetCore environment to initialise U-Boot's one.
Yuli> in the U-Boot but some hard-coded values still Yuli> remain. CFG_MONITOR_LEN and CFG_ENV_SECT_SIZE
Sam> If used EEPROM for ENV home, could we need to set Sam> CFG_ENV_SECT_SIZE?
No, if the environment is not in flash this problem does not exist but the EEPROM is too small for U-Boot's environment (and Wolfgang always advises against using EEPROM for environment:).
Sam> Actually, I am worring about one thing if we wanted to combine Sam> CW nad DW port. That's how to deal with HIGH boot mode[DW] and Sam> LOW boot mode[CW] in one image.
There will be no single binary image for all boards but can be single source which also reduces maintenance efforts.
...
--- Yuli Barcohen yuli@arabellasw.com wrote:
There will be no single binary image for all boards but can be single source which also reduces maintenance efforts.
Ummm, I do agree with it:-)
NOW TIME : 21:33 -- Good night:-)
Sam
___________________________________________________________ 雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 http://cn.mail.yahoo.com/?id=77071
In message 17059.20977.593589.618317@astp0002.localdomain you wrote:
CHANGELOG
Fix RPXlite board configuration.
- Use correct flash sector size - Use correct memory test end address - Add support for bzip2 compression - Various small fixes
Applied, thanks.
Best regards,
Wolfgang Denk
participants (3)
-
Sam Song -
Wolfgang Denk -
Yuli Barcohen