Re: [U-Boot] Any good __LOW COST__ MIPS SBC suggestion please
Hi Balaji, Please don't top quote. Balaji Ravindran wrote: Hi Florian and Jerry, Thanks for the inputs, i was actually going through the choices, and yea as suggested Lemote seems to be a nice choice for me, and was wanting to see distributors in the US / US shipping options., Based on your .in email domain, I did not expect that to be a problem. :-/ also i had a look at the Linksys routers that you guys mentioned, but one question, aren't the commercial products different from those of development versions?, There are no development versions. That is why they are cheap. ;-) I mean, when i opened up my WRT 610N, i could see that, the main section of my router board is sealed in a steel casing(guess heat dissipater), though i can get the specs online, The metal enclosure would be a EMI shield. This is typically needed over the RF sections, sometimes needed over the processor sections. It may or may not cover interesting things (processor, JTAG connector, etc). but does it have JTAG ports for debugging support? usually in production versions, the odm's doesn't provide JTAG right? well, i couldn't see one though. The JTAG port is typically pads with no connector installed. The designer/developers need it for development and the manufacturer typically needs it for loading new boards or debugging bad boards. Developers get boards with connectors installed (special builds or add-on). Manufacturers will use a fixture with pogo pins to stab the pads directly. You get the opportunity for showing creativity, ingenuity, and soldering prowess. Just curious, will we be able to get development boards of Linksys WRT SKUs? No. Linksys is in the business of selling lots of turnkey boxes, not development stations. Their attitude varies between tolerance and unhappiness with respect to hackers repurposing their boxes. If you are looking for development boards, the off-the-shelf repurposing that Florian and I have mentioned do not fit your desires. You will need to restart your search with actual eval/dev boards and probably pay more money. The advantage is that you will probably get better help and more information from the (re)seller. The disadvantage is that you will pay more and probably learn less. Thanks Balaji R Best regards, gvb P.S. Florian: Thanks for the added info, that was very helpful. [snip original] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc82xx: Remove SL8245 board and the now orpahned sk98lin network driver.
This code has compile problems and the company does not even exist any more. So we take the liberty to drop support for it. Signed-off-by: Detlev Zundel d...@denx.de CC: Wolfgang Denk w...@denx.de CC: Ben Warren biggerbadder...@gmail.com --- The patch is too large for the ML, so it can be found here: 0001-mpc82xx-Remove-SL8245-board-and-the-now-orpahned-sk.patch MAINTAINERS |1 - MAKEALL |1 - Makefile|3 - board/sl8245/Makefile | 44 - board/sl8245/config.mk | 31 - board/sl8245/flash.c| 488 -- board/sl8245/sl8245.c | 79 - drivers/net/sk98lin/Makefile| 108 - drivers/net/sk98lin/h/lm80.h| 197 - drivers/net/sk98lin/h/skaddr.h | 425 -- drivers/net/sk98lin/h/skcsum.h | 261 -- drivers/net/sk98lin/h/skdebug.h | 119 - drivers/net/sk98lin/h/skdrv1st.h| 264 -- drivers/net/sk98lin/h/skdrv2nd.h| 561 --- drivers/net/sk98lin/h/skerror.h | 80 - drivers/net/sk98lin/h/skgedrv.h | 72 - drivers/net/sk98lin/h/skgehw.h | 2336 -- drivers/net/sk98lin/h/skgehwt.h | 74 - drivers/net/sk98lin/h/skgei2c.h | 299 -- drivers/net/sk98lin/h/skgeinit.h| 1113 - drivers/net/sk98lin/h/skgepnm2.h| 462 -- drivers/net/sk98lin/h/skgepnmi.h| 1113 - drivers/net/sk98lin/h/skgesirq.h| 194 - drivers/net/sk98lin/h/ski2c.h | 292 -- drivers/net/sk98lin/h/skqueue.h | 147 - drivers/net/sk98lin/h/skrlmt.h | 563 --- drivers/net/sk98lin/h/sktimer.h | 99 - drivers/net/sk98lin/h/sktypes.h | 87 - drivers/net/sk98lin/h/skversion.h | 52 - drivers/net/sk98lin/h/skvpd.h | 335 -- drivers/net/sk98lin/h/xmac_ii.h | 1738 drivers/net/sk98lin/skaddr.c| 1875 drivers/net/sk98lin/skcsum.c| 925 drivers/net/sk98lin/skge.c | 4866 drivers/net/sk98lin/skgehwt.c | 215 - drivers/net/sk98lin/skgeinit.c | 2367 -- drivers/net/sk98lin/skgemib.c | 1056 - drivers/net/sk98lin/skgepnmi.c | 8306 --- drivers/net/sk98lin/skgesirq.c | 2416 -- drivers/net/sk98lin/ski2c.c | 1501 --- drivers/net/sk98lin/sklm80.c| 288 -- drivers/net/sk98lin/skproc.c| 510 --- drivers/net/sk98lin/skqueue.c | 238 - drivers/net/sk98lin/skrlmt.c| 3505 --- drivers/net/sk98lin/sktimer.c | 293 -- drivers/net/sk98lin/skvpd.c | 1325 -- drivers/net/sk98lin/skxmac2.c | 4398 --- drivers/net/sk98lin/u-boot_compat.h | 98 - drivers/net/sk98lin/uboot_drv.c | 138 - drivers/net/sk98lin/uboot_skb.c | 117 - include/configs/SL8245.h| 294 -- 51 files changed, 0 insertions(+), 46369 deletions(-) delete mode 100644 board/sl8245/Makefile delete mode 100644 board/sl8245/config.mk delete mode 100644 board/sl8245/flash.c delete mode 100644 board/sl8245/sl8245.c delete mode 100644 drivers/net/sk98lin/Makefile delete mode 100644 drivers/net/sk98lin/h/lm80.h delete mode 100644 drivers/net/sk98lin/h/skaddr.h delete mode 100644 drivers/net/sk98lin/h/skcsum.h delete mode 100644 drivers/net/sk98lin/h/skdebug.h delete mode 100644 drivers/net/sk98lin/h/skdrv1st.h delete mode 100644 drivers/net/sk98lin/h/skdrv2nd.h delete mode 100644 drivers/net/sk98lin/h/skerror.h delete mode 100644 drivers/net/sk98lin/h/skgedrv.h delete mode 100644 drivers/net/sk98lin/h/skgehw.h delete mode 100644 drivers/net/sk98lin/h/skgehwt.h delete mode 100644 drivers/net/sk98lin/h/skgei2c.h delete mode 100644 drivers/net/sk98lin/h/skgeinit.h delete mode 100644 drivers/net/sk98lin/h/skgepnm2.h delete mode 100644 drivers/net/sk98lin/h/skgepnmi.h delete mode 100644 drivers/net/sk98lin/h/skgesirq.h delete mode 100644 drivers/net/sk98lin/h/ski2c.h delete mode 100644 drivers/net/sk98lin/h/skqueue.h delete mode 100644 drivers/net/sk98lin/h/skrlmt.h delete mode 100644 drivers/net/sk98lin/h/sktimer.h delete mode 100644 drivers/net/sk98lin/h/sktypes.h delete mode 100644 drivers/net/sk98lin/h/skversion.h delete mode 100644 drivers/net/sk98lin/h/skvpd.h delete mode 100644 drivers/net/sk98lin/h/xmac_ii.h delete mode 100644 drivers/net/sk98lin/skaddr.c delete mode 100644 drivers/net/sk98lin/skcsum.c delete mode 100644 drivers/net/sk98lin/skge.c delete mode 100644 drivers/net/sk98lin/skgehwt.c delete mode 100644 drivers/net/sk98lin/skgeinit.c delete mode 100644 drivers/net/sk98lin/skgemib.c delete mode 100644 drivers/net/sk98lin/skgepnmi.c delete mode 100644 drivers/net/sk98lin/skgesirq.c delete mode 100644 drivers/net/sk98lin/ski2c.c delete mode 100644 drivers/net/sk98lin/sklm80.c delete mode 100644 drivers/net/sk98lin/skproc.c delete mode 100644 drivers/net/sk98lin/skqueue.c delete mode 100644 drivers/net/sk98lin/skrlmt.c
[U-Boot] Arm pull request
Wolfgang, Please pull arm. Tom The following changes since commit ef8d008730fb62fc81a792274eea40480593a7d3: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash are available in the git repository at: git://git.denx.de/u-boot-arm master Achim Ehrlich (1): ARM change name of defines for AT91 arm926ejs Anders Darander (1): Add bootcount to AT91 Daniel Gorsulowski (1): AT91: Update otc570 board to new SoC access Heiko Schocher (2): arm: add support for the suen3 board from keymile arm, suen3: fix compile error, if doing not a local build Jens Scharsig (1): updates the at91 main_clock calculation John Rigby (5): mxc_serial replace platform specific clock Add support for Freescale MX25 SOC fec_mxc: cleanup and factor out MX27 dependencies fec_mxc: add MX25 support Add support for KARO TX25 board Ladislav Michl (8): NetStar: eeprom - undefined reference to `memset' NetStar: eeprom - be less verbose NetStar: eeprom - fix linker error NetStar: fix default environment NetStar: make mtdparts default ready for recent kernels netstar.h: do not exceed 80 columns VoiceBlue: limit line lenght to 80 characters VoiceBlue: fix linker errors Matthias Kaehlcke (3): ep93xx: Fix calculation of sys ticks in clk_to_systicks() ep93xx: Refactoring of timer code edb93xx: Fix SDRAM initialization Nick Thompson (1): da830evm: Add support for TI EMAC Prafulla Wadaskar (1): arm: kirkwood: suen3: fixed build warning Sandeep Paulraj (1): DaVinci: Adding entry to MAKEALL for DM365 EVM Siarhei Siamashka (1): OMAP3: workaround for ARM Cortex-A8 erratum 725233 Stefano Babic (10): MX51: Add initial support for the Freescale MX51 MX51: Add register definitions MX51: Add pin and multiplexer definitions. serial_mxc: add support for MX51 processor mmc: check correctness of the voltage mask in ocr MMC: add weak function to detect MMC/SD card ARM: add accessors functions fsl_esdhc: add support for mx51 processor Add initial support for Freescale mx51evk board MX51: removed warnings for the mx51evk Tom Rix (1): ARM Update mach-types Vipin Kumar (1): SPEAr : Supporting new mach ids for spear310 and spear320 MAINTAINERS| 10 +- MAKEALL|3 + Makefile | 11 + board/atmel/at91cap9adk/at91cap9adk.c |2 +- board/atmel/at91sam9261ek/at91sam9261ek.c |2 +- board/atmel/at91sam9263ek/at91sam9263ek.c |2 +- board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c|2 +- board/atmel/at91sam9rlek/at91sam9rlek.c|2 +- board/davinci/da830evm/da830evm.c | 65 ++- board/edb93xx/sdram_cfg.c | 39 +- board/esd/otc570/otc570.c | 182 ++-- board/freescale/mx51evk/Makefile | 48 + board/freescale/mx51evk/config.mk | 25 + board/freescale/mx51evk/imximage.cfg | 119 +++ board/freescale/mx51evk/mx51evk.c | 397 .../eeprom.lds = freescale/mx51evk/mx51evk.h} | 56 +- board/karo/tx25/Makefile | 51 + board/karo/tx25/config.mk |5 + board/karo/tx25/lowlevel_init.S| 131 +++ board/karo/tx25/tx25.c | 176 board/keymile/common/common.c |6 +- board/keymile/km_arm/Makefile | 54 + board/keymile/km_arm/config.mk | 28 + board/keymile/km_arm/km_arm.c | 324 ++ board/keymile/km_arm/kwbimage.cfg | 175 board/netstar/Makefile | 54 +- board/netstar/eeprom.c | 95 +- board/netstar/eeprom_start.S | 13 - board/ronetix/pm9261/pm9261.c |2 +- board/ronetix/pm9263/pm9263.c |2 +- board/spear/spear310/spear310.c|2 +- board/spear/spear320/spear320.c|2 +- board/voiceblue/Makefile | 33 +- board/voiceblue/eeprom.c | 97 +- board/voiceblue/eeprom_start.S | 11 - cpu/arm920t/ep93xx/timer.c | 76 +- cpu/arm926ejs/at91/clock.c |9 +- cpu/arm926ejs/at91/cpu.c | 42 +- cpu/arm926ejs/mx25/Makefile| 46 + cpu/arm926ejs/mx25/generic.c | 263 + cpu/arm926ejs/mx25/reset.c
Re: [U-Boot] [PATCH] mpc5xxx: Remove all references to MGT5100
Detlev Zundel d...@denx.de writes:
We do not support a processor that never reached a real customer.
Signed-off-by: Detlev Zundel d...@denx.de
---
This is really -next stuff. The patch was tested on lite5200b and
on TQM5200.
[...]
diff --git a/MAKEALL b/MAKEALL
index 1e660b6..977a9f3 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -7,7 +7,7 @@ trap print_stats 0
# Determine number of CPU cores if no default was set
: ${BUILD_NCPUS:=`getconf _NPROCESSORS_ONLN`}
-if [ $BUILD_NCPUS -gt 1 ]
+if [ $BUILD_NCPUS -gt 0 ]
then
JOBS=-j $((BUILD_NCPUS + 1))
else
Ooops, this chunk slipped through the cracks and will be fixed in
subsequent versions, sorry.
Cheers
Detlev
--
He who can properly define and divide is to be considered a god.
-- Plato
--
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] POST progress API
Hi Michael, Added POST progress API implemented as weak calls before and after each call to the POST test callback in the post_run_single routine of the post.c file. Signed-off-by: Michael Zaidman michael.zaid...@gmail.com Acked-by: Detlev Zundel d...@denx.de Cheers Detlev -- It's bad civic hygiene to build technologies that could someday be used to facilitate a police state. No matter what the eavesdroppers and censors say, these systems put us all at greater risk. Communications systems that have no inherent eavesdropping capabilities are more secure than systems with those capabilities built in. -- Bruce Schneier -- 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] What is CONFIG_HAS_DATAFLASH?
Hi Timur, Wolfgang Denk wrote: This doesn't tell me anything. Hm... What exactly don't you understand here? Well, I was just wondering what the connection is between DataFlash (which is some flash technology that I don't know much about) and the md command. A google hit (second one for me) tells more: http://www.atmel.com/products/dataflash/default.asp ... sequential access families ideal for program code, data storage, Serial EEPROM replacement, and the next generation PC Bios Market. So it does not fit the put address on a-bus, get contents on d-bus model. Why are plain simple memory accesses not possible on your hardware? Which architecture / CPU is this? Because on this one chip I'm working on, the designers decided to mux the LBC address lines with the video signal from the on-board display driver. No, I'm not kidding about that. That means that when you're using the video display, you can't access flash. Wow, I knew h/w designers are creative, but _that_ creative ;) Cheers Detlev -- 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] (patch) segfault when calling fit_check_format() on corrupt FIT images
Hi Jon,
I found that fit_check_format() was causing a segfault when run on a
corrupt FIT image. I tracked the problem down to line 92 in
libfdt/fdt_ro.c in _fdt_string_eq():
return (strlen(p) == len) (memcmp(p, s, len) == 0);
In the case of a corrupt FIT image one can't depend on 'p' being NULL
terminated. I changed it to use strnlen() to fix the issue.
We are a bit reluctant to accept changes here as this is shared code
with the 'dtc' device tree compiler[1].
Also when glancing over the code, it seems like there may be more places
where a corrupt fdt may backfire so this makes me also sceptic if this
single fix is a useful thing.
Stepping back a little bit, I don't even know why we should trap such a
problem at all - after all while developing we have quite a few
possibilities to shoot ourselves in the foot. In a production system
such a thing should not happen and if it does, it will be caught by a
sensible infrastructure and e.g. a hardware watchdog.
--- a/libfdt/fdt_ro.c Fri Mar 05 06:52:52 2010 -0600
+++ b/libfdt/fdt_ro.c Fri Mar 05 11:10:21 2010 -0600
@@ -89,7 +89,7 @@
{
const char *p = fdt_string(fdt, stroffset);
- return (strlen(p) == len) (memcmp(p, s, len) == 0);
+ return (strnlen(p, len) == len) (memcmp(p, s, len) == 0);
}
int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t
*size)
On the other hand if you do insist on your change, then pleas send git
patches as written in the documentation[2].
Cheers
Detlev
[1] http://jdl.com/software/
[2] http://www.denx.de/wiki/U-Boot/Patches
--
[Linux] USB consoles was a bad hack written on a drunken dare. I'm still
constantly amazed that the thing even works at all, let alone the fact that
people are actually using it :)
-- Greg KH 20090420225358.gc28...@kroah.com
--
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) segfault when calling fit_check_format() on corrupt FIT images
On Mon, Mar 8, 2010 at 11:07 AM, Detlev Zundel d...@denx.de wrote: We are a bit reluctant to accept changes here as this is shared code with the 'dtc' device tree compiler[1]. Understandable. Also when glancing over the code, it seems like there may be more places where a corrupt fdt may backfire so this makes me also sceptic if this single fix is a useful thing. I agree. It looks like there might be more than one case where a non null terminated string could cause problems. Stepping back a little bit, I don't even know why we should trap such a problem at all - after all while developing we have quite a few possibilities to shoot ourselves in the foot. In a production system such a thing should not happen and if it does, it will be caught by a sensible infrastructure and e.g. a hardware watchdog. In our environment we have redundant FIT images in flash. This issue was caught by one of our testers who was purposely powering off the device during a firmware upgrade (in order to test the redundancy). The segfault is observed after rebooting to the remaining good image and invoking a command that calls fit_check_format(). The issue occurs after the flash has been erased, since in this case the erased flash is all 1's no terminating null character is ever found. My goal is to be able to determine (while in Linux) if one of the two firmware images in flash is corrupt or not. Although our platform supports a hardware watchdog, I am unclear how it could solve this particular problem? Granted, this is a fairly obscure case and it is not likely that users will be powering off hardware during firmware upgrades, but I wanted to at least describe the scenario to see what others might think. I would appreciate any suggestions for other methods of determining if a FIT image in flash is valid or not. On the other hand if you do insist on your change, then pleas send git patches as written in the documentation[2]. Sorry about that. I will submit any further patches as per the documentation. Regards, Jon Nalley ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch] ./net/net.c - make Microsoft dns servers happy with random_port() numbers
For some reason, (which I can't find any documentation on), if U-Boot
gives a port number higher than 17500 to a Microsoft DNS server, the
server will reply to port 17500, and U-Boot will ignore things (since
that isn't the port it asked the DNS server to reply to).
This fixes that by ensuring the random port number is less than 17500.
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
---
net/net.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/net.c b/net/net.c
index 595abd9..98d58e5 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1872,11 +1872,13 @@ void copy_filename (char *dst, char *src, int size)
#if defined(CONFIG_CMD_NFS) || defined(CONFIG_CMD_SNTP) ||
defined(CONFIG_CMD_DNS)
/*
- * make port a little random, but use something trivial to compute
+ * make port a little random (1024-17407)
+ * This keeps the math somewhat trivial to compute, and seems to work with
+ * all supported protocols/clients/servers
*/
unsigned int random_port(void)
{
- return 1024 + (get_timer(0) % 0x8000);;
+ return 1024 + (get_timer(0) % 0x4000);
}
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Help with LCD setup
First time user. Sorry if you got multiple emails already. I add the following line at the bottom of my omap3_beagle.h file. #define CONFIG_LCD 1 #define CONFIG_CMD_BMP 1 #define CONFIG_SPLASH_SCREEN1 #define CONFIG_MPC823 1 #define CONFIG_LCD_LOGO 1 The following is the error message. Did I miss anything? gcc version is listed below. git branch: master se...@beaglesetup:~/kernel/uBoot/mainline$ arm-angstrom-linux-gnueabi-gcc --version arm-angstrom-linux-gnueabi-gcc (GCC) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. lcd.c: In function ‘bitmap_plot’: lcd.c:505: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token lcd.c:505: error: ‘immr’ undeclared (first use in this function) lcd.c:505: error: (Each undeclared identifier is reported only once lcd.c:505: error: for each function it appears in.) lcd.c:505: error: ‘immap_t’ undeclared (first use in this function) lcd.c:505: error: expected expression before ‘)’ token lcd.c:506: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token lcd.c:506: error: ‘cp’ undeclared (first use in this function) lcd.c: In function ‘lcd_display_bitmap’: lcd.c:605: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token lcd.c:605: error: ‘immr’ undeclared (first use in this function) lcd.c:605: error: ‘immap_t’ undeclared (first use in this function) lcd.c:605: error: expected expression before ‘)’ token lcd.c:606: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token lcd.c:606: error: ‘cp’ undeclared (first use in this function) make[2]: *** [lcd.o] Error 1 make[2]: Leaving directory `/home/setup/kernel/uBoot/mainline/common' make[1]: *** [common/libcommon.a] Error 2 make[1]: Leaving directory `/home/setup/kernel/uBoot/mainline' make: *** [omap3_beagle] Error 2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (patch) segfault when calling fit_check_format() on corrupt FIT images
Dear Jon Nalley, In message d83696341003081006v1b6c1714ubec35ea8ff718...@mail.gmail.com you wrote: My goal is to be able to determine (while in Linux) if one of the two firmware images in flash is corrupt or not. Although our platform supports a hardware watchdog, I am unclear how it could solve this particular problem? Granted, this is a fairly obscure case and it is not likely that users will be powering off hardware during firmware upgrades, but I wanted to at least describe the scenario to see what others might think. I would appreciate any suggestions for other methods of determining if a FIT image in flash is valid or not. Corruption should be detected by the checksum tests we're doing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It seems intuitively obvious to me, which means that it might be wrong. -- Chris Torek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help with LCD setup
Hi, On Mon, 8 Mar 2010 13:32:32 -0600 Chao You you.c...@gmail.com wrote: First time user. Sorry if you got multiple emails already. I add the following line at the bottom of my omap3_beagle.h file. #define CONFIG_LCD 1 #define CONFIG_CMD_BMP 1 #define CONFIG_SPLASH_SCREEN1 #define CONFIG_MPC823 1 This if wrong. Please don't use MPC823 specific board configuration macro in your config file, it is for different architecture. The following is the error message. Did I miss anything? There is no support for splash screen in mainline U-Boot, it seems. You need to add appropriate display controller initialization code, better would be to add a simple driver so that other omap3 boards could also benefit from it. lcd.c: In function ‘bitmap_plot’: lcd.c:505: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token lcd.c:505: error: ‘immr’ undeclared (first use in this function) lcd.c:505: error: (Each undeclared identifier is reported only once lcd.c:505: error: for each function it appears in.) lcd.c:505: error: ‘immap_t’ undeclared (first use in this function) lcd.c:505: error: expected expression before ‘)’ token Try to understand the information your compiler gives you: Look at the common/lcd.c file, around line 505: 504: #elif defined(CONFIG_MPC823) 505:volatile immap_t *immr = (immap_t *) CONFIG_SYS_IMMR; 506:volatile cpm8xx_t *cp = (immr-im_cpm); 507: #endif ‘immap_t’ type is used in the code, but it is undeclared. You can try to find out where it could be declared, i.e. by searching in the code: a...@wker:~/u-boot$ grep -r } immap_t * include/asm-ppc/immap_86xx.h:} immap_t; include/asm-ppc/immap_83xx.h:} immap_t; include/asm-ppc/immap_83xx.h:} immap_t; include/asm-ppc/immap_83xx.h:} immap_t; include/asm-ppc/immap_83xx.h:} immap_t; include/asm-ppc/immap_83xx.h:} immap_t; include/asm-ppc/immap_83xx.h:} immap_t; include/asm-ppc/immap_512x.h:} immap_t; include/asm-ppc/5xx_immap.h:} immap_t; include/asm-ppc/immap_8220.h:} immap_t; include/asm-ppc/8xx_immap.h:} immap_t; include/asm-ppc/immap_8260.h:} immap_t; Now you can see that this type declaration is in ppc architecture specific headers which can't be used for your platform. That means, you must be doing something wrong. You also can see that the variable declarations are conditional, depending on definition of CONFIG_MPC823 macro. Try to find out what this macro is actually for, than you can see if it makes sense to use it in your case. Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] bootcounter implementation for OMAP3
Hello,
I am trying to implement the bootcount_store and bootcount_load
methods for the OMAP3503 processor based board which I am using.
For this I decided to use the location at the end of scratchpad RAM,
that is I am trying to write at location 0x480029BF. The code looks like
this, but the boot loader hags when it encounters bootcount_load.
#ifdef CONFIG_BOOTCOUNT_LIMIT
void bootcount_store(ulong a)
{
volatile ulong *save_addr =
(volatile ulong *)(0x480029BF);
*save_addr = (BOOTCOUNT_MAGIC 0x) | (a 0x);
}
ulong bootcount_load(void)
{
volatile ulong *save_addr = (volatile ulong *)(0x480029BF);
if ((*save_addr 0x) != (BOOTCOUNT_MAGIC 0x))
return 0;
else
return (*save_addr 0x);
}
#endif /* CONFIG_BOOTCOUNT_LIMIT */
Am I doing some thing wring fundamentally? Can I get some pointers towrads this?
Also this code I have put in cpu/arm_cortexa8/cpu.c. Is there a way I can put
these functions in OMAP3 specific code and still have them called?
regards
-Nitin
New Email names for you!
Get the Email name you#39;ve always wanted on the new @ymail and @rocketmail.
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
