Fill in remaining MTD driver data for OneNAND.
Review onenand_print_device_info():
- Return device info to fill mtd device name.
- Remove verbose parameter as it become useless.
Signed-off-by: Fathi Boudra <[EMAIL PROTECTED]>
---
diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c
index ce9
Wolfgang Denk a écrit :
> That's why I think we should have an explicit "builtin" command, i. e.
> command with the name "builtin" that will always run the corresponding
> builtin command, no if there is a "command alias" or not - similar to
> the bash command
... and make sure that one can *neve
JFFS2 command support on OneNAND.
- Fix typo.
- Fix nand_bbt_descr redefinition when NAND and OneNAND are enabled.
Since last comments:
- Add some CONFIG_CMD_ONENAND to prevent adding new code.
- Fix line too long.
- Revert mtd device types definition.
TODO: Use NAND command interface (e.g.: par
In message <[EMAIL PROTECTED]> you wrote:
>
> That would be REALLY cool! It would take some initial work, but the
> reward would be really simple and transparent expandability for the
> command set. As with the "bootm" command, we might end up with simpler
> code (I don't think too many comman
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> My current best thought is to create a new "boot simple" (boots?
>> bootsm?) command that contains only the essence of bootm. I would then
>> change the command "bootm" to do a hush script run of the env variable
>> "bootm" (i.
Kumar Gala wrote:
> If we really want to simplify what bootm does than I think we should
> remove ft_board_setup() from lib_ppc/bootm.c and expect any actually
> modification of the device tree to have already occurred.
>
> Is this something we'd really be willing to do?
>
> - k
I don't thin
In message <[EMAIL PROTECTED]> you wrote:
>
> My current best thought is to create a new "boot simple" (boots?
> bootsm?) command that contains only the essence of bootm. I would then
> change the command "bootm" to do a hush script run of the env variable
> "bootm" (i.e. the command "bootm" wo
Hi,
> > TODO: Use NAND command interface (e.g.: part_validate_*nand()).
>
> Do you mean merging the NAND and OneNAND versions of the jffs2
> code, through the (mostly already existing) function pointer
> interface?
yes, as you suggested to kyungmin: use mtd_info function pointer interface.
> I'd
On Mon, Aug 4, 2008 at 9:02 PM, Becky Bruce <[EMAIL PROTECTED]> wrote:
> Currently, they use CONFIG_NUM_CPUS, which is different than
> 85xx for no good reason.
>
> --- a/include/configs/MPC8610HPCD.h
> +++ b/include/configs/MPC8610HPCD.h
> @@ -17,7 +17,7 @@
> #define CONFIG_MPC86xx 1
Wolfgang Denk wrote:
>> One minor flaw, I don't see how "bootm" the env script could run "bootm"
>> the built-in command, because it would instead recursively run "bootm"
>> the env script if scripts have higher priority and the command line
>> "bootm" would run the built-in "bootm" if scripts h
On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> My current best thought is to create a new "boot simple" (boots?
>> bootsm?) command that contains only the essence of bootm. I would
>> then
>> change the command "bootm" to do a hush script run
In message <[EMAIL PROTECTED]> you wrote:
>
> > That's why I think we should have an explicit "builtin" command, i. e.
> > command with the name "builtin" that will always run the corresponding
> > builtin command, no if there is a "command alias" or not - similar to
> > the bash command
>
> ...
On Mon, 4 Aug 2008, Scott Wood wrote:
> On Mon, Aug 04, 2008 at 02:45:33PM +0200, Guennadi Liakhovetski wrote:
> > I _think_ this should work with all NAND chips. Otherwise we might have to
> > introduce a configuration variable.
>
> Which small-page NAND chips can't handle READOOB? On large pa
Version 5: This time based on nand-flash/testing head. Therefore it
couldn't be runtime-tested: largepage support in nand_spl is broken there
ATM. Otherwise all comments have been taken care of. After nand_spl is
fixed for largepage NAND devices, this will be tested, if needed, v6 will
be submi
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
drivers/mtd/jedec_flash.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index 9845e93..020647a 100644
--- a/drivers/mtd/jedec_flash.c
+++ b
We have to read a whole page on large-page NAND chips, at least the chip
installed on SMDK6400 can only read whole pages with READ0. Also activate
chipselect before using the chip, and deactivate it afterwards.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
nand_spl/nand_boot.c |
Notice: USB on S3C6400 currently works _only_ with switched off MMU. One could
try to enable the MMU, but map addresses 1-to-1, and disable data cache, then
it should work too and we could still profit from instruction cache.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
cpu/arm117
Based on the original S3C64XX UART driver by Samsung for U-Boot 1.1.6.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
drivers/serial/Makefile |1 +
drivers/serial/s3c64xx.c | 197 ++
2 files changed, 198 insertions(+), 0 deletions(-)
Kumar Gala wrote:
> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
[snip]
>> One idea that has been spinning in my mind for some time is to make
>> the "run" command to execute the content of an environment variable
>> optional. Instead, we could try and handle environment variable names
>>
Based on the original S3C64XX NAND driver by Samsung for U-Boot 1.1.6.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/s3c64xx.c | 305
2 files changed, 306 insertions(+), 0 deletions(
SMDK6400 can only boot U-Boot from NAND-flash. This patch adds a nand_spl
driver for it too. The board can also boot from the NOR flash, but due to
hardware limitations it can only address 64KiB on it, which is not enough
for U-Boot. Based on the original sources by Samsung for U-Boot 1.1.6.
Signe
Wolfgang Denk a écrit :
> In message <[EMAIL PROTECTED]> you wrote:
>>> That's why I think we should have an explicit "builtin" command, i. e.
>>> command with the name "builtin" that will always run the corresponding
>>> builtin command, no if there is a "command alias" or not - similar to
>>> the
On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
>
> [snip]
>
>>> One idea that has been spinning in my mind for some time is to
>>> make
>>> the "run" command to execute the content of an environment
>>> variable
>
Hi,
> Wolfgang Denk wrote:
>>> One minor flaw, I don't see how "bootm" the env script could run "bootm"
>>> the built-in command, because it would instead recursively run "bootm"
>>> the env script if scripts have higher priority and the command line
>>> "bootm" would run the built-in "bootm" i
In message <[EMAIL PROTECTED]> you wrote:
>
> Yes, that is Wolfgang's (and my) proposal: rationalize the built-in
> "bootm" to do just #6. Steps 1-5 already exist as built-in commands or
> commands could be created almost trivially to invoke the existing code.
> The current "bootm" behavior
Can we drop any functionality from the current bootm?
For example does powerpc still need to support bd_t based booting?
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Li
here's a rough start at an outline for the bootm script based on the
code (I've only outlined the Linux/PPC boot case its seems the most
complicated). One of the first things we clearly need is a imload
command. Thoughts on the various disable_{interrupts, usb, caches} ?
- k
bootm script:
In message <[EMAIL PROTECTED]> you wrote:
> Can we drop any functionality from the current bootm?
Any? You mean:
int bootm (...)
{
return 0;
}
:-)
> For example does powerpc still need to support bd_t based booting?
Yes, of course we need this. There is
On Aug 5, 2008, at 9:45 AM, Wolfgang Denk wrote:
> In message
> <[EMAIL PROTECTED]> you wrote:
>> Can we drop any functionality from the current bootm?
>
> Any? You mean:
>
> int bootm (...)
> {
> return 0;
> }
>
> :-)
if it were only so easy :)
>> For example
On Tue, Aug 05, 2008 at 03:08:04PM +0200, Guennadi Liakhovetski wrote:
> It's a large-page device. And, as far as I understand the datasheet, to
> read data at arbitrary offset in a page, you first have to issue a READ
> PAGE (READ0) for _the_ _whole_ page, then you can use RANDOM DATA READ to
>
On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
>
> [snip]
>
>>> One idea that has been spinning in my mind for some time is to
>>> make
>>> the "run" command to execute the content of an environment
>>> variable
>
On Tue, Aug 05, 2008 at 03:36:33PM +0200, Guennadi Liakhovetski wrote:
> Version 5: This time based on nand-flash/testing head. Therefore it
> couldn't be runtime-tested: largepage support in nand_spl is broken there
> ATM.
Hmm, so it is. I don't have hardware that uses the cmd_ctrl interface t
On Tue, 5 Aug 2008, Scott Wood wrote:
> On Tue, Aug 05, 2008 at 03:36:33PM +0200, Guennadi Liakhovetski wrote:
> > Version 5: This time based on nand-flash/testing head. Therefore it
> > couldn't be runtime-tested: largepage support in nand_spl is broken there
> > ATM.
>
> Hmm, so it is. I don
On Tue, Aug 05, 2008 at 03:36:43PM +0200, Guennadi Liakhovetski wrote:
> /*
> - * offs has to be aligned to a block address!
> + * offs has to be aligned to a page address!
>*/
> block = offs / CFG_NAND_BLOCK_SIZE;
> + /* Recalculate offs as an offset inside a bloc
On Tue, 5 Aug 2008, Scott Wood wrote:
> On Tue, Aug 05, 2008 at 03:08:04PM +0200, Guennadi Liakhovetski wrote:
> > It's a large-page device. And, as far as I understand the datasheet, to
> > read data at arbitrary offset in a page, you first have to issue a READ
> > PAGE (READ0) for _the_ _whole
Guennadi Liakhovetski wrote:
> On Tue, 5 Aug 2008, Scott Wood wrote:
>> Are you saying that your NAND chip can't read the OOB by issuing READ0
>> with the appropriate column address? Which chip is this, and where can I
>> find a manual?
>
> At least, this is how I understood it, I might be wrong
boot_get_ramdisk() should not treat the case when a FIT image does not contain
a ramdisk as an error.
Signed-off-by: Peter Tyser <[EMAIL PROTECTED]>
---
The original code would not allow booting of a FIT image which didn't contain a
ramdisk. The bug was observed and fixed on a powerpc 85xx syst
Kumar Gala wrote:
>
> On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
>
>> Kumar Gala wrote:
>>> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
[snip]
What do you think?
>>> While this is a cleaner implementation of what I've implemented w/
>>> ft_env_setup() it still doesn't complet
Also, remove the ctrl variable in favor of passing the constants
directly, and remove redundant (u8) casts.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
This patch is untested, as I don't have the hardware.
Applied to u-boot-nand-flash/testing.
nand_spl/nand_boot.c | 50 ++
[snip]
>> As I look at this more and more I think trying to re-encode the
>> control flow of the bootm command in a script is just insane.
>> There are too many special cases we have to deal with that we'd
>> just being moving from C code into the script.
>
> My assumption is that a given b
On Tue, Aug 05, 2008 at 11:06:28AM +0200, Fathi BOUDRA wrote:
> -void onenand_print_device_info(int device, int verbose)
> +char * onenand_print_device_info(int device)
> {
> int vcc, demuxed, ddp, density;
> -
> - if (!verbose)
> - return;
> + char *dev_info;
>
>
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree after
ft_board_setup() and before the tree is handled to the kernel.
The idea is that users may want to add or manipulate nodes w/changing the
u-boot binary. The curre
On Aug 5, 2008, at 11:50 AM, Kumar Gala wrote:
> Added the 'fdtcmd' environment variable as a way to provide 'fdt'
> commands
> that the user can supply to manipulate the device tree after
> ft_board_setup() and before the tree is handled to the kernel.
>
> The idea is that users may want to ad
On Tue, 5 Aug 2008, Scott Wood wrote:
> Also, remove the ctrl variable in favor of passing the constants
> directly, and remove redundant (u8) casts.
>
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
> ---
> This patch is untested, as I don't have the hardware.
> Applied to u-boot-nand-flash/test
Guennadi Liakhovetski wrote:
>> /* Begin command latch cycle */
>> -this->cmd_ctrl(mtd, cmd, ctrl);
>> +this->cmd_ctrl(mtd, cmd, NAND_CTRL_CLE | NAND_CTRL_CHANGE);
>
> [snip]
>
> See? you do the same! You replace short lowercase variable with long
> uppercase macros:-)
:-)
Yes, b
On Aug 5, 2008, at 7:03 AM, Andy Fleming wrote:
> On Mon, Aug 4, 2008 at 9:02 PM, Becky Bruce
> <[EMAIL PROTECTED]> wrote:
>> Currently, they use CONFIG_NUM_CPUS, which is different than
>> 85xx for no good reason.
>>
>
>
>> --- a/include/configs/MPC8610HPCD.h
>> +++ b/include/configs/MPC8610HP
In message <[EMAIL PROTECTED]> you wrote:
> Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
> that the user can supply to manipulate the device tree after
> ft_board_setup() and before the tree is handled to the kernel.
>
> The idea is that users may want to add or manip
On Aug 5, 2008, at 4:40 PM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]>
> you wrote:
>> Added the 'fdtcmd' environment variable as a way to provide 'fdt'
>> commands
>> that the user can supply to manipulate the device tree after
>> ft_board_setup() and before the tree is handled to
Is this something we'd be willing to put into mainline?
- k
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index a872d31..3ebddd3 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -192,7 +192,8 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
}
#ifdef CO
In message <[EMAIL PROTECTED]> you wrote:
> Is this something we'd be willing to put into mainline?
Definitely not as is.
These are two unrelated changes, so please split this up into two
separate patches so we can decide independently.
Best regards,
Wolfgang Denk
--
DENX Software Engineerin
I have enabled nfs booting on ppc based embedded board. I had placed my
kernel and rootfs in tftp directory, and had set the u-boot enivironment
varialbes as:
setenv bootfile /image/kernel
setenv root_path /tftpboot/image
The board was booting with this configuration...
Now I have pla
Kumar Gala wrote:
> here's a rough start at an outline for the bootm script based on the
> code (I've only outlined the Linux/PPC boot case its seems the most
> complicated). One of the first things we clearly need is a imload
> command. Thoughts on the various disable_{interrupts, usb, cac
On ADS5121 when booting linux the following errors are seen:
Unable to update property /[EMAIL PROTECTED]:bus-frequency,
err=FDT_ERR_NOTFOUND
Unable to update property /[EMAIL PROTECTED]/[EMAIL
PROTECTED]:local-mac-address, err=FDT_ERR_NOTFOUND
Unable to update property /[EMAIL PROTEC
On Tue, Aug 5, 2008 at 7:24 PM, cjjoy1980 <[EMAIL PROTECTED]> wrote:
>
> I have enabled nfs booting on ppc based embedded board. I had placed my
> kernel and rootfs in tftp directory, and had set the u-boot enivironment
> varialbes as:
> setenv bootfile /image/kernel
> setenv root_path /tftpbo
Moving the interrupt vectors to low memory can cause issues if the code
gets overwritten via some image loading command (tftp, boot*, etc.) and
interrupts (like the decrementer are enabled).
On 85xx there is no reason to copy the interrupt vectors to low memory
since we can run them in high memory
Its useful to know where the device tree is if we have set 'autostart'
to 'no. We come back to the prompt after a boot command and we can
than post process the device tree but we need to know where it was put
report this back via the env variable 'bootm_fdtaddr'.
Signed-off-by: Kumar Gala <[EMAIL
Add a boot command that supports the ePAPR client interface on powerpc.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
lib_ppc/bootm.c | 63 +++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm
if the environment variable 'disable_fdt_boardsetup' is set we skip
doing the ft_board_setup().
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
lib_ppc/bootm.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index 1182c50..a5b3a45 100
Hi,
TFTP Server running on your system needs to be configured when you change
the directory.
If you have installed xinetd, the configuration files are stored in
/etc/xinetd.d/ folder
edit /etc/xinetd.d/tftp & change the server_args to pint to new directory
[root @linux]# vi /etc/xinetd.d/tft
In message <[EMAIL PROTECTED]> you wrote:
> Moving the interrupt vectors to low memory can cause issues if the code
> gets overwritten via some image loading command (tftp, boot*, etc.) and
> interrupts (like the decrementer are enabled).
Oops? This is expected and normal behaviour. Did anybody co
60 matches
Mail list logo
