Re: [U-Boot] R: USB EHCI driver
Hi Francesco Great Job!!! I am in process doing the same for Marvell Kirkwood Hopefully your patch will find useful for me Regards... Prafulla . . -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Rendine Francesco Sent: Tuesday, June 23, 2009 8:32 PM To: Michael Trimarchi; Gupta Maneesh-B18878 Cc: u-boot@lists.denx.de Subject: [U-Boot] R: USB EHCI driver Hi all, I'm successful in provide a preliminary support to EHCI USB Freescale controller integrated on ADS5121 platform. I'm preparing a patch to submit to u-boot mailing list. Regards, Francesco. -Messaggio originale- Da: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it] Inviato: gio 4/9/2009 7:50 A: Gupta Maneesh-B18878 Cc: Rendine Francesco; u-boot@lists.denx.de Oggetto: Re: [U-Boot] USB EHCI driver Hi, Gupta Maneesh-B18878 wrote: Hi Francesco, Could you make any progress? Regards Maneesh -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Michael Trimarchi Sent: Monday, March 23, 2009 2:46 PM To: Rendine Francesco Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] USB EHCI driver Hi, Rendine Francesco wrote: Hi, I've already tried that define, but nothing is changed... What can I see in the USB driver to resolve issue? Thanks. -Original Message- From: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it] Sent: Fri 3/20/2009 9:36 AM To: Rendine Francesco Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] USB EHCI driver Hi, FrancescoVT wrote: usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 dev=1ffebb08, pipe=8883, buffer=1f9a671a, length=64, req=1ffea214 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 EHCI fail timeout STD_ASS reset usb_new_device: usb_get_descriptor() failed #define CONFIG_LEGACY_USB_INIT_SEQ Michael Sorry I can't help you without the board :( and now I don't have another board to test to verify it. I'm working on android, and some migor issue. Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot I don't ask anymore because I'm busy, BTW good question Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91sam9260/9263: add back up fot the rst(reset controller).
Stelian Pop a écrit : On Tue, Jun 23, 2009 at 12:46:50PM +0200, Sedji Gaouaou wrote: On the boards at91sam9260ek, at91sam9263ek and afed9260, the rstc register was set to 0 after being set to 500 ms for the PHY reset. Now if back up is enable it will be set to the saved value. The changelog message is not very clear. What means if backup is enabled ? I don't see anything in the patch which can be enabled or disabled... To enable the back up you need to put a battery, so if there is no battery there is no back up...that is why I said if back up is enable :) I think you meant something like: Do backup the old reset length and restore it after the MACB initialisation. But you comment is better, so I will change it. +rstc = at91_sys_read(AT91_RSTC_MR); [...] /* Restore NRST value */ at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY | - AT91_RSTC_ERSTL | (0x0 8) | + (rstc) | AT91_RSTC_URSTEN); Also, I don't like this: you backup in 'rstc' the _whole_ contents of the MR register (including for example the URSTEN bit), but on restore you still construct a bit mask... In order to be consistent, I would do either: rstc = at91_sys_read(AT91_RSTC_MR); ... at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY | rstc); or rstc = at91_sys_read(AT91_RSTC_MR) AT91_RSTC_ERSTL; ... at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY | rstc | AT91_RSTC_URSTEN); I will change that to then. Regards, Sedji ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot 2009 for Freescale mpc5121
Hi All, I was able to compile and run the u-boot for my board from both cygwin and Linux. The only problem I had was the uboot.lds file that in the old version had the manual listing of the segments like this: *(.rodata) *(.rodata1) *(.rodata.str1.4) Now it uses a macro to sort them according to wildcard. I use gcc-3.4.3 for the MPC51xx provided by Freescale. Is there any newer version of the GNU toolchain that u-boot uses? If yes where do I get it? Regards, Stas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91sam9260/9263: add back up fot the rst(reset controller).
On the boards at91sam9260ek, at91sam9263ek and afed9260, the rstc register was
set to 0 after being set to 500 ms for the PHY reset.
Do backup the old reset length and restore it after the MACB initialisation.
Signed-off-by: Sedji Gaouaou sedji.gaou...@atmel.com
---
board/afeb9260/afeb9260.c |6 +-
board/atmel/at91sam9260ek/at91sam9260ek.c |6 +-
board/atmel/at91sam9263ek/at91sam9263ek.c |6 +-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/board/afeb9260/afeb9260.c b/board/afeb9260/afeb9260.c
index a247663..b9d0929 100644
--- a/board/afeb9260/afeb9260.c
+++ b/board/afeb9260/afeb9260.c
@@ -81,6 +81,8 @@ static void afeb9260_nand_hw_init(void)
#ifdef CONFIG_MACB
static void afeb9260_macb_hw_init(void)
{
+ unsigned long rstc;
+
/* Enable clock */
at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9260_ID_EMAC);
@@ -103,6 +105,8 @@ static void afeb9260_macb_hw_init(void)
pin_to_mask(AT91_PIN_PA28),
pin_to_controller(AT91_PIN_PA0) + PIO_PUDR);
+ rstc = at91_sys_read(AT91_RSTC_MR) AT91_RSTC_ERSTL;
+
/* Need to reset PHY - 500ms reset */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
AT91_RSTC_ERSTL | (0x0D 8) |
@@ -115,7 +119,7 @@ static void afeb9260_macb_hw_init(void)
/* Restore NRST value */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
-AT91_RSTC_ERSTL | (0x0 8) |
+(rstc) |
AT91_RSTC_URSTEN);
/* Re-enable pull-up */
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 6bd3b44..d7d60ba 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -86,6 +86,8 @@ static void at91sam9260ek_nand_hw_init(void)
#ifdef CONFIG_MACB
static void at91sam9260ek_macb_hw_init(void)
{
+ unsigned long rstc;
+
/* Enable clock */
at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9260_ID_EMAC);
@@ -108,6 +110,8 @@ static void at91sam9260ek_macb_hw_init(void)
pin_to_mask(AT91_PIN_PA28),
pin_to_controller(AT91_PIN_PA0) + PIO_PUDR);
+ rstc = at91_sys_read(AT91_RSTC_MR) AT91_RSTC_ERSTL;
+
/* Need to reset PHY - 500ms reset */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
(AT91_RSTC_ERSTL (0x0D 8)) |
@@ -120,7 +124,7 @@ static void at91sam9260ek_macb_hw_init(void)
/* Restore NRST value */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
-(AT91_RSTC_ERSTL (0x0 8)) |
+(rstc) |
AT91_RSTC_URSTEN);
/* Re-enable pull-up */
diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c
b/board/atmel/at91sam9263ek/at91sam9263ek.c
index 57d5c95..59c6a96 100644
--- a/board/atmel/at91sam9263ek/at91sam9263ek.c
+++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
@@ -91,6 +91,8 @@ static void at91sam9263ek_nand_hw_init(void)
#ifdef CONFIG_MACB
static void at91sam9263ek_macb_hw_init(void)
{
+ unsigned long rstc;
+
/* Enable clock */
at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9263_ID_EMAC);
@@ -108,6 +110,8 @@ static void at91sam9263ek_macb_hw_init(void)
pin_to_mask(AT91_PIN_PE26),
pin_to_controller(AT91_PIN_PE0) + PIO_PUDR);
+ rstc = at91_sys_read(AT91_RSTC_MR) AT91_RSTC_ERSTL;
+
/* Need to reset PHY - 500ms reset */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
(AT91_RSTC_ERSTL (0x0D 8)) |
@@ -120,7 +124,7 @@ static void at91sam9263ek_macb_hw_init(void)
/* Restore NRST value */
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
-(AT91_RSTC_ERSTL (0x0 8)) |
+(rstc) |
AT91_RSTC_URSTEN);
/* Re-enable pull-up */
--
1.5.3.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 88e61xx driver in u-boot
-Original Message-
From: Andrew Dyer [mailto:amd...@gmail.com]
Sent: Wednesday, June 24, 2009 4:55 AM
To: Prafulla Wadaskar; U-Boot List
Subject: 88e61xx driver in u-boot
Hi, I am in the midst of bringing up a board using the
88E6161 chip and was looking at your u-boot driver as an
example of how to set it up (still writing simple tests
loaded via JTAG, not the full u-boot).
Our board uses the indirect method of writing to the MII bus
registers, and I think there may be a bug in the indirect
version of mv88e61xx_rd_phy(). In the function, the command
written into the SMI indirect command register is:
86miiphy_write(name, mii_dev_addr, 0x0,
87 reg_ofs | (phy_adr 5) | (1 10) | (1
12) | (1
88
15));
The part that looks wrong is the 1 10 (the SMIOp field).
According to the datasheet table 35, for a read to be
performed inside the chip it should be 2 10. Probably cut
and pasted from the
mv88e61xx_wr_phy() above.
I have tested single chip addressing mode, Multichip addressing mode is not
tested for this driver, I am getting the board this weekend, I will check and
reply
But looking at your analysis, it seems to be copy paste error, I will correct
it.
Thanks
I also wondered about this snippet of code:
55 static void mv88e61xx_wr_phy(char *name, u32 phy_adr,
u32 reg_ofs, u16 data)
56 {
57 u16 reg;
58 u32 mii_dev_addr;
59
60 /* command to read PHY dev address */
61 if (!miiphy_read(name, 0xEE, 0xEE, mii_dev_addr)) {
62 printf(Error..could not read PHY dev
address\n);
63return;
64 }
I don't see anything in the 88E6161 switch itself that would
respond at those 0xEE addresses (IIRC the MII bus only
provides for 5 bits of register and phy address). Is this
something specific to the board/SoC you were running the
switch with and/or it's miiphy_read implementation?
As far as I can tell, what is needed is to set mii_dev_addr
to the address set by the ADDR[4:0] chip config pins, which
would see to be a board specific item, and shouldn't be in
the generic driver. This would seem like a good candidate
for something that is passed in via the mv88e61xx_config structure.
This command is mapped to the smi_reg_read function of SoCs eth controller
driver (kirkwood-egiga.c).
The 0xEE in this command is used to flag the above function to read-n-return
phy device address which is needed by switch for multi chip addressing.
Phy device address is decided by board hardware and same need to be programmed
for eth controller and switch for successful read/write.
In the current implementation phy address is provided to eth controller driver
from board config header.
During switch init which comes next, switch gets it from associated controller
though this interface
As you suggested, we can simply provide this through mv88e61xx_config
structure, but it may lead to configuration problems, providing same settings
at two different places, if there is mismatch one need to spend enough time
debugging the same (as I spend).
To avoid this I have implemented above method.
We do not have exposed api for the same in miiphy.h, this need to be supported
in miiphyutil
My next efforts will be expose miiphy_devadr_read/write api for the same.
Regards..
Prafulla ..
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocating to my code.
Hi Prathika, hi everyone, I am working on a card based on PPC440EP, I am porting u-boot on this card. As I understand, the PPC initially boots from the flash and then relocates itself to RAM address where there is board_init_r() and main_loop() is called. Correct. Running from flash makes writing to flash (i.e. updating images there) somewhat complicated. I have an application code that simply does a loop back on UART channel2. After all the initialization, I want to knock off the relocation code, board_init_r() and main_loop() execution in u-boot and relocate it to my application The application code will residing in flash. How can I do this anyone kindly help me in this regard... Why do you want to run from flash - what exactly are you trying to do? Did you think about the consequences, i.e. where will your code store local variables, etc.? Why do you want to use U-Boot in the first place if you do not want to use its main functionality? Cheers Detlev -- The mathematician's patterns, like the painter's or the poet's, must be beautiful; the ideas, like the colours or the words, must fit together in a harmonious way. Beauty is the first test: there is no permanent place in the world for ugly mathematics. -- G. H. Hardy -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM920T SMDK2440 support
Hi, everyone Is U-Boot not support ARM920T SMDK2440 board? Regards, J.H.Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] A320: driver for FTRTC010 real time clock
Hi Po-Yu Chuang,
Dear Jean-Christophe PLAGNIOL-VILLARD,
2009/6/24 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com:
+
+static volatile struct ftrtc010 *rtc = (struct ftrtc010
*)CONFIG_SYS_RTC_BASE;
+
+static void ftrtc_enable (void)
you use it at one please only the reset
Sorry, I don't understand what do you mean
I guess he means that he doesn't like functions which are only called
from one place - he'd rather like to see the code directly at the
callers site.
However I do not agree here - functions have also a documentation
effect, so I vote to keep the function. If neccessary, we could declare
the function inline, but this is really overkill here.
+{
+ rtc-cr = cpu_to_le32 (FTRTC010_CR_ENABLE);
so please move this code there
+}
+
+/*
+ * return current time in seconds
+ */
+static unsigned long ftrtc_time (void)
+{
+ unsigned long day;
+ unsigned long hour;
+ unsigned long minute;
+ unsigned long second;
+ unsigned long second2;
+
+ do {
+ second = le32_to_cpu (rtc-sec);
please use proper accessor
readl/writel
Should I use
second = readl(rtc-sec);
Yep.
Cheers
Detlev
--
BUGS:
It is not yet possible to change operating system by writing to
/proc/sys/kernel/ostype.
-- Linux sysctl(2) man page
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] R: USB EHCI driver
Hi Francesco, I'm successful in provide a preliminary support to EHCI USB Freescale controller integrated on ADS5121 platform. I'm preparing a patch to submit to u-boot mailing list. Congratulations - I'm also looking forward to see and test the patch on our ads5121. Cheers Detlev -- More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other to total extinction. Let us pray, we have the wisdom to choose correctly. -- Woody Allen -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] xscale: add support for the polaris board
The Polaris board is based on the TrizepsIV module of
Keith Koep (http://www.keith-koep.com).
Signed-off-by: Stefano Babic sba...@denx.de
---
MAINTAINERS |4
Makefile|7 ++-
board/trizepsiv/conxs.c | 27 +++
include/configs/trizepsiv.h | 28 +++-
4 files changed, 48 insertions(+), 18 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9379c7e..97476e9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -500,6 +500,10 @@ Rowel Atienza ro...@diwalabs.com
armadillo ARM720T
+Stefano Babic sba...@denx.de
+
+ trizepsiv xscale
+
Dirk Behme dirk.be...@gmail.com
omap3_beagleARM CORTEX-A8 (OMAP3530 SoC)
diff --git a/Makefile b/Makefile
index acec1a0..3a77988 100644
--- a/Makefile
+++ b/Makefile
@@ -3082,8 +3082,13 @@ scpu_config: unconfig
pxa255_idp_config: unconfig
@$(MKCONFIG) $(@:_config=) arm pxa pxa255_idp
+polaris_config \
trizepsiv_config : unconfig
- @$(MKCONFIG) $(@:_config=) arm pxa trizepsiv
+ @mkdir -p $(obj)include
+ @if [ $(findstring polaris,$@) ] ; then \
+ echo #define CONFIG_POLARIS 1 $(obj)include/config.h ; \
+ fi;
+ @$(MKCONFIG) -a trizepsiv arm pxa trizepsiv
wepep250_config: unconfig
@$(MKCONFIG) $(@:_config=) arm pxa wepep250
diff --git a/board/trizepsiv/conxs.c b/board/trizepsiv/conxs.c
index 5c0eb41..8c11456 100644
--- a/board/trizepsiv/conxs.c
+++ b/board/trizepsiv/conxs.c
@@ -44,13 +44,18 @@ extern struct serial_device serial_ffuart_device;
extern struct serial_device serial_btuart_device;
extern struct serial_device serial_stuart_device;
+#if CONFIG_POLARIS
+#define BOOT_CONSOLE serial_stuart
+#else
+#define BOOT_CONSOLE serial_ffuart
+#endif
/* - */
/*
* Miscelaneous platform dependent initialisations
*/
-void usb_board_init(void)
+int usb_board_init(void)
{
UHCHR = (UHCHR | UHCHR_PCPL | UHCHR_PSPL)
~(UHCHR_SSEP0 | UHCHR_SSEP1 | UHCHR_SSEP2 | UHCHR_SSE);
@@ -71,6 +76,8 @@ void usb_board_init(void)
/* Set port power control mask bits, only 3 ports. */
UHCRHDB |= (0x717);
+
+ return 0;
}
void usb_board_init_fail(void)
@@ -89,7 +96,6 @@ void usb_board_stop(void)
CKEN = ~CKEN10_USBHOST;
- puts(Called USB STOP\n);
return;
}
@@ -112,17 +118,14 @@ int board_late_init(void)
#if defined(CONFIG_SERIAL_MULTI)
char *console=getenv(boot_console);
- if ((strcmp(console,serial_btuart) == 0) ||
- (strcmp(console,serial_stuart) == 0) ||
- (strcmp(console,serial_ffuart) == 0)) {
- setenv(stdout,console);
- setenv(stdin, console);
- setenv(stderr,console);
- } else {
- setenv(stdout, serial);
- setenv(stdin, serial);
- setenv(stderr, serial);
+ if ((console == NULL) || (strcmp(console,serial_btuart)
+ strcmp(console,serial_stuart)
+ strcmp(console,serial_ffuart))) {
+ console = BOOT_CONSOLE;
}
+ setenv(stdout,console);
+ setenv(stdin, console);
+ setenv(stderr,console);
#endif
return 0;
}
diff --git a/include/configs/trizepsiv.h b/include/configs/trizepsiv.h
index bfa7157..170d080 100644
--- a/include/configs/trizepsiv.h
+++ b/include/configs/trizepsiv.h
@@ -93,7 +93,6 @@
#undef CONFIG_SHOW_BOOT_PROGRESS
#define CONFIG_BOOTDELAY 3
-#define CONFIG_SERVERIP192.168.1.99
#define CONFIG_BOOTCOMMAND run boot_flash
#define CONFIG_BOOTARGSconsole=ttyS0,38400
ramdisk_size=12288\
rw root=/dev/ram initrd=0xa080,5m
@@ -239,11 +238,17 @@
#define CONFIG_SYS_GRER1_VAL 0x
#define CONFIG_SYS_GRER2_VAL 0x
#define CONFIG_SYS_GRER3_VAL 0x
-#define CONFIG_SYS_GFER0_VAL 0x
+
#define CONFIG_SYS_GFER1_VAL 0x
-#define CONFIG_SYS_GFER2_VAL 0x
#define CONFIG_SYS_GFER3_VAL 0x0020
+#if CONFIG_POLARIS
+#define CONFIG_SYS_GFER0_VAL 0x0001
+#define CONFIG_SYS_GFER2_VAL 0x0020
+#else
+#define CONFIG_SYS_GFER0_VAL 0x
+#define CONFIG_SYS_GFER2_VAL 0x
+#endif
#define CONFIG_SYS_PSSR_VAL0x20/* CHECK */
@@ -259,7 +264,11 @@
#define CONFIG_SYS_MSC0_VAL0x4df84df0
#define CONFIG_SYS_MSC1_VAL0x7ff87ff4
+#if CONFIG_POLARIS
+#define CONFIG_SYS_MSC2_VAL0xa2697ff8
+#else
#define CONFIG_SYS_MSC2_VAL0xa26936d4
+#endif
#define CONFIG_SYS_MDCNFG_VAL 0x880009C9
#define CONFIG_SYS_MDREFR_VAL 0x20ca201e
#define
[U-Boot] R: R: USB EHCI driver
Hi, thanks for your compliments, but I think that there is some work to do about this driver to support OTG mode and gadget mode. For now I enabled support to host mode, and from my test does it work. I'm preparing the patch, and this will carry away some days because usb u-boot source code is been re-organized.. I developed my patch on u-boot 2009.03, so I have to port my job on last u-boot version. Regards, Francesco -Messaggio originale- Da: Detlev Zundel [mailto:d...@denx.de] Inviato: mer 6/24/2009 10:51 A: Rendine Francesco Cc: Michael Trimarchi; Gupta Maneesh-B18878; u-boot@lists.denx.de Oggetto: Re: [U-Boot] R: USB EHCI driver Hi Francesco, I'm successful in provide a preliminary support to EHCI USB Freescale controller integrated on ADS5121 platform. I'm preparing a patch to submit to u-boot mailing list. Congratulations - I'm also looking forward to see and test the patch on our ads5121. Cheers Detlev -- More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other to total extinction. Let us pray, we have the wisdom to choose correctly. -- Woody Allen -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Hi Scott, On Tue, Jun 23, 2009 at 06:33:53PM +0200, Detlev Zundel wrote: Also this is one of the objections worded on the mailing list, namely that such a cooperation will be impossible in the future if U-Boot moves to GPLv3. As a base for reasonable discussion, I think we need to evaluate those claims and back them up by actual figures. Only then the real effort needed to move and the potential loss of code immigration can be estimated. The NAND subsystem is from Linux and is GPL v2 only, as is the u-boot-specific NAND code in drivers/mtd/nand. Ok, thanks for that info. Subtracting the drivers this is ~5k LOC, right? nand_ecc.c is an exception, which not only has the or later language but also has an exception that makes it non-viral. Why do you refer to one of the most important aspects of the effectiveness of the GPL as being viral? GPLd software neither attacks nor infects software so the wording is actively misleading. env_nand.c is v2-or-later. cmd_nand.c has no explicit license. In summary: If you switch to v3, you lose much of NAND. Unless RMS volunteers to rewrite it. :-) Is there any chance of convincing those authors to change that? Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be a neccessary precondition to only accept blessed firmware upgrades (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades. Regardless of what motivates it, people who sell hardware to such customers (and who also contribute to u-boot) may not want to risk losing that business by pushing GPLv3 on them. Actually I want to understand why people fear to loose business with GPLv3. What is the exact scenario that is so threatening? Unless this is understood, it is hard to argue in any way. Cheers Detlev -- It's amazing I won. I was running against peace, prosperity, and incumbency. -- George H.W. Bush, 06/14/2001, talking to Swedish prime minister Goran Perrson, unaware that a live tv camera was still on -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Hi Mike, On Tuesday 23 June 2009 15:26:35 Scott Wood wrote: On Tue, Jun 23, 2009 at 06:33:53PM +0200, Detlev Zundel wrote: Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be a neccessary precondition to only accept blessed firmware upgrades (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades. Regardless of what motivates it, people who sell hardware to such customers (and who also contribute to u-boot) may not want to risk losing that business by pushing GPLv3 on them. indeed. expecting businesses to push other peoples' agenda isnt realistic, especially when the conversation is pretty much a net customer loss for said businesses. It seems so clear for you, but it isn't for me - where is this net loss for them, what exactly do they loose? customers arent going to appear because your business is now pushing GPLv3 instead of GPLv2, but they will certainly disappear. Why will they disappear? Cheers Detlev -- error compiling committee.c: too many arguments to function -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Hi Jean-Christophe, On 15:41 Tue 23 Jun , Mike Frysinger wrote: On Tuesday 23 June 2009 15:26:35 Scott Wood wrote: On Tue, Jun 23, 2009 at 06:33:53PM +0200, Detlev Zundel wrote: Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be a neccessary precondition to only accept blessed firmware upgrades (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades. Regardless of what motivates it, people who sell hardware to such customers (and who also contribute to u-boot) may not want to risk losing that business by pushing GPLv3 on them. indeed. expecting businesses to push other peoples' agenda isnt realistic, especially when the conversation is pretty much a net customer loss for said businesses. customers arent going to appear because your business is now pushing GPLv3 instead of GPLv2, but they will certainly disappear. 200% agree I can assure you that today If we switch the V2 to the v3 we will lose a lot of customers and soc that use secure boot as example which is not a progression but a problematic regression What exactly is secure boot? And force to give the private key which use to sign the code is not reallist it's a security flaw That's interesting to hear. Where exactly is there security involved and why should security be implementable by signed binaries only? Does that mean that for example I have *no secure* software on my computer right now? Don't you mistake security for authenticity? so U-Boot will close itself to a lots of business and customers As you are not trying to give concrete examples, let me try to formulate your facts: U-Boot will not be usable within DRM systems. Is that what you are saying? Cheers Detlev -- 0x2B | ~0x2B -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config.mk: Remove unused HPATH
Hi Detlev, Detlev Zundel wrote: This variable is not unused anywhere. Makes my brain twist and after carefully applying boolean equivalence operations contradicts the title ;) Oops, thanks for pointing out. Will correct it later. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Wednesday 24 June 2009 05:12:01 Detlev Zundel wrote: On Tuesday 23 June 2009 15:26:35 Scott Wood wrote: On Tue, Jun 23, 2009 at 06:33:53PM +0200, Detlev Zundel wrote: Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be a neccessary precondition to only accept blessed firmware upgrades (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades. Regardless of what motivates it, people who sell hardware to such customers (and who also contribute to u-boot) may not want to risk losing that business by pushing GPLv3 on them. indeed. expecting businesses to push other peoples' agenda isnt realistic, especially when the conversation is pretty much a net customer loss for said businesses. It seems so clear for you, but it isn't for me - where is this net loss for them, what exactly do they loose? customers arent going to appear because your business is now pushing GPLv3 instead of GPLv2, but they will certainly disappear. Why will they disappear? if you want to push your agenda on your customers (i'm assuming you actually have some and arent just here for fun), that's your business. but when customers absolutely state their requirements are secure boot and the ability to lock their hardware so no one else can run things, then i'm not about to argue with them. their response is simply fine, we'll move on to the next guy who will satisfy our requirements. they arent generally trying to lock out people who just want to toy, they're targeting people who want to clone their hardware or functionality to create knockoffs or they're trying to guarantee lock down so they can get certified (like medical devices). that's my practical standpoint from my job experience -- GPLv3 will cause a u- boot fork and the net result is not beneficial to anyone. my completely personal standpoint is the same -- do not use the GPLv3. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mcf5445x watchdog support in U-Boot
Hello TsiChung. I have added watchdog support in U-Boot for MCF5445x devices using the M54455 EVB platform to test. I can send you a patch if you wish (the timeout is hard coded to 16 secs at the moment)? However, I am having trouble when U-Boot starts Linux in the case when the watchdog has been enabled in U-Boot. Basically, Linux seems to crash before it gets a chance to print anything on the console - but, control appears to have left U-Boot. Building U-Boot with debug, it displays: ## Transferring control to Linux (at address 4002) ... BIV Then it's dead after which the watchdog times out and causes a cpu reset. Building U-Boot without debug I get the following: *** Unexpected exception *** Vector Number: 4 Format: 04 Fault Status: 0 PC: 4fdbfdc8SR: 2700SP: 4fd72a64 D0: 0004D1: 03f9D2: 4fdb4202D3: 004fa3da D4: D5: 4fdc7c8cD6: 122c0034D7: 4fd82f76 A0: 4033cb98A1: 4025aa39A2: 4002A3: 4fdbfdc8 A4: A5: 4fdc5800A6: 4fd72afb *** Please Reset Board! *** Then again, the watchdog times out and causes a cpu reset. It definitely appears as though Linux has been started but I cannot tell what has actually happened. I think it's possible that something in the Linux setup has caused (or contributed to) the crash. The problem does not happen if the watchdog support is disabled by #undefining CONFIG_WATCHDOG. It certainly seems that U-Boot is not responsible for the crash. Do you have any thoughts on this? I'd appreciate a bit of help. Rgds, -- Matt Hi TsiChung, I can supply you my patch for a watchdog driver implementation for 5445x to test with if you like? I've not fed it back to Freescale yet. Will do though. It's based on 2.6.29. Is there a mechanism to allow U-Boot to indicate to Linux that it has enabled the watchdog (eg as part of the bd_info struct maybe)? Just a thought... It could then be kicked at kernel arch init and then repeatedly by Linux user space via /dev/watchdog if required by the application. The reason I suggested kicking the watchdog in arch init is to give Linux a chance to boot (kernel and user) before the watchdog times out. Obviously several things could prevent this (eg tasks that take time before user space starts for example fsck etc). I'm sure other U-Boot developers/maintainers have thought about this..? Thoughts? In any case, I need to enable the watchdog in U-Boot for a mcf54451 based platform because need it in our system (we're using an mcf54455 evb as reference hw). I'm happy to help in the development / testing etc. Please just let me know. Best regards, -- Matt Matt, Yes. I am planning to enable watchdog in mcf5445x in u-boot. Need to investigate more in booting linux and the transition to starting the linux kernel of watchdog behavior to make sure it is not causing problem to the linux kernel. Best Regards, TsiChung -Original Message- From: Matthew Lear [mailto:m...@bubblegen.co.uk] Sent: Monday, June 15, 2009 7:59 AM To: Liew Tsi Chung-R5AAHP; u-boot@lists.denx.de Subject: mcf5445x watchdog support in U-Boot Hi TsiChung et al, I was wondering if there are plans to support and utilise the watchdog in the mcf5445x devices within U-Boot? I've ported a kernel driver from the bitshrine gpp (http://www.bitshrine.org/gpp/linux-2.6.25-mcfv4e-watchdog.patch) so that it hooks into my 54455 hw (Freescale EVB), however I'd like to configure and enable the watchdog in U-Boot with the intention that once Linux starts, the responsibility of kicking the watchdog resides with a user space app - driver. Thoughts? Much appreciated. -- Matt ___ 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Hi Mike, On Wednesday 24 June 2009 05:12:01 Detlev Zundel wrote: On Tuesday 23 June 2009 15:26:35 Scott Wood wrote: On Tue, Jun 23, 2009 at 06:33:53PM +0200, Detlev Zundel wrote: Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be a neccessary precondition to only accept blessed firmware upgrades (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades. Regardless of what motivates it, people who sell hardware to such customers (and who also contribute to u-boot) may not want to risk losing that business by pushing GPLv3 on them. indeed. expecting businesses to push other peoples' agenda isnt realistic, especially when the conversation is pretty much a net customer loss for said businesses. It seems so clear for you, but it isn't for me - where is this net loss for them, what exactly do they loose? customers arent going to appear because your business is now pushing GPLv3 instead of GPLv2, but they will certainly disappear. Why will they disappear? if you want to push your agenda on your customers (i'm assuming you actually have some and arent just here for fun), that's your business. Is it possible that you jump to conslusions here? All we - on a regular basis - do is to talk to our customers until we understand what the customer needs. Then we think about how this can or cannot be done with the help of Free Software. After all nobody is forcing anyone to use Free Software and for some customer wishes Free Software may simply be not a legal option, so what? In this process it is common that customers have incomplete information about Free Software in general and not well-articulated fears making them jump to premature conclusions (e.g. we need a closed source Linux kernel driver) which would prevent us from doing development for them. At this point it is extremely important to learn about the reasoning of the customer and then clearing up confusion probably leading to revisiting the question of using Free Software. Essentially I can only remember one customer in the last years who did not go further at the time after learning that we would not develop a non-GPL kernel module. Incidentally this customer is now back on our doorstep because the market effectively forces him to use a GNU/Linux system from a feature perspective. This time around closed sources kernel modules are not even on the agenda anymore. but when customers absolutely state their requirements are secure boot and the ability to lock their hardware so no one else can run things, then i'm not about to argue with them. their response is simply fine, we'll move on to the next guy who will satisfy our requirements. It is your decision if you don't want to even understand your customers needs. I surely do and this is what I try to understand in this thread. I admit that I did not think this through completely, but how much of this no one else can run things is actually connected to the bootloader? U-Boot itself will not be handling prime content I guess. Those secure boot you talk about - what is it exactly and what are the potential attack vectors of it? Are there vectors besides the bootloader? If so, how does a non-supporting bootloader make the situation any worse? they arent generally trying to lock out people who just want to toy, they're targeting people who want to clone their hardware or functionality to create knockoffs or they're trying to guarantee lock down so they can get certified (like medical devices). How does GPLv3 vs. GPLv2 touch the we will get cloned question? Maybe I do not see the obvious here, but sourcecode to binaries under either license must be available, so what's the difference? that's my practical standpoint from my job experience -- GPLv3 will cause a u- boot fork and the net result is not beneficial to anyone. You must have a very good crystal ball. Maybe if my crystal ball was that good I did not need to ask questions. my completely personal standpoint is the same -- do not use the GPLv3. Ok, somehow this was already clear to me. On the other hand I also do believe that for a project which is here simply because of the benefits of the GPL, we should spend some time thinking this through and then base the decision of the project on a sound basis. Handwaving arguments do not help much here, so thanks for your input. Cheers Detlev -- I haven't lost my mind, I know exactly where I left it. -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___
Re: [U-Boot] U-Boot timer example crashes on EP88xC
Hi Mikhail, I am using ELDK 4.2 and U-Boot 2009.03 on an EP88xC rev1.1 board (MPC885 cpu) and am trying to get the example apps working (the ones that come with U-Boot) following instructions on http://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.2.;. examples/hello_world.bin worked fine: [...] But things didn't go too smoothly with the examples/timer.bin app: = tftp 4 ep88x_timerdemo Trying FEC ETHERNET Using FEC ETHERNET device TFTP from server 10.0.54.129; our IP address is 10.0.54.150 Filename 'ep88x_timerdemo'. Load address: 0x4 Loading: ## done Bytes transferred = 263740 (4063c hex) = go 40004 ## Starting application at 0x00040004 ... Oh huh - this would imply that the timer routine got linked to this address. When I use objdump to deassemble the object file, it seems that timer is at 40108. Try go 0x40108 and read the FAQ[1] ;) Cheers Detlev [1] http://www.denx.de/wiki/view/DULG/MyStandaloneProgramDoesNotWork -- NAN - No Acronym Neccessary -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] A320: Add support for Faraday A320 evaluation board
Hello Po-Yu, 2009/6/24 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com: please use git I cannot access git in the company, but I will try that at home. Why is that? If it is because of the git port not getting through a company firewall, we do actually offer http:// access to our git repos - just check the URL section in gitweb[1]. Cheers Detlev [1] http://git.denx.de/?p=u-boot.git;a=summary -- One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot 2009 for Freescale mpc5121
Hi Stas, I was able to compile and run the u-boot for my board from both cygwin and Linux. The only problem I had was the uboot.lds file that in the old version had the manual listing of the segments like this: *(.rodata) *(.rodata1) *(.rodata.str1.4) Now it uses a macro to sort them according to wildcard. I use gcc-3.4.3 for the MPC51xx provided by Freescale. Is there any newer version of the GNU toolchain that u-boot uses? You can use the freely available ELDK 4.2 being based on gcc 4.2.2 (see [1]). Cheers Detlev [1] http://www.denx.de/en/Software/WebHome -- I have always observed that the pretensions of all people are in exact inverse ratio to their merits; this is one of the axioms of morals.-- Joseph Lagrange -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM920T SMDK2440 support
Hi J.H.Kim, Is U-Boot not support ARM920T SMDK2440 board? Apparantly not out of the box. If you search the ML however[1] you will see a few comments about that board. Maybe mail the relevant authors. Cheers Detlev [1] http://search.gmane.org/?query=smdk2440group=gmane.comp.boot-loaders.u-boot -- It's amazing I won. I was running against peace, prosperity, and incumbency. -- George H.W. Bush, 06/14/2001, talking to Swedish prime minister Goran Perrson, unaware that a live tv camera was still on -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocating to my code.
Hi Prathika, I did not mean it should run from flash itself..My application will just reside in flash, I will read back from flash to a RAM location. To be honest, I have trouble understanding this. As I understand, in board_init_f(), after calling the init_sequence, relocate_code() is called and it is a must to call relocate_code(), from where it branches to main_loop(). My aim is to branch to my application code before calling relocate_code().My application code's executable address is 0x40004. Well, if you are working on a PowerPC platform, then 0x40004 is certainly a RAM address. Is it that i can just give jump to 0x40004 before calling relocate_code() and it works? I still don't get why you want to change *anything* inside U-Boot. Why not just use the commands that are available in the command line interpreter? Say you have your application stored at fc2e (arbitrary address) and it is 64k in size. Then why not just do: cp.b fc2e 4 1;go 40004 Setting bootenv to these commands will start your application on U-Boot timeout. Sticking them into preboot even runs them before the command line is started at all. Cheers Detlev -- Those who do not understand Unix are condemned to reinvent it, poorly. - Henry Spencer, University of Toronto Unix hack -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Hi Detlev, What exactly is secure boot? Jean-Christophe - if I may interject... Embedded systems using core soc silicon from a number of manufacturers have started to use what is known as 'secure boot'. This is typically the case in applications which utilise conditional access system software to protect content. The emphasis on using secure boot is largely driven by the conditional access industry itself. Secure boot basically means that internally in the soc, fuses are blown that provide some semblance of a low-level hw signature. This signature is combined with additional information from a conditional access / security vendor who may provide tools/utilities for 'signing' bootloader and/or application software binary code images. Consider the case where the soc is boot-strapped by low-level 'secure boot' code. Even before the bootloader's main() is entered, the boot code validates the image using secure features such as private keys. If validation succeeds the platform bootstrap continues to main(). If the licensing of U-Boot changed and U-Boot contained secure boot code and/or features such as these in its low-level bootstrap code, it is feasible that the secure features would have to be made public, thus there would be a rather large security flaw. Don't you mistake security for authenticity? In this context, I believe both terms are interchangeable and effectively mean the same thing. It is secure because only authenticated code is allowed to be executed, thus another step to avoid piracy, hacking of conditional access systems etc. Hope that helps. Cheers, -- Matt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot timer example crashes on EP88xC
When I use objdump to deassemble the object file, it seems that timer is at 40108. Try go 0x40108 and read the FAQ[1] ;) Cheers Detlev [1] http://www.denx.de/wiki/view/DULG/MyStandaloneProgramDoesNotWork go 0x40108 did it, thanks! And thanks for the FAQ reference, knowing this will be definitely useful in the future. Why does the documentation say to use 0x40004? I have not made any changes to the timer program, is it different because the example uses the SREC version of the file and I'm using the binary? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] minor fixes for mvBL-M7 and use of common code
Kim, On Tue, 2009-06-23 at 18:17 -0500, Kim Phillips wrote: On Mon, 22 Jun 2009 15:50:29 +0200 André Schwarz andre.schw...@matrix-vision.de wrote: Hello André, X-Mailer: Evolution 2.26.1 ... [0001-rebased-mvBLM7-with-minor-fixes.patch text/x-patch (8.2KB)] please use Insert-Text File... (Alt-n x) to insert the patch. sorry - has been my first patch sent with evolution. -#define _IO_BASE 0x - the above is the reason for the below: ok - understood. Didn't expect your patch being applied that quickly, i.e. obviously missed all ACK's. Applying: minor fixes for mvBL-M7 and use of common code error: patch failed: include/configs/MVBLM7.h:193 error: include/configs/MVBLM7.h: patch does not apply Patch failed at 0001 minor fixes for mvBL-M7 and use of common code ...and because I have the remove _IO_BASE and KSEG1ADDR from board configuration files patch already applied, and probably justifiably so, since it arrived earlier to the list than your patch. btw, I also get this at build time: Configuring for MVBLM7 board... mv_common.c: In function 'mv_load_fpga': mv_common.c:93: warning: implicit declaration of function 'fpga_load' So did you want 1-3/3 of these to bypass u-boot-mpc83xx and go straight to WD? I'm asking because there's overlap with the mpc5xxx maintainer (WD himself apparently) in this patchseries. Will wait for all replies. As far as I know WD is on vacation, i.e. this is going to take some time. I'm in no hurry - if it's ok for you I'll fix all remaining issues with a single rebase/resend. Cheers, André Kim MATRIX VISION GmbH, Talstra�e 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Gesch�ftsf�hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Wednesday 24 June 2009 09:17:50 Detlev Zundel wrote: if you want to push your agenda on your customers (i'm assuming you actually have some and arent just here for fun), that's your business. Is it possible that you jump to conslusions here? All we - on a regular basis - do is to talk to our customers until we understand what the customer needs. Then we think about how this can or cannot be done with the help of Free Software. After all nobody is forcing anyone to use Free Software and for some customer wishes Free Software may simply be not a legal option, so what? In this process it is common that customers have incomplete information about Free Software in general and not well-articulated fears making them jump to premature conclusions (e.g. we need a closed source Linux kernel driver) which would prevent us from doing development for them. At this point it is extremely important to learn about the reasoning of the customer and then clearing up confusion probably leading to revisiting the question of using Free Software. Essentially I can only remember one customer in the last years who did not go further at the time after learning that we would not develop a non-GPL kernel module. Incidentally this customer is now back on our doorstep because the market effectively forces him to use a GNU/Linux system from a feature perspective. This time around closed sources kernel modules are not even on the agenda anymore. and that's your prerogative. how you choose to run your business has no bearing at all on how other people choose to run their businesses. but when customers absolutely state their requirements are secure boot and the ability to lock their hardware so no one else can run things, then i'm not about to argue with them. their response is simply fine, we'll move on to the next guy who will satisfy our requirements. It is your decision if you don't want to even understand your customers needs. wrong, we've actually done the opposite. we know what they want to do and it is doable with GPLv2. it is not doable with GPLv3. yes, there are cases of ingrained perceptions about how to accomplish something and GPLv3 blocks those methods. but again, it is *your* choice to attempt to educate people here, it is not the automatic burden of people to champion the GNU cause for you. I admit that I did not think this through completely, but how much of this no one else can run things is actually connected to the bootloader? U-Boot itself will not be handling prime content I guess. Those secure boot you talk about - what is it exactly and what are the potential attack vectors of it? Are there vectors besides the bootloader? If so, how does a non-supporting bootloader make the situation any worse? secure boot is pretty straightforward. the CPU has internal keys programmed into it and will only boot signed binaries. this is u-boot. u-boot in turn will only boot signed encrypted binaries using keys inside of the CPU that can only be accessed by code running on the CPU. licensing of these binaries obviously doesnt matter. the encrypted stream is transferred from external storage into internal CPU storage, decrypted there, and then executed from there. so there is no possibility of sniffing the decrypted stream on any bus as it never leaves the CPU. they arent generally trying to lock out people who just want to toy, they're targeting people who want to clone their hardware or functionality to create knockoffs or they're trying to guarantee lock down so they can get certified (like medical devices). How does GPLv3 vs. GPLv2 touch the we will get cloned question? Maybe I do not see the obvious here, but sourcecode to binaries under either license must be available, so what's the difference? if you dont have the decryption keys, you cant read the end program. having access to the u-boot source doesnt matter. that's my practical standpoint from my job experience -- GPLv3 will cause a u- boot fork and the net result is not beneficial to anyone. You must have a very good crystal ball. Maybe if my crystal ball was that good I did not need to ask questions. then you should take it in to get serviced my completely personal standpoint is the same -- do not use the GPLv3. Ok, somehow this was already clear to me. On the other hand I also do believe that for a project which is here simply because of the benefits of the GPL, we should spend some time thinking this through and then base the decision of the project on a sound basis. Handwaving arguments do not help much here, so thanks for your input. except that licensing choice is just as much practical considerations (can XYZ be done with the GPLv3) as it is personal choice. it dictates how we choose to *let* other people utilize the code. i personally dont have a problem with people locking their hardware. that is their choice and the GPLv2 allows
Re: [U-Boot] 88e61xx driver in u-boot
On Wed, Jun 24, 2009 at 3:09 AM, Prafulla Wadaskarprafu...@marvell.com wrote: I don't see anything in the 88E6161 switch itself that would respond at those 0xEE addresses (IIRC the MII bus only provides for 5 bits of register and phy address). Is this something specific to the board/SoC you were running the switch with and/or it's miiphy_read implementation? As far as I can tell, what is needed is to set mii_dev_addr to the address set by the ADDR[4:0] chip config pins, which would see to be a board specific item, and shouldn't be in the generic driver. This would seem like a good candidate for something that is passed in via the mv88e61xx_config structure. This command is mapped to the smi_reg_read function of SoCs eth controller driver (kirkwood-egiga.c). The 0xEE in this command is used to flag the above function to read-n-return phy device address which is needed by switch for multi chip addressing. Phy device address is decided by board hardware and same need to be programmed for eth controller and switch for successful read/write. In the current implementation phy address is provided to eth controller driver from board config header. During switch init which comes next, switch gets it from associated controller though this interface As you suggested, we can simply provide this through mv88e61xx_config structure, but it may lead to configuration problems, providing same settings at two different places, if there is mismatch one need to spend enough time debugging the same (as I spend). To avoid this I have implemented above method. We do not have exposed api for the same in miiphy.h, this need to be supported in miiphyutil My next efforts will be expose miiphy_devadr_read/write api for the same. I would suggest until this API is in place, it would make more sense to have the structure carry the address value and have the board startup code initialize the structure member by calling the SoC functions. This would keep the in-tree switch driver from being quite so specific to your board and SoC and get rid of the 'overloading' of the miiphy_read() function. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v5] KB9202: Add NAND support
Add NAND support for the KwikByte KB9202
Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
---
El Tue, Jun 23, 2009 at 04:19:40PM -0500 Scott Wood ha dit:
I get conflicts in kb9202.h. Is this against an arch tree, or does it
need to be respun?
The previous patches were against v2009-03, as i had problems
building the current git head for the kb9202 when i started working on
the patch. Did you apply the first patch of this series when you got
the conflict? This patch is based on the current HEAD.
Changes regarding v4:
* put KB9202 entry in the Makefile at the correct position
(alphabetical order)
* removed superfluous clear of NAND_BUSWIDTH_16 flag
* fixed line length/broken indentation
drivers/mtd/nand/Makefile|1 +
drivers/mtd/nand/kb9202_nand.c | 150 ++
include/asm-arm/arch-at91rm9200/AT91RM9200.h |2 +
include/configs/kb9202.h | 11 ++-
4 files changed, 163 insertions(+), 1 deletions(-)
create mode 100644 drivers/mtd/nand/kb9202_nand.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 71dd5b9..d2bd558 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_DRIVER_NAND_BFIN) += bfin_nand.o
COBJS-$(CONFIG_NAND_DAVINCI) += davinci_nand.o
COBJS-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
COBJS-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o
+COBJS-$(CONFIG_NAND_KB9202) += kb9202_nand.o
COBJS-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o
COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.c
diff --git a/drivers/mtd/nand/kb9202_nand.c b/drivers/mtd/nand/kb9202_nand.c
new file mode 100644
index 000..b8f46fa
--- /dev/null
+++ b/drivers/mtd/nand/kb9202_nand.c
@@ -0,0 +1,150 @@
+/*
+ * (C) Copyright 2006
+ * KwikByte kb9200_...@kwikbyte.com
+ *
+ * (C) Copyright 2009
+ * Matthias Kaehlcke matth...@kaehlcke.net
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/AT91RM9200.h
+#include asm/arch/hardware.h
+
+#include nand.h
+
+/*
+ * hardware specific access to control-lines
+ */
+
+#define MASK_ALE(1 22) /* our ALE is A22 */
+#define MASK_CLE(1 21) /* our CLE is A21 */
+
+#define KB9202_NAND_NCE (1 28) /* EN* on D28 */
+#define KB9202_NAND_BUSY (1 29) /* RB* on D29 */
+
+#define KB9202_SMC2_NWS (1 2)
+#define KB9202_SMC2_TDF (1 8)
+#define KB9202_SMC2_RWSETUP (1 24)
+#define KB9202_SMC2_RWHOLD (1 29)
+
+/*
+ * Board-specific function to access device control signals
+ */
+static void kb9202_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+
+ if (ctrl NAND_CTRL_CHANGE) {
+ ulong IO_ADDR_W = (ulong) this-IO_ADDR_W;
+
+ /* clear ALE and CLE bits */
+ IO_ADDR_W = ~(MASK_ALE | MASK_CLE);
+
+ if (ctrl NAND_CLE)
+ IO_ADDR_W |= MASK_CLE;
+
+ if (ctrl NAND_ALE)
+ IO_ADDR_W |= MASK_ALE;
+
+ this-IO_ADDR_W = (void *) IO_ADDR_W;
+
+ if (ctrl NAND_NCE)
+ writel(KB9202_NAND_NCE, AT91C_PIOC_CODR);
+ else
+ writel(KB9202_NAND_NCE, AT91C_PIOC_SODR);
+ }
+
+ if (cmd != NAND_CMD_NONE)
+ writeb(cmd, this-IO_ADDR_W);
+}
+
+
+/*
+ * Board-specific function to access the device ready signal.
+ */
+static int kb9202_nand_ready(struct mtd_info *mtd)
+{
+ return readl(AT91C_PIOC_PDSR) KB9202_NAND_BUSY;
+}
+
+
+/*
+ * Board-specific NAND init. Copied from include/linux/mtd/nand.h for
reference.
+ *
+ * struct nand_chip - NAND Private Flash Chip Data
+ * @IO_ADDR_R: [BOARDSPECIFIC] address to read the 8 I/O lines of the
flash device
+ * @IO_ADDR_W: [BOARDSPECIFIC] address to write the 8 I/O lines of the
flash device
+ * @hwcontrol: [BOARDSPECIFIC] hardwarespecific function for accesing
control-lines
+ * @dev_ready: [BOARDSPECIFIC] hardwarespecific function for accesing
device ready/busy line
+ * If set to NULL no access
Re: [U-Boot] ARM920T SMDK2440 support
I'm hoping to submit patches to add support for the Embest SBC2440-II Board later today. It uses an s3c2440 CPU so my patches would make a good starting point for the SMDK2440 board. - Kevin On 24/06/2009 09:42, J.Hwan.Kim wrote: Hi, everyone Is U-Boot not support ARM920T SMDK2440 board? Regards, J.H.Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot __ Information from ESET NOD32 Antivirus, version of virus signature database 4181 (20090623) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4184 (20090624) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot timer example crashes on EP88xC
Hi Mikhail, When I use objdump to deassemble the object file, it seems that timer is at 40108. Try go 0x40108 and read the FAQ[1] ;) Cheers Detlev [1] http://www.denx.de/wiki/view/DULG/MyStandaloneProgramDoesNotWork go 0x40108 did it, thanks! And thanks for the FAQ reference, knowing this will be definitely useful in the future. Why does the documentation say to use 0x40004? The documentation _was_ correct at some point in time. Obviously the situation changed. The real problem is that we currently do not exactly specify the memory layout for the examples elf files. To be deterministic we would need to have a linker script which puts the intended function onto the correct offset. This has not been done and with previous toolchains the examples worked (more or less) like expected. Obviously nobody used the timer example recently ;) I have not made any changes to the timer program, is it different because the example uses the SREC version of the file and I'm using the binary? No this is not a problem - as mentioned above it is the contents of the elf file which is not according to expectation. For the fun of it you could try to come up with a linker script for powerpc also. This should get at least the text segment at the intended place. How to order functions in there I'm not so sure. Maybe use attributes to define a specific text segment at the beginning and then mark the main function with this attribute. You're welcome to play here ;) Cheers Detlev -- Indeed, the author firmly believes that the best serious work is also good fun. We needn't apologize if we enjoy doing research. -- Donald Knuth -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Wed, Jun 24, 2009 at 11:09:49AM +0200, Detlev Zundel wrote: nand_ecc.c is an exception, which not only has the or later language but also has an exception that makes it non-viral. Why do you refer to one of the most important aspects of the effectiveness of the GPL as being viral? GPLd software neither attacks nor infects software so the wording is actively misleading. I was referring to the if you link me in, the entire project must be under my terms clause. I refer to it as viral because that is the typical terminology for this sort of license -- so named because it can lead to software being licensed under GPL that otherwise wouldn't have been just so it can be combined with existing GPL software, and then yet more software licenses under GPL so it can link with *that* software (now devoid of the original code whose author explicitly chose GPL), etc. Whether it is a good thing is a matter of personal opinion, which I was trying to keep out of that e-mail. Looks like I failed. :-) Regardless of what motivates it, people who sell hardware to such customers (and who also contribute to u-boot) may not want to risk losing that business by pushing GPLv3 on them. Actually I want to understand why people fear to loose business with GPLv3. What is the exact scenario that is so threatening? Unless this is understood, it is hard to argue in any way. U-boot contributor A wants to sell hardware to customer B, who wants secure boot, or for any other reason does not want to involve themselves in GPL3. I'm not going to provide names, but this is not hypothetical. If nobody wanted to do the things that GPLv3 prevents, there wouldn't be a GPLv3. :-) U-boot goes GPLv3. A has a choice to continue developing on mainline u-boot, in which case one of these happens: 1. A develops *another* bootloader in parallel (possibly based on old GPLv2 u-boot) for customer B, 2. B develops (or acquires) their own firmware, or 3. B buys hardware from someone else who provides non-GPL3 firmware. #2 seems unlikely if #3 is a reasonable option -- and if A is going to do #1, why wouldn't they develop *only* that non-GPL3 firmware if it is a superset of usefulness to A (who doesn't particularly care about the GPL3 agenda)? In other words, a fork. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] minor fixes for mvBL-M7 and use of common code
On Wed, 24 Jun 2009 16:19:06 +0200 André Schwarz andre.schw...@matrix-vision.de wrote: -#define _IO_BASE 0x - the above is the reason for the below: ok - understood. Didn't expect your patch being applied that quickly, i.e. obviously missed all ACK's. WD hasn't applied it yet - I applied it to my local tree. None of this means your patch should touch the same line and thus cause unnecessary conflicts. So did you want 1-3/3 of these to bypass u-boot-mpc83xx and go straight to WD? I'm asking because there's overlap with the mpc5xxx maintainer (WD himself apparently) in this patchseries. Will wait for all replies. As far as I know WD is on vacation, i.e. this is going to take some time. I'm in no hurry - if it's ok for you I'll fix all remaining issues with a single rebase/resend. sure, go ahead - I guess we have to wait for WD to pick them up. I'll try and ack them before he gets back. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Hi Mike, On Wednesday 24 June 2009 09:17:50 Detlev Zundel wrote: if you want to push your agenda on your customers (i'm assuming you actually have some and arent just here for fun), that's your business. Is it possible that you jump to conslusions here? All we - on a regular basis - do is to talk to our customers until we understand what the customer needs. Then we think about how this can or cannot be done with the help of Free Software. After all nobody is forcing anyone to use Free Software and for some customer wishes Free Software may simply be not a legal option, so what? In this process it is common that customers have incomplete information about Free Software in general and not well-articulated fears making them jump to premature conclusions (e.g. we need a closed source Linux kernel driver) which would prevent us from doing development for them. At this point it is extremely important to learn about the reasoning of the customer and then clearing up confusion probably leading to revisiting the question of using Free Software. Essentially I can only remember one customer in the last years who did not go further at the time after learning that we would not develop a non-GPL kernel module. Incidentally this customer is now back on our doorstep because the market effectively forces him to use a GNU/Linux system from a feature perspective. This time around closed sources kernel modules are not even on the agenda anymore. and that's your prerogative. how you choose to run your business has no bearing at all on how other people choose to run their businesses. All I said is that we have a pretty good idea of what is legal and what isn;t and that we will not start work in an area where we belive we could actually be liable by law. How you come to the conclusion that this is prerogative completely escapes me. Are you sure that you are interested in what I say? but when customers absolutely state their requirements are secure boot and the ability to lock their hardware so no one else can run things, then i'm not about to argue with them. their response is simply fine, we'll move on to the next guy who will satisfy our requirements. It is your decision if you don't want to even understand your customers needs. wrong, we've actually done the opposite. we know what they want to do and it is doable with GPLv2. it is not doable with GPLv3. From what I read, I do not get this impression. Locking people out is not a ulterior motive but the outcome of a perceived threat to a business model. It was this business model that I wanted to get a clear picture of. It seems I cannot get any more informatino here. yes, there are cases of ingrained perceptions about how to accomplish something and GPLv3 blocks those methods. but again, it is *your* choice to attempt to educate people here, it is not the automatic burden of people to champion the GNU cause for you. What kind of axe do you have to grind here? We (as a project) were asked about our stance to move to GPLv3 which is a perfectly good question to pose. All I want to do is collect facts - your allegation that I want other people to carry a burden shows me that this way will bear no more fruit. they arent generally trying to lock out people who just want to toy, they're targeting people who want to clone their hardware or functionality to create knockoffs or they're trying to guarantee lock down so they can get certified (like medical devices). How does GPLv3 vs. GPLv2 touch the we will get cloned question? Maybe I do not see the obvious here, but sourcecode to binaries under either license must be available, so what's the difference? if you dont have the decryption keys, you cant read the end program. having access to the u-boot source doesnt matter. Having access to the physical device will. How long do you think will it take to get broken into? Unfortunately physics do not follow wishes of companies as seen over and over in the past. On the other hand I also do believe that for a project which is here simply because of the benefits of the GPL, we should spend some time thinking this through and then base the decision of the project on a sound basis. Handwaving arguments do not help much here, so thanks for your input. except that licensing choice is just as much practical considerations (can XYZ be done with the GPLv3) as it is personal choice. it dictates how we choose to *let* other people utilize the code. Licensing ceases to be a personal choice when it is a community project. i personally dont have a problem with people locking their hardware. that is their choice and the GPLv2 allows them that freedom. You have a strange definition of freedom - for you it is limited to the provider of the devices not to the users of the devices. I guess this is what this all boils down to. hell, i wouldnt have a problem with a public domain u-boot.
Re: [U-Boot] U-book and GPLv3? (fwd)
There is an enormous practical consideration stopping the licensing change. u-boot has not required copyright assignment. This means that every single person that has contributed code to u-boot needs to give their permission for the change. This includes the authors of code copied from the Linux kernel. It isn't good enough to just post to the email list and ask for the change, you have to make sure that every single person has been asked even if they aren't paying attention to the list. If any of these people object (and some already have objected) their contribution will need to be identified, removed and rewritten. This is not a comment on the merits or faults of the GPL v3. It is just an assessment of the logistical effort required to do the change. IMHO it would be easier to just write a new boot loader from scratch, require copyright assignment on contributions and start off with the GPL v3 initially. -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Hi Matthew, thanks for the explanation. Don't you mistake security for authenticity? In this context, I believe both terms are interchangeable and effectively mean the same thing. This is generally not true. These concepts have well defined meanings. I can have a secure communicatins channel with someone I did not authenticate. Also I can have a non-secure communications channel with someone who authenticated himself by some means to me. It is secure because only authenticated code is allowed to be executed, thus another step to avoid piracy, hacking of conditional access systems etc. Running only authenticated code does *not* ensure security, no matter how much this is wished for. But no matter, I now understand that security seems to mean data can only be handled in the way intended by the owners of the data which is a different concept to me. Cheers Detlev -- FORTRAN's tragic fate has been its wide acceptance, mentally chaining thousands and thousands of programmers to our past mistakes. I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility. -- Edsger W. Dijkstra -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Hi Jon, There is an enormous practical consideration stopping the licensing change. u-boot has not required copyright assignment. This means that every single person that has contributed code to u-boot needs to give their permission for the change. This is not correct. People who wrote code under GPLv2 or later licenses would not need to be queried. The project could use the sources under a later version. Cheers Detlev -- X-Windows has to be the most expensive way ever of popping up an Emacs window. -- The UNIX Haters Handbook -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Detlev Zundel wrote: i personally dont have a problem with people locking their hardware. that is their choice and the GPLv2 allows them that freedom. You have a strange definition of freedom - for you it is limited to the provider of the devices not to the users of the devices. I guess this is what this all boils down to. No, it is let the device providers and the users who have *chosen* to use those devices sort it out themselves, *I'm* not restricting anyone. It's not strange or standing on your head, it's just a different opinion. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Tue, Jun 23, 2009 at 10:33 AM, Detlev Zundeld...@denx.de wrote: Is there any chance of convincing those authors to change that? Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be a neccessary precondition to only accept blessed firmware upgrades (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades. That isn't my reasoning. I license under GPLv2 because I like that license. I don't like GPLv3 because I think it is too complex and it tries to solve things that are non-problems for me. GPLv2 expresses well how I want to license my code. GPLv3 does not. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Trouble booting using board info
Hello, I'm trying to load Linux from U-Boot. I'm pretty new at this so there may be some obvious things wrong with what I'm doing. I am using ELDK 4.2 and U-Boot 2009.03 on an EP88xC rev1.1 board (MPC885 cpu) and the linux kernel sources obtained from instructions at http://www.denx.de/wiki/view/DULG/LinuxConfiguration#Section_6.1.;. Below is my output as it currently stands (with lots of debug output): U-Boot 2009.03-svn8591 (Jun 24 2009 - 10:24:20) CPU: MPC885ZPnn at 100 MHz [40.0...133.0 MHz] 8 kB I-Cache 8 kB D-Cache FEC present clock 1Hz != 30Hz Board: EP88xC 1.1 CPLD revision 2 DRAM: 64 MB Top of RAM usable for U-Boot at: 0400 Reserving 187k for U-Boot at: 03fd1000 Reserving 384k for malloc() at: 03f71000 Reserving 60 Bytes for Board Info at: 03f70fc4 Reserving 56 Bytes for Global Data at: 03f70f8c Stack Pointer at: 03f70f68 New Stack Pointer is: 03f70f68 Now running in RAM - U-Boot at: 03fd1000 FLASH: flash detect cfi fwc addr fc00 cmd f0 f0 8bit x 8 bit fwc addr fc00 cmd ff ff 8bit x 8 bit fwc addr fc55 cmd 98 98 8bit x 8 bit is= cmd 51(Q) addr fc10 is= 30 51 fwc addr fc000555 cmd 98 98 8bit x 8 bit is= cmd 51(Q) addr fc10 is= 30 51 fwc addr fc00 cmd f0 f0f0 16bit x 8 bit fwc addr fc00 cmd ff 16bit x 8 bit fwc addr fcaa cmd 98 9898 16bit x 8 bit is= cmd 51(Q) addr fc20 is= 3234 5151 fwc addr fc000aaa cmd 98 9898 16bit x 8 bit is= cmd 51(Q) addr fc20 is= 3234 5151 fwc addr fc00 cmd f0 00f0 16bit x 16 bit fwc addr fc00 cmd ff 00ff 16bit x 16 bit fwc addr fcaa cmd 98 0098 16bit x 16 bit is= cmd 51(Q) addr fc20 is= 3234 0051 fwc addr fc000aaa cmd 98 0098 16bit x 16 bit is= cmd 51(Q) addr fc20 is= 3234 0051 fwc addr fc00 cmd f0 f0f0f0f0 32bit x 8 bit fwc addr fc00 cmd ff 32bit x 8 bit fwc addr fc000154 cmd 98 98989898 32bit x 8 bit is= cmd 51(Q) addr fc40 is= 00510051 51515151 fwc addr fc001554 cmd 98 98989898 32bit x 8 bit is= cmd 51(Q) addr fc40 is= 00510051 51515151 fwc addr fc00 cmd f0 00f000f0 32bit x 16 bit fwc addr fc00 cmd ff 00ff00ff 32bit x 16 bit fwc addr fc000154 cmd 98 00980098 32bit x 16 bit is= cmd 51(Q) addr fc40 is= 00510051 00510051 is= cmd 52(R) addr fc44 is= 00520052 00520052 is= cmd 59(Y) addr fc48 is= 00590059 00590059 device interface is 2 found port 4 chip 2 port 32 bits chip 16 bits 00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 07 qr...@.'6... 10 : 07 0a 00 03 05 04 00 18 02 00 05 00 01 7f 00 00 20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 12 cc 27 ...' fwc addr fc00 cmd f0 00f000f0 32bit x 16 bit fwc addr fc001554 cmd aa 00aa00aa 32bit x 16 bit fwc addr fc000aa8 cmd 55 00550055 32bit x 16 bit fwc addr fc001554 cmd 90 00900090 32bit x 16 bit fwc addr fc00 cmd f0 00f000f0 32bit x 16 bit fwc addr fc000154 cmd 98 00980098 32bit x 16 bit manufacturer is 2 manufacturer id is 0x1 device id is 0x227e device id2 is 0x0 cfi version is 0x3133 size_ratio 2 port 32 bits chip 16 bits found 1 erase regions erase region 0: 0x027f erase_region_count = 128 erase_region_size = 131072 fwc addr fc00 cmd f0 00f000f0 32bit x 16 bit flash_protect ON: from 0xFC00 to 0xFC028FFF protect on 0 flash_protect ON: from 0xFC04 to 0xFC07 protect on 1 32 MB env_relocate[233] offset = 0x7fd1000 env_relocate[254] malloced ENV at 03f71008 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial U-Boot relocated to 03fd1000 Net: FEC ETHERNET, FEC2 ETHERNET ### main_loop entered: bootdelay=2 ### main_loop: bootcmd=bootm fc08 Hit any key to stop autoboot: 0 ## Current stack ends at 0x03f70d50 * kernel: cmdline image address = 0xfc08 Wrong Image Format for bootm command ERROR: can't get kernel image! = setenv ipaddr 10.0.54.150 = setenv serverip 10.0.54.129 = setenv ethaddr 00-e0-86-0c-84-fd eth_set_enetaddr(num=0, addr=00-e0-86-0c-84-fd) Setting new HW address on FEC ETHERNET New Address is 00:E0:86:0C:84:FD eth_set_enetaddr(num=0, addr=00-e0-86-0c-84-fd) Setting new HW address on FEC ETHERNET New Address is 00:E0:86:0C:84:FD = tftp 40 ep88x_uimage Trying FEC ETHERNET Using FEC ETHERNET device TFTP from server 10.0.54.129; our IP address is 10.0.54.150 Filename 'ep88x_uimage'. Load address: 0x40 Loading: # done Bytes transferred = 1057401 (102279 hex) = bootm 40 ## Current stack ends at 0x03f70d60 * kernel: cmdline image address = 0x0040 ## Booting kernel from Legacy Image at 0040 ... Image Name: Linux-2.6.30-rc2-01402-gd4e2f68 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1057337 Bytes = 1 MB Load Address: Entry Point: Verifying Checksum ... OK kernel data at 0x00400040, len = 0x00102239 (1057337) ## No init Ramdisk ramdisk start = 0x, ramdisk end
Re: [U-Boot] U-book and GPLv3? (fwd)
On Wednesday 24 June 2009 12:34:40 Detlev Zundel wrote: On Wednesday 24 June 2009 09:17:50 Detlev Zundel wrote: if you want to push your agenda on your customers (i'm assuming you actually have some and arent just here for fun), that's your business. Is it possible that you jump to conslusions here? All we - on a regular basis - do is to talk to our customers until we understand what the customer needs. Then we think about how this can or cannot be done with the help of Free Software. After all nobody is forcing anyone to use Free Software and for some customer wishes Free Software may simply be not a legal option, so what? In this process it is common that customers have incomplete information about Free Software in general and not well-articulated fears making them jump to premature conclusions (e.g. we need a closed source Linux kernel driver) which would prevent us from doing development for them. At this point it is extremely important to learn about the reasoning of the customer and then clearing up confusion probably leading to revisiting the question of using Free Software. Essentially I can only remember one customer in the last years who did not go further at the time after learning that we would not develop a non-GPL kernel module. Incidentally this customer is now back on our doorstep because the market effectively forces him to use a GNU/Linux system from a feature perspective. This time around closed sources kernel modules are not even on the agenda anymore. and that's your prerogative. how you choose to run your business has no bearing at all on how other people choose to run their businesses. All I said is that we have a pretty good idea of what is legal and what isn;t and that we will not start work in an area where we belive we could actually be liable by law. How you come to the conclusion that this is prerogative completely escapes me. Are you sure that you are interested in what I say? i think you are interpreting the word incorrectly. it is your prerogative -- your right -- to run your business however you want. but when customers absolutely state their requirements are secure boot and the ability to lock their hardware so no one else can run things, then i'm not about to argue with them. their response is simply fine, we'll move on to the next guy who will satisfy our requirements. It is your decision if you don't want to even understand your customers needs. wrong, we've actually done the opposite. we know what they want to do and it is doable with GPLv2. it is not doable with GPLv3. From what I read, I do not get this impression. Locking people out is not a ulterior motive but the outcome of a perceived threat to a business model. It was this business model that I wanted to get a clear picture of. It seems I cannot get any more informatino here. locking down a machine is part of due diligence as well when it comes to certification. not taking measures to prevent uncertified code from running is a legal liability for companies. you can chalk these use cases up as perceived threads to a business model all you like. many customers arent going to change because of your opinion, and while you may not business with them, i dont have a problem with doing it. yes, there are cases of ingrained perceptions about how to accomplish something and GPLv3 blocks those methods. but again, it is *your* choice to attempt to educate people here, it is not the automatic burden of people to champion the GNU cause for you. What kind of axe do you have to grind here? We (as a project) were asked about our stance to move to GPLv3 which is a perfectly good question to pose. All I want to do is collect facts - your allegation that I want other people to carry a burden shows me that this way will bear no more fruit. i wasnt directing all of these comments directly at you. i dont know you nor do i care. if the GNU project wants people to use the GPLv3 and people have a perception of it being crap, then it's their problem to address it. they arent generally trying to lock out people who just want to toy, they're targeting people who want to clone their hardware or functionality to create knockoffs or they're trying to guarantee lock down so they can get certified (like medical devices). How does GPLv3 vs. GPLv2 touch the we will get cloned question? Maybe I do not see the obvious here, but sourcecode to binaries under either license must be available, so what's the difference? if you dont have the decryption keys, you cant read the end program. having access to the u-boot source doesnt matter. Having access to the physical device will. How long do you think will it take to get broken into? Unfortunately physics do not follow wishes of companies as seen over and over in the past. and companies understand that. i never said locking
Re: [U-Boot] U-book and GPLv3? (fwd)
On Wednesday 24 June 2009 12:45:38 Detlev Zundel wrote: It is secure because only authenticated code is allowed to be executed, thus another step to avoid piracy, hacking of conditional access systems etc. Running only authenticated code does *not* ensure security, no matter how much this is wished for. But no matter, I now understand that security seems to mean data can only be handled in the way intended by the owners of the data which is a different concept to me. you ignored my simple straightforward example where both authenticity and security is provided. cpu only loads signed u-boot -- authenticity. u-boot only loads encrypted signed binaries -- security and authenticity. since the binaries stay inside of the CPU, for all practical (and then some) purposes, the decrypted binary will never be discovered from this system. and unless you're lumping data and code together under the term data, that part is also incorrect. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Wed, Jun 24, 2009 at 12:56 PM, Detlev Zundeld...@denx.de wrote: Hi Jon, There is an enormous practical consideration stopping the licensing change. u-boot has not required copyright assignment. This means that every single person that has contributed code to u-boot needs to give their permission for the change. This is not correct. People who wrote code under GPLv2 or later licenses would not need to be queried. The project could use the sources under a later version. There is a mix of GPLv2 or later and GPLv2 code. You will have to sort which license applies. Let's hope nobody modified a GPL v2 header in any file to say GPL v2 or later. That would open a giant can of worms. This is a giant administrative nightmare. The effort for doing this exceeds the effort require to write a new boot loader. Require copyright assignment on the new boot loader and then the license can be easily changed. -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v5] KB9202: Add NAND support
On Wed, Jun 24, 2009 at 05:23:05PM +0200, Matthias Kaehlcke wrote: Add NAND support for the KwikByte KB9202 Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net --- El Tue, Jun 23, 2009 at 04:19:40PM -0500 Scott Wood ha dit: I get conflicts in kb9202.h. Is this against an arch tree, or does it need to be respun? The previous patches were against v2009-03, as i had problems building the current git head for the kb9202 when i started working on the patch. Did you apply the first patch of this series when you got the conflict? This patch is based on the current HEAD. No - if it depends on other patches that go through an arch tree, then this patch should go through that tree as well. Acked-by: Scott Wood scottw...@freescale.com -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 8313erdb: Enable CONFIG_SYS_64BIT_VSPRINTF.
This is now required by the NAND subsystem. Signed-off-by: Scott Wood scottw...@freescale.com --- include/configs/MPC8313ERDB.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h index 2308568..92f74cc 100644 --- a/include/configs/MPC8313ERDB.h +++ b/include/configs/MPC8313ERDB.h @@ -299,6 +299,8 @@ #define CONFIG_OF_BOARD_SETUP 1 #define CONFIG_OF_STDOUT_VIA_ALIAS 1 +#define CONFIG_SYS_64BIT_VSPRINTF 1 + /* * Serial Port */ -- 1.5.6.rc1.6.gc53ad ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nand_spl: Fix cmd_ctrl usage in nand_boot.c.
When adding large page NAND support to this file, I had a misunderstanding about the exact semantics of NAND_CTRL_CHANGE (which isn't documented anywhere I can find) -- it is apparently just a hint to drivers, which aren't required to preserve the old value for subsequent non-change invocations. This change makes nand_boot.c no longer assume this. Note that this happened to work by chance with some NAND drivers, which don't preserve the value, but treat 0 equivalently to NAND_CTRL_ALE. I don't have hardware to test this, so any testing is appreciated. Signed-off-by: Scott Wood scottw...@freescale.com --- Applied to u-boot-nand-flash. nand_spl/nand_boot.c | 18 +++--- 1 files changed, 11 insertions(+), 7 deletions(-) diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c index be2e69c..b9fd6f5 100644 --- a/nand_spl/nand_boot.c +++ b/nand_spl/nand_boot.c @@ -47,11 +47,13 @@ static int nand_command(struct mtd_info *mtd, int block, int page, int offs, u8 /* Set ALE and clear CLE to start address cycle */ /* Column address */ this-cmd_ctrl(mtd, offs, NAND_CTRL_ALE | NAND_CTRL_CHANGE); - this-cmd_ctrl(mtd, page_addr 0xff, 0); /* A[16:9] */ - this-cmd_ctrl(mtd, (page_addr 8) 0xff, 0); /* A[24:17] */ + this-cmd_ctrl(mtd, page_addr 0xff, NAND_CTRL_ALE); /* A[16:9] */ + this-cmd_ctrl(mtd, (page_addr 8) 0xff, + NAND_CTRL_ALE); /* A[24:17] */ #ifdef CONFIG_SYS_NAND_4_ADDR_CYCLE /* One more address cycle for devices 32MiB */ - this-cmd_ctrl(mtd, (page_addr 16) 0x0f, 0); /* A[28:25] */ + this-cmd_ctrl(mtd, (page_addr 16) 0x0f, + NAND_CTRL_ALE); /* A[28:25] */ #endif /* Latch in address */ this-cmd_ctrl(mtd, NAND_CMD_NONE, NAND_NCE | NAND_CTRL_CHANGE); @@ -94,13 +96,15 @@ static int nand_command(struct mtd_info *mtd, int block, int page, int offs, u8 /* Column address */ this-cmd_ctrl(mtd, offs 0xff, NAND_CTRL_ALE | NAND_CTRL_CHANGE); /* A[7:0] */ - this-cmd_ctrl(mtd, (offs 8) 0xff, 0); /* A[11:9] */ + this-cmd_ctrl(mtd, (offs 8) 0xff, NAND_CTRL_ALE); /* A[11:9] */ /* Row address */ - this-cmd_ctrl(mtd, (page_addr 0xff), 0); /* A[19:12] */ - this-cmd_ctrl(mtd, ((page_addr 8) 0xff), 0); /* A[27:20] */ + this-cmd_ctrl(mtd, (page_addr 0xff), NAND_CTRL_ALE); /* A[19:12] */ + this-cmd_ctrl(mtd, ((page_addr 8) 0xff), + NAND_CTRL_ALE); /* A[27:20] */ #ifdef CONFIG_SYS_NAND_5_ADDR_CYCLE /* One more address cycle for devices 128MiB */ - this-cmd_ctrl(mtd, (page_addr 16) 0x0f, 0); /* A[31:28] */ + this-cmd_ctrl(mtd, (page_addr 16) 0x0f, + NAND_CTRL_ALE); /* A[31:28] */ #endif /* Latch in address */ this-cmd_ctrl(mtd, NAND_CMD_READSTART, -- 1.5.6.rc1.6.gc53ad ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 8313erdb: Enable CONFIG_SYS_64BIT_VSPRINTF.
On Wed, 24 Jun 2009 17:11:48 -0500 Scott Wood scottw...@freescale.com wrote: This is now required by the NAND subsystem. Signed-off-by: Scott Wood scottw...@freescale.com --- abd. see: http://lists.denx.de/pipermail/u-boot/2009-June/054383.html Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH-ARM] Add support for Embest SBC2440-II Board 3/7
This patch re-formats the s3c24x0 driver code, excluding the MTD NAND
driver which is in patch 4, in preparation for changes to make the
NAND driver support both s3c2410 and s3c2440 CPU's, ready for the
addition of the Embest SBC2440-II Board.
The changes are as follows:
- re-indent the code using Lindent
- mak sure register layouts are defined using a C struct, from a
comment by Wolfgang on 03/06/2009
- replace the upper-case typedef'ed C struct names with lower case
non-typedef'ed ones, from a comment by Scott on 22/06/2009
- make sure registers are accessed using the proper accessor
functions, from a comment by Wolfgang on 03/06/2009
- run checkpatch.pl and fix any error reports
Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk
---
board/mpl/vcma9/vcma9.c |7 +-
board/mpl/vcma9/vcma9.h | 18 ++--
board/samsung/smdk2400/smdk2400.c |5 +-
board/samsung/smdk2410/smdk2410.c |5 +-
board/sbc2410x/sbc2410x.c |7 +-
board/trab/cmd_trab.c |8 +-
board/trab/rs485.c| 12 +-
board/trab/trab.c | 17 ++-
board/trab/trab_fkt.c | 22 ++--
board/trab/tsc2000.c | 17 ++-
board/trab/tsc2000.h |4 +-
board/trab/vfd.c | 12 +-
drivers/i2c/s3c24x0_i2c.c | 273 +++--
drivers/rtc/s3c24x0_rtc.c | 134 +-
drivers/serial/serial_s3c24x0.c | 160 --
15 files changed, 368 insertions(+), 333 deletions(-)
diff --git a/board/mpl/vcma9/vcma9.c b/board/mpl/vcma9/vcma9.c
index a4c463a..3d0947d 100644
--- a/board/mpl/vcma9/vcma9.c
+++ b/board/mpl/vcma9/vcma9.c
@@ -71,8 +71,9 @@ static inline void delay(unsigned long loops)
int board_init(void)
{
- S3C24X0_CLOCK_POWER * const clk_power = S3C24X0_GetBase_CLOCK_POWER();
- S3C24X0_GPIO * const gpio = S3C24X0_GetBase_GPIO();
+ struct s3c24x0_clock_power * const clk_power =
+ S3C24X0_GetBase_CLOCK_POWER();
+ struct s3c24x0_gpio * const gpio = S3C24X0_GetBase_GPIO();
/* to reduce PLL lock time, adjust the LOCKTIME register */
clk_power-LOCKTIME = 0xFF;
@@ -172,7 +173,7 @@ static inline void NF_Init(void)
void
nand_init(void)
{
- S3C2410_NAND * const nand = S3C2410_GetBase_NAND();
+ struct s3c2410_nand * const nand = S3C2410_GetBase_NAND();
NF_Init();
#ifdef DEBUG
diff --git a/board/mpl/vcma9/vcma9.h b/board/mpl/vcma9/vcma9.h
index 220b705..8f98e9e 100644
--- a/board/mpl/vcma9/vcma9.h
+++ b/board/mpl/vcma9/vcma9.h
@@ -39,14 +39,14 @@ typedef enum {
static inline void NF_Conf(u16 conf)
{
- S3C2410_NAND * const nand = S3C2410_GetBase_NAND();
+ struct s3c2410_nand * const nand = S3C2410_GetBase_NAND();
nand-NFCONF = conf;
}
static inline void NF_Cmd(u8 cmd)
{
- S3C2410_NAND * const nand = S3C2410_GetBase_NAND();
+ struct s3c2410_nand * const nand = S3C2410_GetBase_NAND();
nand-NFCMD = cmd;
}
@@ -59,14 +59,14 @@ static inline void NF_CmdW(u8 cmd)
static inline void NF_Addr(u8 addr)
{
- S3C2410_NAND * const nand = S3C2410_GetBase_NAND();
+ struct s3c2410_nand * const nand = S3C2410_GetBase_NAND();
nand-NFADDR = addr;
}
static inline void NF_SetCE(NFCE_STATE s)
{
- S3C2410_NAND * const nand = S3C2410_GetBase_NAND();
+ struct s3c2410_nand * const nand = S3C2410_GetBase_NAND();
switch (s) {
case NFCE_LOW:
@@ -81,35 +81,35 @@ static inline void NF_SetCE(NFCE_STATE s)
static inline void NF_WaitRB(void)
{
- S3C2410_NAND * const nand = S3C2410_GetBase_NAND();
+ struct s3c2410_nand * const nand = S3C2410_GetBase_NAND();
while (!(nand-NFSTAT (10)));
}
static inline void NF_Write(u8 data)
{
- S3C2410_NAND * const nand = S3C2410_GetBase_NAND();
+ struct s3c2410_nand * const nand = S3C2410_GetBase_NAND();
nand-NFDATA = data;
}
static inline u8 NF_Read(void)
{
- S3C2410_NAND * const nand = S3C2410_GetBase_NAND();
+ struct s3c2410_nand * const nand = S3C2410_GetBase_NAND();
return(nand-NFDATA);
}
static inline void NF_Init_ECC(void)
{
- S3C2410_NAND * const nand = S3C2410_GetBase_NAND();
+ struct s3c2410_nand * const nand = S3C2410_GetBase_NAND();
nand-NFCONF |= (112);
}
static inline u32 NF_Read_ECC(void)
{
- S3C2410_NAND * const nand = S3C2410_GetBase_NAND();
+ struct s3c2410_nand * const nand = S3C2410_GetBase_NAND();
return(nand-NFECC);
}
diff --git a/board/samsung/smdk2400/smdk2400.c
b/board/samsung/smdk2400/smdk2400.c
index 0b82070..9f75d01 100644
--- a/board/samsung/smdk2400/smdk2400.c
+++ b/board/samsung/smdk2400/smdk2400.c
@@ -45,8 +45,9 @@ extern int do_mdm_init; /* defined in common/main.c */
int board_init (void)
{
- S3C24X0_CLOCK_POWER * const
[U-Boot] [PATCH-ARM, MTD] Add support for Embest SBC2440-II Board 4/7
This patch re-formats the s3c24x0 NAND driver code in preparation for
changes to make the NAND driver support both s3c2410 and s3c2440 CPU's,
ready for the addition of the Embest SBC2440-II Board.
The changes are as follows:
- re-indent the code using Lindent
- make sure register layouts are defined using a C struct, from a
comment by Wolfgang on 03/06/2009
- replace the upper-case typedef'ed C struct names with lower case
non-typedef'ed ones, from a comment by Scott on 22/06/2009
- make sure registers are accessed using the proper accessor
functions, from a comment by Wolfgang on 03/06/2009
- run checkpatch.pl and fix any error reports
The patches were tested after applying patches 1-4. Testing was done
by running MAKEALL for all ARM9 targets and checking that no new
warnings or errors were introduced.
Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk
---
drivers/mtd/nand/s3c2410_nand.c | 62 +++---
1 files changed, 25 insertions(+), 37 deletions(-)
diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
index d27a625..1dfe59e 100644
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ b/drivers/mtd/nand/s3c2410_nand.c
@@ -20,29 +20,10 @@
#include common.h
-#if 0
-#define DEBUGN printf
-#else
-#define DEBUGN(x, args ...) {}
-#endif
-
#include nand.h
#include s3c2410.h
#include asm/io.h
-#define __REGb(x) (*(volatile unsigned char *)(x))
-#define __REGi(x) (*(volatile unsigned int *)(x))
-
-#defineNF_BASE 0x4e00
-#defineNFCONF __REGi(NF_BASE + 0x0)
-#defineNFCMD __REGb(NF_BASE + 0x4)
-#defineNFADDR __REGb(NF_BASE + 0x8)
-#defineNFDATA __REGb(NF_BASE + 0xc)
-#defineNFSTAT __REGb(NF_BASE + 0x10)
-#define NFECC0 __REGb(NF_BASE + 0x14)
-#define NFECC1 __REGb(NF_BASE + 0x15)
-#define NFECC2 __REGb(NF_BASE + 0x16)
-
#define S3C2410_NFCONF_EN (115)
#define S3C2410_NFCONF_512BYTE (114)
#define S3C2410_NFCONF_4STEP (113)
@@ -58,11 +39,12 @@
static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct nand_chip *chip = mtd-priv;
+ struct s3c2410_nand *nand = S3C2410_GetBase_NAND();
- DEBUGN(hwcontrol(): 0x%02x 0x%02x\n, cmd, ctrl);
+ debugX(1, hwcontrol(): 0x%02x 0x%02x\n, cmd, ctrl);
if (ctrl NAND_CTRL_CHANGE) {
- ulong IO_ADDR_W = NF_BASE;
+ ulong IO_ADDR_W = (ulong)nand;
if (!(ctrl NAND_CLE))
IO_ADDR_W |= S3C2410_ADDR_NCLE;
@@ -72,9 +54,11 @@ static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
chip-IO_ADDR_W = (void *)IO_ADDR_W;
if (ctrl NAND_NCE)
- NFCONF = ~S3C2410_NFCONF_nFCE;
+ writel(readl(nand-NFCONF) ~S3C2410_NFCONF_nFCE,
+ nand-NFCONF);
else
- NFCONF |= S3C2410_NFCONF_nFCE;
+ writel(readl(nand-NFCONF) | S3C2410_NFCONF_nFCE,
+ nand-NFCONF);
}
if (cmd != NAND_CMD_NONE)
@@ -83,15 +67,17 @@ static void s3c2410_hwcontrol(struct mtd_info *mtd, int
cmd, unsigned int ctrl)
static int s3c2410_dev_ready(struct mtd_info *mtd)
{
- DEBUGN(dev_ready\n);
- return (NFSTAT 0x01);
+ struct s3c2410_nand *nand = S3C2410_GetBase_NAND();
+ debugX(1, dev_ready\n);
+ return readl(nand-NFSTAT) 0x01;
}
#ifdef CONFIG_S3C2410_NAND_HWECC
void s3c2410_nand_enable_hwecc(struct mtd_info *mtd, int mode)
{
- DEBUGN(s3c2410_nand_enable_hwecc(%p, %d)\n, mtd, mode);
- NFCONF |= S3C2410_NFCONF_INITECC;
+ struct s3c2410_nand *nand = S3C2410_GetBase_NAND();
+ debugX(1, s3c2410_nand_enable_hwecc(%p, %d)\n, mtd, mode);
+ writel(readl(nand-NFCONF) | S3C2410_NFCONF_INITECC, nand-NFCONF);
}
static int s3c2410_nand_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
@@ -100,8 +86,8 @@ static int s3c2410_nand_calculate_ecc(struct mtd_info *mtd,
const u_char *dat,
ecc_code[0] = NFECC0;
ecc_code[1] = NFECC1;
ecc_code[2] = NFECC2;
- DEBUGN(s3c2410_nand_calculate_hwecc(%p,): 0x%02x 0x%02x 0x%02x\n,
- mtd , ecc_code[0], ecc_code[1], ecc_code[2]);
+ debugX(1, s3c2410_nand_calculate_hwecc(%p,): 0x%02x 0x%02x 0x%02x\n,
+ mtd , ecc_code[0], ecc_code[1], ecc_code[2]);
return 0;
}
@@ -123,24 +109,26 @@ int board_nand_init(struct nand_chip *nand)
{
u_int32_t cfg;
u_int8_t tacls, twrph0, twrph1;
- S3C24X0_CLOCK_POWER * const clk_power = S3C24X0_GetBase_CLOCK_POWER();
+ struct s3c24x0_clock_power *clk_power = S3C24X0_GetBase_CLOCK_POWER();
+ struct s3c2410_nand *nand_reg = S3C2410_GetBase_NAND();
- DEBUGN(board_nand_init()\n);
+
[U-Boot] [PATCH-ARM] Add support for Embest SBC2440-II Board 5/7
Patches 5 to 7, replace [PATCH-ARM 2/2] Add support for the Embest SBC2440-II Board 2/2 submitted on 19/06/2009. This patch adds support for the s3c2440 cpu, excluding the NAND driver which is in patch 6/7. This patch assume the following patches have already been applied: - [PATCH-ARM] Bug-fix in drivers mtd nand Makefile, sent 18/06/2009 - [PATCH-ARM] CONFIG_SYS_HZ fix for ARM920T S3C24X0 Boards, sent 21/06/2009 The patch was tested by running MAKEALL for all ARM9 targets and checking that no new warnings or errors were introduced. Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk --- common/serial.c |4 +- cpu/arm920t/s3c24x0/Makefile |2 + cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S | 81 + cpu/arm920t/s3c24x0/speed.c | 41 +-- cpu/arm920t/s3c24x0/timer.c | 20 +--- cpu/arm920t/s3c24x0/usb.c| 17 +-- cpu/arm920t/s3c24x0/usb_ohci.c | 11 +-- cpu/arm920t/start.S | 39 +-- drivers/i2c/s3c24x0_i2c.c| 18 ++-- drivers/mtd/nand/s3c2410_nand.c |2 +- drivers/rtc/s3c24x0_rtc.c|7 +- drivers/serial/serial_s3c24x0.c |6 +- drivers/usb/host/ohci-hcd.c |3 +- include/common.h |5 +- include/configs/VCMA9.h |4 +- include/configs/sbc2410x.h |4 +- include/configs/smdk2400.h |4 +- include/configs/smdk2410.h |4 +- include/configs/trab.h |4 +- include/s3c2410.h| 25 include/s3c2440.h| 162 ++ include/s3c24x0.h| 94 ++- include/s3c24x0_cpu.h| 29 + 23 files changed, 468 insertions(+), 118 deletions(-) create mode 100644 cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S create mode 100644 include/s3c2440.h create mode 100644 include/s3c24x0_cpu.h diff --git a/common/serial.c b/common/serial.c index dd80e7c..6548b8b 100644 --- a/common/serial.c +++ b/common/serial.c @@ -58,7 +58,7 @@ struct serial_device *__default_serial_console (void) #else return serial0_device; #endif -#elif defined(CONFIG_S3C2410) +#elif defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440) #if defined(CONFIG_SERIAL1) return s3c24xx_serial0_device; #elif defined(CONFIG_SERIAL2) @@ -133,7 +133,7 @@ void serial_initialize (void) #if defined (CONFIG_STUART) serial_register(serial_stuart_device); #endif -#if defined(CONFIG_S3C2410) +#if defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440) serial_register(s3c24xx_serial0_device); serial_register(s3c24xx_serial1_device); serial_register(s3c24xx_serial2_device); diff --git a/cpu/arm920t/s3c24x0/Makefile b/cpu/arm920t/s3c24x0/Makefile index 5d2be2c..f030515 100644 --- a/cpu/arm920t/s3c24x0/Makefile +++ b/cpu/arm920t/s3c24x0/Makefile @@ -25,6 +25,8 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(SOC).a +SOBJS += arch_pre_lowlevel_init.o + COBJS += speed.o COBJS += timer.o COBJS += usb.o diff --git a/cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S b/cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S new file mode 100644 index 000..13467cf --- /dev/null +++ b/cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S @@ -0,0 +1,81 @@ +/* + * (C) Copyright 2009 + * Kevin Morfitt, Fearnside Systems Ltd, kevin.morf...@fearnside-systems.co.uk + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include config.h + +#ifdef CONFIG_S3C24X0 + +/* Register addresses. */ +# ifdef CONFIG_S3C2400 + #define pWTCON 0x1530 + #define INTMSK 0x1448 + #define CLKDIVN 0x14800014 +#else + #define pWTCON 0x5300 + #define INTMSK 0x4A08 + #define INTSUBMSK 0x4A1C + #define CLKDIVN 0x4C14 +#endif + +/* Configuration values. */ +#ifdef CONFIG_S3C2440 + #define INTSMASK0x + #define CLKDIVVAL 0x5 +#else + #define INTSMASK0x3ff +
[U-Boot] [PATCH-ARM, MTD] Add support for Embest SBC2440-II Board 6/7
This patch adds support for the s3c2440 cpu to the MTD NAND driver. The
changes were based heavily on the Linux-2.6.30 s3c2410 MTD NAND driver
which also supports the s3c2440 cpu. I've tested these changes on an
s3c2440 cpu (on the Embest SBC2440-II Board) but not on an s3c2410 cpu
as none of the u-boot s3c2410 boards use the MTD NAND driver and anyway,
I don't have an s3c2410 board. I have, however, checked that it builds
OK for an s3c2410 cpu.
This patch assume the following patches have already been applied:
- [PATCH-ARM] Bug-fix in drivers mtd nand Makefile, sent 18/06/2009
- [PATCH-ARM] CONFIG_SYS_HZ fix for ARM920T S3C24X0 Boards, sent
21/06/2009
The patch was tested by running MAKEALL for all ARM9 targets and
checking that no new warnings or errors were introduced.
Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk
---
drivers/mtd/nand/s3c2410_nand.c | 134 +--
1 files changed, 73 insertions(+), 61 deletions(-)
diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
index 5157941..991064a 100644
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ b/drivers/mtd/nand/s3c2410_nand.c
@@ -2,6 +2,10 @@
* (C) Copyright 2006 OpenMoko, Inc.
* Author: Harald Welte lafo...@openmoko.org
*
+ * Modified to add S3C2440 support by
+ * (C) Copyright 2009
+ * Kevin Morfitt, Fearnside Systems Ltd,
kevin.morf...@fearnside-systems.co.uk
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -21,48 +25,53 @@
#include common.h
#include nand.h
+#include linux/mtd/nand_ecc.h
#include s3c24x0_cpu.h
#include asm/io.h
-#define S3C2410_NFCONF_EN (115)
-#define S3C2410_NFCONF_512BYTE (114)
-#define S3C2410_NFCONF_4STEP (113)
-#define S3C2410_NFCONF_INITECC (112)
-#define S3C2410_NFCONF_nFCE(111)
-#define S3C2410_NFCONF_TACLS(x)((x)8)
-#define S3C2410_NFCONF_TWRPH0(x) ((x)4)
-#define S3C2410_NFCONF_TWRPH1(x) ((x)0)
+#if defined(CONFIG_S3C2410_NAND_HWECC) defined(CONFIG_SYS_NAND_LARGEPAGE)
+/* new oob placement block for use with hardware ecc generation
+ */
+static struct nand_ecclayout nand_hw_eccoob = {
+ .eccbytes = 3,
+ .eccpos = {0, 1, 2},
+ .oobfree = { {8, 8} }
+};
+#endif
-#define S3C2410_ADDR_NALE 4
-#define S3C2410_ADDR_NCLE 8
+static void s3c2410_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct s3c2410_nand *nand = S3C2410_GetBase_NAND();
+ unsigned long reg = readl(nand-S3C24X0_NAND_CTRL_REG);
+
+ if (chip == -1) {
+ debugX(1, Negating nFCE\n);
+ reg |= S3C24X0_NAND_nFCE_BIT;
+ } else {
+ debugX(1, Asserting nFCE\n);
+ reg = ~S3C24X0_NAND_nFCE_BIT;
+ }
+ writel(reg, nand-S3C24X0_NAND_CTRL_REG);
+}
static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
- struct nand_chip *chip = mtd-priv;
struct s3c2410_nand *nand = S3C2410_GetBase_NAND();
debugX(1, hwcontrol(): 0x%02x 0x%02x\n, cmd, ctrl);
- if (ctrl NAND_CTRL_CHANGE) {
- ulong IO_ADDR_W = (ulong)nand;
-
- if (!(ctrl NAND_CLE))
- IO_ADDR_W |= S3C2410_ADDR_NCLE;
- if (!(ctrl NAND_ALE))
- IO_ADDR_W |= S3C2410_ADDR_NALE;
-
- chip-IO_ADDR_W = (void *)IO_ADDR_W;
+ if (cmd == NAND_CMD_NONE)
+ return;
- if (ctrl NAND_NCE)
- writel(readl(nand-NFCONF) ~S3C2410_NFCONF_nFCE,
- nand-NFCONF);
- else
- writel(readl(nand-NFCONF) | S3C2410_NFCONF_nFCE,
- nand-NFCONF);
+ if (ctrl NAND_CLE) {
+ debugX(1, NFCMD = 0x%08X\n, cmd);
+ writel(cmd, nand-NFCMD);
}
- if (cmd != NAND_CMD_NONE)
- writeb(cmd, chip-IO_ADDR_W);
+ if (ctrl NAND_ALE) {
+ debugX(1, NFADDR = 0x%08X\n, cmd);
+ writel(cmd, nand-NFADDR);
+ }
}
static int s3c2410_dev_ready(struct mtd_info *mtd)
@@ -76,39 +85,32 @@ static int s3c2410_dev_ready(struct mtd_info *mtd)
void s3c2410_nand_enable_hwecc(struct mtd_info *mtd, int mode)
{
struct s3c2410_nand *nand = S3C2410_GetBase_NAND();
+ unsigned long reg = readl(nand-S3C24X0_NAND_CTRL_REG);
+
debugX(1, s3c2410_nand_enable_hwecc(%p, %d)\n, mtd, mode);
- writel(readl(nand-NFCONF) | S3C2410_NFCONF_INITECC, nand-NFCONF);
+ reg |= S3C24X0_NAND_INITECC_BIT;
+ writel(reg, nand-S3C24X0_NAND_CTRL_REG);
}
static int s3c2410_nand_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
u_char *ecc_code)
{
- ecc_code[0] = NFECC0;
- ecc_code[1] = NFECC1;
- ecc_code[2]
[U-Boot] [PATCH-ARM] Add support for Embest SBC2440-II Board 7/7
This patch adds support for the Embest SBC2440-II Board. The patch was tested by: - running MAKEALL for all ARM9 targets and checking that no new warnings or errors were introduced - programming it into NOR flash of an Embest SBC2440-II Board, loading kernel and root file system images via ftp, programming them into NAND flash and checking that u-boot successfully starts the kernel at re-boot Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk --- MAINTAINERS|4 + MAKEALL|1 + Makefile |3 + board/embest/sbc2440ii/Makefile| 55 +++ board/embest/sbc2440ii/config.mk | 25 board/embest/sbc2440ii/lowlevel_init.S | 219 board/embest/sbc2440ii/sbc2440ii.c | 109 ++ cpu/arm920t/s3c24x0/timer.c|1 + include/configs/sbc2440ii.h| 247 9 files changed, 664 insertions(+), 0 deletions(-) create mode 100644 board/embest/sbc2440ii/Makefile create mode 100644 board/embest/sbc2440ii/config.mk create mode 100644 board/embest/sbc2440ii/lowlevel_init.S create mode 100644 board/embest/sbc2440ii/sbc2440ii.c create mode 100644 include/configs/sbc2440ii.h diff --git a/MAINTAINERS b/MAINTAINERS index 9379c7e..39c938e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -578,6 +578,10 @@ Nishanth Menon n...@ti.com omap3_zoom1 ARM CORTEX-A8 (OMAP3xx SoC) +Kevin Morfitt kevin.morf...@fearnside-systems.co.uk + + sbc2440ii ARM920T + David Müller d.muel...@elsoft.ch smdk2410ARM920T diff --git a/MAKEALL b/MAKEALL index f4599d6..ae95ffa 100755 --- a/MAKEALL +++ b/MAKEALL @@ -519,6 +519,7 @@ LIST_ARM9= \ omap5912osk \ omap730p2 \ sbc2410x\ + sbc2440ii \ scb9328 \ smdk2400\ smdk2410\ diff --git a/Makefile b/Makefile index bcc81c9..e8cdbe3 100644 --- a/Makefile +++ b/Makefile @@ -2898,6 +2898,9 @@ omap730p2_cs3boot_config :unconfig sbc2410x_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t sbc2410x NULL s3c24x0 +sbc2440ii_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm920t sbc2440ii embest s3c24x0 + scb9328_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t scb9328 NULL imx diff --git a/board/embest/sbc2440ii/Makefile b/board/embest/sbc2440ii/Makefile new file mode 100644 index 000..26237a2 --- /dev/null +++ b/board/embest/sbc2440ii/Makefile @@ -0,0 +1,55 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# Modified for EMBEST SBC2440-II board with S3C2440 (ARM920T) cpu by: +# (C) Copyright 2009 +# Kevin Morfitt, Fearnside Systems Ltd, kevin.morf...@fearnside-systems.co.uk +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).a + +COBJS := sbc2440ii.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/embest/sbc2440ii/config.mk b/board/embest/sbc2440ii/config.mk new file mode 100644 index 000..def11d8 --- /dev/null +++ b/board/embest/sbc2440ii/config.mk @@ -0,0 +1,25 @@ +# +# (C) Copyright 2002 +# Gary Jennejohn, DENX Software Engineering, g...@denx.de +# David Mueller, ELSOFT AG, d.muel...@elsoft.ch +# +# SAMSUNG SMDK2410 board with S3C2410X (ARM920T) cpu +# +# see http://www.samsung.com/ for more information on SAMSUNG +# +# Modified for EMBEST SBC2440-II board with S3C2440 (ARM920T) cpu by: +# (C) Copyright 2009
Re: [U-Boot] U-book and GPLv3? (fwd)
The NAND subsystem is from Linux and is GPL v2 only, as is the u-boot-specific NAND code in drivers/mtd/nand. Ok, thanks for that info. Subtracting the drivers this is ~5k LOC, right? Two ways of dealing with ths include (1) contacting the developers and asking then to relicense, and (2) writing a replacement (it's not that big). The FSF can't offer to rewrite it, but we could halp find any developers who are now difficult to contact. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
Embedded systems using core soc silicon from a number of manufacturers have started to use what is known as 'secure boot'. This is typically the case in applications which utilise conditional access system software to protect content. The emphasis on using secure boot is largely driven by the conditional access industry itself. The principal purpose of these products is to restrict the public's freedom. So it is natural that their means involve restricting our freedom too. In DefectiveByDesign.org we organize protests against such devices. They don't deserve help. In this context, I believe both terms are interchangeable and effectively mean the same thing. It is secure because only authenticated code is allowed to be executed, thus another step to avoid piracy, If that is meant to refer to sharing of copies of published works, please don't call that piracy. That is a propaganda term which is used to spread the assumption that sharing is bad. See http://www.gnu.org/philosophy/words-to-avoid.html. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
I can assure you that today If we switch the V2 to the v3 we will lose a lot of customers Are the users of U-Boot usually customers? That term normally refers to people that buy a commercial product or service. And force to give the private key which use to sign the code is not reallist it's a security flaw I have a computer on which I can install any code I choose. I don't think that is a security flaw. On the contrary, if only one company can install a new version, that is a grave security flaw for me as a user. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
their response is simply fine, we'll move on to the next= =20 guy who will satisfy our requirements. When people offer to use my programs if I relax the license requirements, my respose to them is, If you don't use my software, that's your loss. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] EHCI and OHCI deriver in u-boot-2009.03
Hi, I am using diver of EHCI and OHCI in u-boot-2009.03. My HC is ISP1564, this HC has multi-function, it supports OHCI and EHCI. So, I think that maybe we must define new macros in my NSB405EP.h which is in ./include/config dir. But I find there are many functions in usb_ohci.c and usb_ehci_core.c defined as the same name,so I do not know how to use them at the same time in my project to support both OHCI and EHCI. Any way, another problem is that I can scan 2 functions in pci bus while using cmd: pci. As know that when HC power on, the ports ownership is under OHCI, how can I switch the owmship to EHCI???(write bit OCR of HcControl may not useful while I used). Also, another problem is that: u-boot allocate base address and size for both OHCI and EHCI while HC be found on pci bus. This step has not problem. OHCI base = 0x8000, size = 0x1000, EHCI base = 0x80001000, size = 0x100. Then I used command md to display the memory on 0x8000(ohci) has no problem. But When display memory 0x80001000(ehci), u-boot go to dead as belows : =md 80001000 =80001000: 20009500 then the terminal will not display any more info and will not receive any keys you pressed.Maybe u-boot go to dead this time. So I do not know why. Can anybody help me or provide me some useful info about using muti-function usb HC in u-boot ??? Thanks, Josh Wei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocating to my code.
Detlev Zundel wrote: Hi Prathika, I did not mean it should run from flash itself..My application will just reside in flash, I will read back from flash to a RAM location. To be honest, I have trouble understanding this. As I understand, in board_init_f(), after calling the init_sequence, relocate_code() is called and it is a must to call relocate_code(), from where it branches to main_loop(). My aim is to branch to my application code before calling relocate_code().My application code's executable address is 0x40004. Well, if you are working on a PowerPC platform, then 0x40004 is certainly a RAM address. Is it that i can just give jump to 0x40004 before calling relocate_code() and it works? I still don't get why you want to change *anything* inside U-Boot. Why not just use the commands that are available in the command line interpreter? Say you have your application stored at fc2e (arbitrary address) and it is 64k in size. Then why not just do: cp.b fc2e 4 1;go 40004 Setting bootenv to these commands will start your application on U-Boot timeout. Sticking them into preboot even runs them before the command line is started at all. --Thanks for your reply Detley. I think I was just trying to complicate things.I have got a better picture now. Before calling relcoate_code() in board.c, ifI using the command cp.b fc2e 4 1;go 40004 should be fine. Thanks Regards, Prathika R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Wednesday 24 June 2009 20:59:47 Richard Stallman wrote: their response is simply fine, we'll move on to the next= =20 guy who will satisfy our requirements. When people offer to use my programs if I relax the license requirements, my respose to them is, If you don't use my software, that's your loss. feel free to go write your own bootloader then. or improve grub2 such that it can actually compete with u-boot. then you may make these statements all you like. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
