Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
On Tue, Sep 8, 2009 at 4:07 PM, Jerry Van Baren wrote: > J.C. Wren wrote: > >> I saw this comment: "Also i gather from e-mails on the list that Wolfgang >> does not like these references to "SZ_xx". Maybe that discussion took >> place >> before I joined the list. >> >> If he wants it that way, fine. But that doesn't explain the "why". >> What's >> so offensive about the SZ_* defines? >> >> --jc >> > > Hi J.C., > > The SZ_* defines turns a simple math problem into a two finger problem... > every time you see them, you need to put your finger in the code and look > them up, only to find (1 << n), have to stick a second finger in the code, > and have to do the math anyway. > > One REALLY BAD problem is that idiots have been known to mis-define them > rather than fix the code that uses them (seriously!). By using (1 << 20) > directly, it removes that temptation. > > A lesser problem is that they don't do anything, you still have to figure > out that 1 << 20 is 1MiB. All they do is defer the pain. > > You will also find other silliness, e.g. generating SZ_31M: > <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/27048/focus=27139> > This silliness is the road to insanity: SZ_30M and SZ_29M and SZ_28.125M. > (OK, I exaggerated on that last one. It would actually be SZ_28_125M.) > > HTH, > gvb > > [snip] > Excellent explanation. Thank you. I do like this (from the email link): (31 * 1024 * 1024). And it appears not to give Wolfgang indigestion :) --jc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
I saw this comment: "Also i gather from e-mails on the list that Wolfgang does not like these references to "SZ_xx". Maybe that discussion took place before I joined the list. If he wants it that way, fine. But that doesn't explain the "why". What's so offensive about the SZ_* defines? --jc On Tue, Sep 8, 2009 at 3:20 PM, Paulraj, Sandeep wrote: > Jc, > > > > Did you read what I wrote below the --- line in the patch itself? > > > > Wolfgang wants to get rid of these references. He expressed this some time > back. > > If he decides to get rid of this file altogether this will lead to > compilation failures. > > > > Thanks, > > Sandeep > > > ------ > > *From:* jcw...@gmail.com [mailto:jcw...@gmail.com] *On Behalf Of *J.C. > Wren > *Sent:* Tuesday, September 08, 2009 3:15 PM > *To:* Tom > *Cc:* Paulraj, Sandeep; u-boot@lists.denx.de > > *Subject:* Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx > > > > Why is this change being made at all? Seems a lot more awkward to define > (1 << 20) than SZ_1MB. SZ_1MB reads a lot easier. > > --jc > > On Tue, Sep 8, 2009 at 3:09 PM, Tom wrote: > > Paulraj, Sandeep wrote: > > > >> -Original Message- > >> From: Wolfgang Denk [mailto:w...@denx.de] > >> Sent: Tuesday, September 08, 2009 2:51 PM > >> To: Paulraj, Sandeep > >> Cc: u-boot@lists.denx.de > >> Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx > >> > >> Dear s-paul...@ti.com, > >> > >> In message <1252434246-19517-1-git-send-email-s-paul...@ti.com> you > wrote: > >>> From: Sandeep Paulraj > >>> > >>> This patch removes the asm/sizes.h header file from being > >>> included in the DaVinci SOC configs. > >>> References to SZ_xx have been replaced by appropriate > >>> bit shifted values. > >>> > >>> Signed-off-by: Sandeep Paulraj > >> Note that this patch actually changes the configuration: > >> > >>> --- a/include/configs/davinci_dm355evm.h > >>> +++ b/include/configs/davinci_dm355evm.h > >> ... > >>> /* U-Boot memory configuration */ > >>> -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ > >>> -#define CONFIG_SYS_MALLOC_LEN SZ_512K /* malloc() > >> arena */ > >>> +#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ > >>> +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB*/ > >> as it increases the malloc() arena size form 512 to 1024 KiB. > >> > >> Assuming this was done intentionally: > > [Sandeep] Yes this was intentional because for NANDs with large block > sizes(256 KiB), if this is not increased we will get "out of memory" errors. > >> Acked-by: Wolfgang Denk > >> > > Then this change needs to be a separate patch. > > Nak Tom > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
Why is this change being made at all? Seems a lot more awkward to define (1 << 20) than SZ_1MB. SZ_1MB reads a lot easier. --jc On Tue, Sep 8, 2009 at 3:09 PM, Tom wrote: > Paulraj, Sandeep wrote: > > > >> -Original Message- > >> From: Wolfgang Denk [mailto:w...@denx.de] > >> Sent: Tuesday, September 08, 2009 2:51 PM > >> To: Paulraj, Sandeep > >> Cc: u-boot@lists.denx.de > >> Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx > >> > >> Dear s-paul...@ti.com, > >> > >> In message <1252434246-19517-1-git-send-email-s-paul...@ti.com> you > wrote: > >>> From: Sandeep Paulraj > >>> > >>> This patch removes the asm/sizes.h header file from being > >>> included in the DaVinci SOC configs. > >>> References to SZ_xx have been replaced by appropriate > >>> bit shifted values. > >>> > >>> Signed-off-by: Sandeep Paulraj > >> Note that this patch actually changes the configuration: > >> > >>> --- a/include/configs/davinci_dm355evm.h > >>> +++ b/include/configs/davinci_dm355evm.h > >> ... > >>> /* U-Boot memory configuration */ > >>> -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ > >>> -#define CONFIG_SYS_MALLOC_LEN SZ_512K /* malloc() > >> arena */ > >>> +#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ > >>> +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB*/ > >> as it increases the malloc() arena size form 512 to 1024 KiB. > >> > >> Assuming this was done intentionally: > > [Sandeep] Yes this was intentional because for NANDs with large block > sizes(256 KiB), if this is not increased we will get "out of memory" errors. > >> Acked-by: Wolfgang Denk > >> > > Then this change needs to be a separate patch. > > Nak Tom > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Normal command line behavior?
On Tue, Aug 4, 2009 at 3:48 PM, Scott Wood wrote: > On Tue, Aug 04, 2009 at 12:07:17PM -0400, J.C. Wren wrote: > > All fair points. > > > > It appears that the 'nand' commands don't use the new parser structure. > > Do you mean U_BOOT_CMD_MKENT, find_cmd_tbl, etc? Not sure about that part. I just went back and looked at cmd_i2c.c, cmd_yaffs2.c and a few others and I see they all do sub-command processing with strncmp(), too. I had looked at one other file prior to my post, and thought I understood sub-commands were plugged-in with macros. My mistake. I forgot to mention that all the yaffs commands are top level. If I were me, I'd like to see the yaffs command broken down into a sub-menu. That's just a minor nit, as having them all in the top level makes the help a little more unwieldy. And they'd be used infrequently enough that having them under a 'y' sub-menu wouldn't make them much more difficult to use. > > > The 'nand' and 'nboot' commands use the U_BOOT_CMD macro, and have > > repeatable defined as 1. The 'nand' command is doing it's own > > sub-command parsing (via strcnmp()'s), and as a result, all 'nand' > > commands are repeatable. That probably isn't a good idea, and I would > > request the the 'nand' command itself be made non-repeatable. > > The one nand command that probably should be repeatable is "nand dump", > with auto-increment similar to "md". Makes sense. > > > -Scott > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Normal command line behavior?
All fair points. It appears that the 'nand' commands don't use the new parser structure. The 'nand' and 'nboot' commands use the U_BOOT_CMD macro, and have repeatable defined as 1. The 'nand' command is doing it's own sub-command parsing (via strcnmp()'s), and as a result, all 'nand' commands are repeatable. That probably isn't a good idea, and I would request the the 'nand' command itself be made non-repeatable. --jc On Mon, Aug 3, 2009 at 5:58 PM, Wolfgang Denk wrote: > Dear Jerry Van Baren, > > In message <4a773c1c.7080...@ge.com> you wrote: > > > > It is a configuration/design decision: see include/command.h line 46ff, > > struct cmd_tbl_s, field "repeatable". This is configured via the > > U_BOOT_CMD macro. > > > > < > http://git.denx.de/?p=u-boot.git;a=blob;f=include/command.h;h=55caa6eaf888cdb916d3937a5054ad862ec0e0ab;hb=HEAD#l46 > > > > > > Sometimes it is nice (e.g. sequencing through memory dumps), sometimes > > it bites (you found one of those!). IMHO, it is enabled in places where > > it would be better to rely on command line recall rather than the repeat > > function. > > The general rule is that any command that is non-destructive is > repeatable, i. e. a "tftp" will be repeated, while an "erase" will > not. > > Indeed, today command line history makes it partially dispensable, but > often at the cost of more typing (think about using the "md" command). > > > I think the repeat functionality predated the command line recall > > functionality, so it use to be more desirable to repeat the command > > because there wasn't an alternative way to repeat the command. > > Correct, this, and because that was exactly what I wanted when I > implemented it :-) > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > The software required `Windows 95 or better', so I installed Linux. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Normal command line behavior?
I notice that when I hit return at a U-Boot > prompt, it executes the last command again. CONFIG_SYS_HUSH_PARSER is defined, from U-Boot 2009.08-rc1-00030-g56bdfa9-dirty. It this is expected, it seems like a *really* bad idea. It's cost me having to reload 6M images at 115200 twice now. --jc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Make 'nand write.yaffs' mainline?
Being still unfamiliar with u-boot standards and practices for submitting patches, etc, what can I do to make this happen? I can diff it against the sources I have and submit a patch to the mailing list, if that's acceptable. I'm building for ARM, and I've proved it works (needing only a one change because of the lack of __udivid3 for ARM). --jc On Mon, Aug 3, 2009 at 10:39 AM, Wolfgang Denk wrote: > Dear "J.C. Wren", > > In message <17434f2e0908030603t74e23a37ob201fcfb0bf46...@mail.gmail.com> > you wrote: > > > > Scott pointed me at this patch ( > > > http://git.denx.de/?p=u-boot/u-boot-blackfin.git;a=commitdiff;h=44f07de8cc94836cd3b0fd2fb0cf8b8651461087 > ) > > that's in the Blackfin branch. > > > > Would it be possible to make this mainline? > > I don't think this patch has ever been submitted on the mailing list, > at least I cannot find a posting with this subject. > > Without postingit on the ML it cannot go into mainline. Actually if > should not have been added to the BF custoidian repository, either. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Make 'nand write.yaffs' mainline?
Scott pointed me at this patch ( http://git.denx.de/?p=u-boot/u-boot-blackfin.git;a=commitdiff;h=44f07de8cc94836cd3b0fd2fb0cf8b8651461087) that's in the Blackfin branch. Would it be possible to make this mainline? Thanks, --jc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Missing __udivdi3 for ARM
I thought the idea was to move u-boot away from libgcc dependencies. Or did I misread that? I know that a previous problem I commented on was solved by adding a __x.S function the u-boot library. --jc On Sat, Aug 1, 2009 at 10:40 AM, Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <20090801132619.ga19...@game.jcrosoft.org> you wrote: > > On 17:40 Fri 31 Jul , J.C. Wren wrote: > > > I enabled CONFIG_YAFFS2 for ARM, and got the following message: > > > /home/user/u-boot/fs/yaffs2/yaffscfg.c:185: undefined reference to > > > `__udivdi3' > > just use lldiv > > The big question here is if such a change makes sense; please keep in > mind that the yaffs2 code is just borrowed from Linux, so changes > should be kept to a minimum. > > Actually I think it is only reasonable to assume that libgcc.a should > include such a function. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > There is a multi-legged creature crawling on your shoulder. >-- Spock, "A Taste of Armageddon", stardate 3193.9 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Temporary patch for missing _udivdi3 in fs/yaffs2/yaffscfg.c
I don't know if this is the correct way to submit a patch or not. If not, please accept my apologies. This gets past the missing _udivid3 issue, but is not the correct way, long-term. diff --git a/fs/yaffs2/yaffscfg.c b/fs/yaffs2/yaffscfg.c index 16e84a4..25a43aa 100644 --- a/fs/yaffs2/yaffscfg.c +++ b/fs/yaffs2/yaffscfg.c @@ -22,6 +22,7 @@ #include #include +#include #include "nand.h" #include "yaffscfg.h" #include "yaffsfs.h" @@ -182,7 +183,7 @@ int yaffs_StartUp(void) flashDev->nDataBytesPerChunk = mtd->oobblock; flashDev->nChunksPerBlock = mtd->erasesize / mtd->oobblock; #endif - nBlocks = mtd->size / mtd->erasesize; + nBlocks = lldiv (mtd->size, mtd->erasesize); flashDev->nCheckpointReservedBlocks = 10; flashDev->startBlock = 0; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] YAFFS2 and getting the NAND formatted
I'm still at a major chicken-and-the-egg stage here, with regards to YAFFS2. I have YAFFS2 support compiled in the kernel, and in U-boot. I boot into u-boot, I can loady my kernel, write it, yload the YAFFS2 image generated by mkyaffs2image... and then what? Can't use 'nand write' because it doesn't write the OOB for YAFFS2. I have a bunch of handy file commands for YAFFS2, but nothing like 'yformat', or 'ycopy_memory_to_NAND_and_make_a_useful_YAFFS2_image' (please shorten that command if you can :) ). If I had a valid image copy in, I see that I can mount and unmount my image (although no reference is given as to where the mount point is). 'ydump' might do something with a valid image, but it just returns with 0 output, so I'm not sure exactly what it does. I see references to 'nand write.yaffs2' which looks like it might do what I want, but that seems to be non-existent. Was this replaced by something else? All the solutions that don't involve 'nand write.yaffs2' involve booting to Linux and mounting /dev/mtdblockX... Which doesn't really work when you don't a root filesystem (No Ethernet, USB doesn't work right yet (can't get a kernel to recognize the USB pen drive, although u-boot does quite nicely). So what's a user to do? I'm persevering, googling, compiling, programming, examining source... But I don't see how one gets a YAFFS2 image into NAND from a u-boot + serial console method. --jc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Missing __udivdi3 for ARM
I enabled CONFIG_YAFFS2 for ARM, and got the following message: /home/user/u-boot/fs/yaffs2/yaffscfg.c:185: undefined reference to `__udivdi3' I know some other math routines have been fixed, is there a patch for this one? A few minutes of searching found some things from 2007-July, but it seemed to be refactoring the code rather than adding the function. Thanks, --jc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM compiliation failing due to missing __lshrdi3 / EABI version conflict
The patches you just committed did the job, thank you. And, yes, I DID read the thread to it's conclusion. It wasn't helpful. I wasn't planning on becoming familiar with u-boot internals, but thanks to TI, it's become a necessity. --jc On Sun, Jul 26, 2009 at 6:04 PM, Wolfgang Denk wrote: > Dear "J.C. Wren", > > In message <17434f2e0907261449o704a2544jfa3c2575dbd6d...@mail.gmail.com> > you wrote: > > > > I've pulled the most recent git version of u-boot, intending to compile > it > > for ARM. Setting the target for davinci_dvevm and compiling caused the > > linker to throw an error regarding EABI conflicts. I removed libgcc from > > the Makefile, and it appears that drivers/mtd/nand_base.c, > > drivers/mtd_nand_oob.c and drivers/mtd/nand_bbt.c are looking for > __lshrdi3. > > > > I found the thread originated by Jean-Christophe Plagniol-Villard ( > > http://www.mail-archive.com/u-boot@lists.denx.de/msg15910.html) > regarding > > some architectures having a libgcc dependency, and whether that should be > > removed globally or on a per-build basis. > > Hm... why didn't you read the thread to it's (current) end? > > > I attempted to apply his patch, but the git repository seems to have seen > > enough changes where it won't sync, and also I don't have an > > arm_config.mkfile. Perhaps this was a copy of > > config.mk, but I still can't get it to sync on the patches. > > > > What my resolution path for this problem? > > Apply >[PATCH v2] Make linking against libgcc configurable > and >[PATCH] arm: add _lshrdi3.S > > or wait for -rc1 > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > A secure program has to be robust: it must be able to deal with > conditions that "can't happen", whether user input, program error or > library/etc. This is basic damage control. Buffer overflow errors > have nothing to do with security, but everything with stupidity. > -- Wietse Venema in <5cnqm3$...@spike.porcupine.org> > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] nand_bbt: Out of memory for large block NAND
The NAND bad block code is throwing an error at startup of 'nand_bbt: Out of memory' for large block NAND flash (block size of 128K). The vmalloc() call is trying to allocate 135,168 bytes. CONFIG_SYS_MALLOC_LEN is (0x1 + 128*1024). Bumping CONFIG_SYS_MALLOC_LEN to (0x2 + 128*1024) wasn't sufficient, however (0x4 + 128*1024) was. Any recommendations what this should be adjusted to? The system has 256MB of RAM and a single 512MB NAND. --jc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM compiliation failing due to missing __lshrdi3 / EABI version conflict
I've pulled the most recent git version of u-boot, intending to compile it for ARM. Setting the target for davinci_dvevm and compiling caused the linker to throw an error regarding EABI conflicts. I removed libgcc from the Makefile, and it appears that drivers/mtd/nand_base.c, drivers/mtd_nand_oob.c and drivers/mtd/nand_bbt.c are looking for __lshrdi3. I found the thread originated by Jean-Christophe Plagniol-Villard ( http://www.mail-archive.com/u-boot@lists.denx.de/msg15910.html) regarding some architectures having a libgcc dependency, and whether that should be removed globally or on a per-build basis. I attempted to apply his patch, but the git repository seems to have seen enough changes where it won't sync, and also I don't have an arm_config.mkfile. Perhaps this was a copy of config.mk, but I still can't get it to sync on the patches. What my resolution path for this problem? Thanks, --jc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
