Re: [U-Boot-Users] ubi and u-boot
On Mon, 21 Apr 2008, Artem Bityutskiy wrote:
On Mon, 2008-04-21 at 00:22 +0200, Wolfgang Denk wrote:
In message 4808DF3B.2080702@largestprime.net you wrote:
Wolfgang showed some interest briefly too.[1]
I am definitely interested.
What I would suggest to start with is to teach U-boot to erase flash and preserve erase counters, because now it just wipes the erase counters out. Also, it would be nice to teach it to flash images properly in case of NAND flash.
I was under the impression from past emails on the MTD list that the internal meta format for UBI has changed a few times over its lifetime.
Assuming this continues, I would think this would cause problems for bootloaders such as U-Boot whose flash partitions are not necessarily rewritten in the case of a product upgrade - i.e. a firmware upgrade with a new kernel would have a new UBI implementation and spec causing an older bootloader to fail to operate properly with the newer image.
/Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30
On Mon, 2008-04-21 at 15:36 +0200, Ricard Wanderlof wrote:
On Mon, 21 Apr 2008, Artem Bityutskiy wrote:
On Mon, 2008-04-21 at 00:22 +0200, Wolfgang Denk wrote:
In message 4808DF3B.2080702@largestprime.net you wrote:
Wolfgang showed some interest briefly too.[1]
I am definitely interested.
What I would suggest to start with is to teach U-boot to erase flash and preserve erase counters, because now it just wipes the erase counters out. Also, it would be nice to teach it to flash images properly in case of NAND flash.
I was under the impression from past emails on the MTD list that the internal meta format for UBI has changed a few times over its lifetime.
Assuming this continues, I would think this would cause problems for bootloaders such as U-Boot whose flash partitions are not necessarily rewritten in the case of a product upgrade - i.e. a firmware upgrade with a new kernel would have a new UBI implementation and spec causing an older bootloader to fail to operate properly with the newer image.
I think there was only 1 time the on-flash format changed, and that was before UBI was merged upstream. New features can be introduced with additional flags, however older versions should be able to ignore those.
Artem, is that right? My memory is fuzzy here.
josh
Sorry for the newb question but I've been googling like mad and can't find any clues (or more likely, can't understand what I do find).
I'm looking at speed.c under /cpu/arm920t/s3c24xx and thinking this is the business end of CPU speed setting. I've been greping the source to see if I can track back to something calling them that I can understand, but no luck.
Any kind soul out there able to tell me how?
Hi,
p wrote:
Sorry for the newb question but I've been googling like mad and can't find any clues (or more likely, can't understand what I do find).
I'm looking at speed.c under /cpu/arm920t/s3c24xx and thinking this is the business end of CPU speed setting. I've been greping the source to see if I can track back to something calling them that I can understand, but no luck.
under your board/<boardname>/<boardfile> Take for example the board/smdk2410/smdk2410.c and change #if FCLK_SPEED==0 /* Fout = 203MHz, Fin = 12MHz for Audio */ #define M_MDIV 0xC3 #define M_PDIV 0x4 #define M_SDIV 0x1
Regards Michael
Hi p,
u-boot-users-bounces@lists.sourceforge.net wrote on Tuesday, April 22, 2008 3:10 AM:
Sorry for the newb question but I've been googling like mad and can't find any clues (or more likely, can't understand what I do find).
I'm looking at speed.c under /cpu/arm920t/s3c24xx and thinking this is the business end of CPU speed setting. I've been greping the source to
No, in /cpu/arm920t/s3c24x0/speed.c are only functions to read the clock configuration. The setting of the clocks is done in the board specific initilaisation code. For the SMDK2410 for example in /board/smdk2410/smdk2410.c. The MPLL Clock (and thus the derived CPU clock FCLK) is configured via the PLL divider values MDIV, PDIV and SDIV. For a detailed description take a look into the S3C2410 datasheet (search for the MPLL register in the chapter Clock & Power Management).
Regards, Martin Krause
-- TQ-Systems GmbH Muehlstrasse 2, Gut Delling, D-82229 Seefeld Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913 Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl http://www.tq-group.com
Thanks very much for the responses. Once it was pointed out to me that the CPU speed settings are in the board file I actually remembered seeing them there before. Don't know why I got fixated on that speed.c.
I'm now zipping along at 266 mhz!
On Mon, 2008-04-21 at 18:09 -0700, p wrote:
Sorry for the newb question but I've been googling like mad and can't find any clues (or more likely, can't understand what I do find).
I'm looking at speed.c under /cpu/arm920t/s3c24xx and thinking this is the business end
Josh Boyer wrote:
I was under the impression from past emails on the MTD list that the internal meta format for UBI has changed a few times over its lifetime.
Assuming this continues, I would think this would cause problems for bootloaders such as U-Boot whose flash partitions are not necessarily rewritten in the case of a product upgrade - i.e. a firmware upgrade with a new kernel would have a new UBI implementation and spec causing an older bootloader to fail to operate properly with the newer image.
I think there was only 1 time the on-flash format changed, and that was before UBI was merged upstream. New features can be introduced with additional flags, however older versions should be able to ignore those.
Quite. As long as the format is changed in an upward compatible way, it should be fine. Hopefully the existing format is designed to ensure that's always possible - at least for everything called 'UBI 1' since the upstream merge.
-- Jamie
participants (6)
-
Jamie Lokier -
Josh Boyer -
Martin Krause -
michael -
p -
Ricard Wanderlof