license
feature is enabled by the board-level config. I think this will be
a minority case.
2) compilation of native programs has already to be possible since there
are other native tools such as mkimage built during the compilation
Cheers,
--
- Harald Welte <[EMAIL PROTECTED]&g
even
_before_ that code was ever merged into the respective mainline git
tree.
So is this really the preferred workflow? How are others dealing with
this? How to avoid commitlog pollution?
> Applied, thanks.
thanks!
--
- Harald
On Wed, Jul 09, 2008 at 10:42:31AM -0400, Jerry Van Baren wrote:
> Harald Welte wrote:
>> Hi!
>>
>> Since there has been support by Detlev and Stefan, I have modified the
>> patch in a way to dynamically create the include/license.h file from the
>> COPYING file by
vent inadvertent GPL violations, since the GPLv2 license text
can no longer be 'forgotten' to be included into the product.
The 'license' command can be enabled by CONFIG_CMD_LICENSE.
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
diff --git a/Makefile b/Makefile
inde
mand so we have just one interface to manipulate the
> "mtdparts" variable.
ok, no problem with that, I will change this before re-sending the patch
(against u-boot-nand-flash/testing).
Cheers,
--
- Harald Welte <[EMAIL PROTECTED]> http://openmoko.org
'dynenv set {offset,partition-name}' allows the setting of the
marker by specifying a numeric offset or a partition name.
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
diff --git a/common/Makefile b/common/Makefile
index ecf755f..d1d50bf 100644
--- a/common/Makefile
+++ b/
is something quite useful
(if not neccessarry) for the economic large-scale production of
NAND-flash only devices. We can always talk about the implementation
details, and I'm willing to address any feedback regarding it.
> > 3) the standard regular partition table is stor
On Wed, Jul 09, 2008 at 01:28:42PM +0800, Harald Welte wrote:
> >> Therefore, I still believe that such a feature is useful and should be
> >> merged into u-boot. If there are problems with my particular
> >> implementation, I'm happy to address them.
> >
x27;ll base that also on top of nand-flash/testing and submit later. Will
probably need some generalization for the board-level integration.
Cheers,
--
- Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/
===
the first (known-always-good) nand flash block
During boot, the regular mechanism of passing 'mtdparts' to the kernel
is used.
This was the most elegant scheme that I could come up with to support
a large number of factory-bad blocks at any given location in the flash
while still keepi
p of the dynenv patch.
Linux has no need to support it, since it gets the device-unique
partition table passed by the standard commandline mtdparts mechanism.
--
- Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/
On Mon, Jul 07, 2008 at 01:47:24PM -0500, Scott Wood wrote:
> On Mon, Jul 07, 2008 at 12:28:12AM +0800, Harald Welte wrote:
> > I've first sent this on Feb 17, 2007. Unfortunately no reply was
> > received. I think this is a quite useful feature, since a compile time
>
c6400 might be identical, so we'd end up having code in
cpu/arm920t/s3c24xx/ including/linking to code in cpu/arm1136/s3c64xx...
I'll probably end up with something like
cpu/arm920t/s3c24xx 2400, 2410, 2412, 24a0, 2460, 2440, 2442, 2443
cpu/s3c/generic stuff that i
.h
=======
--- u-boot.orig/include/environment.h
+++ u-boot/include/environment.h
@@ -117,4 +117,7 @@
/* Function that updates CRC of the enironment */
void env_crc_update (void);
+/* [re]set to the
drivers that are completely
> fixed for a specific configuration, too.
good.
> What exactly was your problem?
I didn't want to submit a driver that doesn't implement the
standard/full interface of a framebuffer driver inside u-boot without
asking whether that was actually ok.
--
- Har
and config.h itself only includes
board/foobar/config.h, i.e. there is no generic header file which gets
preprocessed after the board-level config is included and which is still
included from config.h. Should I invent one? I'm usually careful with
doing things differently than it is alrea
default_env instead of own copy
include/environment.h: added default_env prototype
Signed-off-by: Werner Almesberger <[EMAIL PROTECTED]>
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
Index: u-boot/common/env_common.c
=
first configuration, no matter what
wValue is being passed.
* GET_DESCRIPTOR/CONFIGURATION always returned the descriptor for the first
configuration (index 0).
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
diff --git a/drivers/usb/usbdcore.c b/drivers/usb/usbdcore.c
index 65a5724..a
ts on this?
[1] =
http://git.denx.de/?p=u-boot/u-boot-s3c24xx.git;a=blob;f=cpu/arm920t/start.S;h=3c542d43fb2a2907bd6043c99e5f071dde29844b;hb=HEAD
--
- Harald Welte <[EMAIL PROTECTED]> http://lafo
configured
by board-specific platform data.
Also, there are many LCM controller parameters that don't fit into the
classical modeline from the CRT world. I'm having a hard time imagining
how those parameters should be passed around...
What do you think?
Cheers,
--
- Harald Welte <
1 /* in a SAMSUNG S3C2410 SoC
*/
+#defineCONFIG_S3C24xx 1 /* in a SAMSUNG S3C24xx family
*/
#define CONFIG_SMDK24101 /* on a SAMSUNG SMDK2410 Board
*/
/* input clock of PLL */
--
- Harald Welte <[EMAIL PROTECT
fset in the NAND
OOB data of block 0. We can do this in case the vendor makes a guarantee that
block 0 never is a factory-default bad block.
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
Index: u-boot/common/Makefile
===
--- u
se text included with U-Boot.
Ok, I agree. Let's wait for the further comments on the list. If I
have the feeling that such a feature would be accepted, I'll re-work the
patch to include a script and makefile hooks to generate the header f
do_nand: add command "nand createbbt" to erase NAND and create a new BBT
Signed-off-by: Werner Almesberger <[EMAIL PROTECTED]>
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
---
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index bb46f34..2f41157 100644
--- a
openmoko products.
Signed-off-by: Werner Almesberger <[EMAIL PROTECTED]>
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
---
diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 748b266..27d5988 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/driv
ssed by the end user,
this helps to prevent inadvertent GPL violations, since the GPLv2 license text
can no longer be 'forgotten' to be included into the product.
The 'license' command can be enabled by CONFIG_CMD_LICENSE.
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
[PATCH] add new 'unzip' command to u-boot commandline
common/cmd_mem.c: new command "unzip srcaddr dstaddr [dstsize]" to unzip from
memory to memory, and option CONFIG_CMD_UNZIP to enable it
Signed-off-by: Werner Almesberger <[EMAIL PROTECTED]>
Signed-off-by: Hara
done by u-boot is not the source of the problem,
but rather some faulty hardware. lowering the clock is merely
a workaround and not a fix.
I think any further debugging would be very specific to your hardware
design.
--
- Harald Welte <[EMAIL PROTECTED]> http://laforge.gnumonks.or
PU core at
100MHz and re-try. If the memory check and/or system boot works this
way, you can try to increase the timings incrementally up to your
desired configuration.
--
- Harald Welte <[EMAIL PROTECTED]> http://laforge.gnumonks.org/
==
oblem ;)
I think it makes a lot of sense to add LZMA support to u-boot, but
obviously in a clean, consistent, documented way. It doesn't hurt, will
not be compiled unless explicitly selected, and the API is zlib like,
i.e. the code changes it requires a
he program counter with the content it should have according to the
uImage/zImage/vmlinux file of th kernel.
--
- Harald Welte <[EMAIL PROTECTED]> http://laforge.gnumonks.org/
"Privacy in residential applic
GPIO configuration for
the RTS/CTS pins, missing connection on the board, broken serial cable.
Basically anthing that affects RTS/CTS from within the s3c24xx and the
PC on the other side.
--
- Harald Welte <[EMAIL PROTECT
Hi Stefan!
On Mon, Mar 17, 2008 at 02:54:00PM +0100, Stefan Roese wrote:
> On Tuesday 22 January 2008, Harald Welte wrote:
> > > >breaks any of the old code. It has actually come to a point where
> > > >I'd volunteer to maintain the s3c24xx chipset code
On Mon, Feb 04, 2008 at 11:55:47PM +0100, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > This patch adds NAND support to the S3C24x0 SoC code in u-boot
> >
> > Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
>
> Applied, thanks
ersion, as far as I remember.
Cheers,
--
- Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
org/wiki/Bootloader_commands
helpful.
Cheers,
--
- Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/
"Privacy in residential applications is a desirab
heir patchs are not placed
> correctly in u-boot's directory;
The patchset in question is a 'quilt' patchset, and all you have to do
is
1) check out latest u-boot.git
2) check out the patchset and put it in a 'patches' subdirectory
3) do 'quilte push -a'
e
> advices,thanks.
the patchset in http://svn.openmoko.org/trunk/src/target/u-boot/patches/
supports exactly this CPU with full boot-from-nand support. Please
check the gta02 board configuration in that patchset.
--
- Harald Welte <[EMAIL PROTECTED]>
te a number of people use their own stuff, or whatever
configuration of OpenEmbedded, or OpenWRT, or even something else.
Is there somewhere a list of the toolchains that the code has to compile
against, including pointers on where to obtain them?
And while we're at it,
I have working (and
creating the generic/common code. This
> >is not pure laziness, but inexperience with the code and lack of
> >access to all the different hardware
>
> Well, someone has to go ahead...
yes, of course. But you need somebody who is voluntarily committed to
doin
;
This is entirely true. Usually those questions are raised on the (now
defunct) openmoko-uboot list, that has been superseded by
openmoko-kernel.
Cheers,
--
- Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/
=
those patches are against current git head of u-boot. What gave you the
assumption that the patches are agains 1.1.6?
--
- Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/
Software for the
42 matches
Mail list logo
