Re: [U-Boot] NAND flash - bad blocks
Hi Scott, I have tried to do some more tests on the board with the NAND chip I have scrub-ed -I have done 'nand erase.chip clean' and tried to probe different nand regions (I have 128MB RAM and 1GB NAND and I am not sure how I could dump the whole NAND at once) It seems the whole NAND is 0xFF After that I have written 10MB at the beginning of the NAND and those data was verified to be written OK Outside of the 10MB region the NAND stays 0xFF in Linux 'nandtest' doesn't report any issue. So I tend to think that nand scrub did a good think for me. Best Regards Dimitar - Original Message - From: Scott Wood scottw...@freescale.com To: Dimitar Penev d...@switchfin.org Cc: u-boot@lists.denx.de Sent: Friday, January 11, 2013 10:21 PM Subject: Re: [U-Boot] NAND flash - bad blocks On 01/11/2013 02:46:06 AM, Dimitar Penev wrote: Hi Scott, On 01/10/2013 01:56:30 AM, Dimitar Penev wrote: Hello, First of all sorry if this question was already answered here. We are sourcing some K9F8G08U0M-PIB0 NAND flash devices. On the first erase in uboot 2011.09 I got bunch of mostly consecutive bad blocks. According to the datasheet we should get not more then 80 bad blocks for our chip but I get something like 240 bad blocks for most of the NAND chips. I seems to be able to fix this using the following procedure: Call your NAND vendor and complain? Well we did but we didn't got something from them which could explain what we observe. After making sure that there's nothing wrong with your NAND driver or controller that causes the OOB to be read incorrectly. We are using nand_plat driver provide by ADI without any customization. Still, do some investigation to see whether it seems to be working. Dump the raw data that you read -- is it mostly 0xff with some bad block markers set, or is it returning garbage? Do any of the blocks that are not marked bad have non-0xff data? If you do a scrub of the entire NAND chip, then write to one block, does the write show up anywhere else on the NAND chip? In uboot ubootnand scrub.chip In uboot ubootnand erase.chip clean at this point I get usually 1,2 bad blocks which looks normal to me. You're not fixing anything -- you're wiping out all bad block information. Those 1,2 bad blocks are not actually bad blocks, but are the bad block table which appears bad to reserve it. These should be at the end of flash. Or, possibly, they're blocks that happen to be damaged in a way that prevents the bad block marker from becoming 0xff. Oh Really? What about 'nandtest -m' in Linux ? I was hoping it does a check of the erase blocks. That's no substitute for having the factory bad block markers. Nandtest doesn't look very rigorous at all -- and only seems to mark bad blocks if the erase or write operations return failure, not if it sees an uncorrectable error on readback. Thanks Scott. Is there any procedure to analyze the nand flash for bad blocks? Yes, and it's done by the flash manufacturer to produce bad block markers. :-P -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND flash - bad blocks
Hi Scott, On 01/10/2013 01:56:30 AM, Dimitar Penev wrote: Hello, First of all sorry if this question was already answered here. We are sourcing some K9F8G08U0M-PIB0 NAND flash devices. On the first erase in uboot 2011.09 I got bunch of mostly consecutive bad blocks. According to the datasheet we should get not more then 80 bad blocks for our chip but I get something like 240 bad blocks for most of the NAND chips. I seems to be able to fix this using the following procedure: Call your NAND vendor and complain? Well we did but we didn't got something from them which could explain what we observe. After making sure that there's nothing wrong with your NAND driver or controller that causes the OOB to be read incorrectly. We are using nand_plat driver provide by ADI without any customization. Did you do anything to the NAND chip prior to this first erase? In particular, did you write to the OOB? For boards coming out of the assembly house: I load uboot in SPI flash, boot from SPI and get the NAND chip recognized properly. On 'nand erase.chip' command I get bunch of bad blocks. So I guess we haven't even touched OOB before 'nand erase' Assuming the components are OK the only possible explanation could be overheating of the chips in the assembly house. Does anybody get something similar? In uboot ubootnand scrub.chip In uboot ubootnand erase.chip clean at this point I get usually 1,2 bad blocks which looks normal to me. You're not fixing anything -- you're wiping out all bad block information. Those 1,2 bad blocks are not actually bad blocks, but are the bad block table which appears bad to reserve it. These should be at the end of flash. Or, possibly, they're blocks that happen to be damaged in a way that prevents the bad block marker from becoming 0xff. Oh Really? What about 'nandtest -m' in Linux ? I was hoping it does a check of the erase blocks. In Linux we have few mtd partitions on this NAND chip. Unmount all of them and for all of them : linuxnandtest -m /dev/mtdx Usually this doesn't add any new badblocks on top of what I get on nand erase in uboot, but I really haven't tested that much device to say. After this procedure the NAND flash seems to work fine. Do you think this is reliable way? No. Thanks Scott. Is there any procedure to analyze the nand flash for bad blocks? -Scott Best Regards Dimitar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NAND flash - bad blocks
Hello, First of all sorry if this question was already answered here. We are sourcing some K9F8G08U0M-PIB0 NAND flash devices. On the first erase in uboot 2011.09 I got bunch of mostly consecutive bad blocks. According to the datasheet we should get not more then 80 bad blocks for our chip but I get something like 240 bad blocks for most of the NAND chips. I seems to be able to fix this using the following procedure: In uboot ubootnand scrub.chip In uboot ubootnand erase.chip clean at this point I get usually 1,2 bad blocks which looks normal to me. In Linux we have few mtd partitions on this NAND chip. Unmount all of them and for all of them : linuxnandtest -m /dev/mtdx Usually this doesn't add any new badblocks on top of what I get on nand erase in uboot, but I really haven't tested that much device to say. After this procedure the NAND flash seems to work fine. Do you think this is reliable way? Is there something better I can do? Has anyone got NAND component batch having more bad blocks then datasheet allows. Should we consider the provider unreliable? Thank you Dimitar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Writting uImage from linux using nandwrite on Blackfin based system
Hello, Happy new year to all of you! We are observing an issue writing some data in the nand flash from uClinux. Things which I think are relevant are: -It is custom Blackfin BF547 based system. It uses MT29F4G08ABADAH4 chip And the interface is thru the built in hardware NAND controller in the CPU. -We are using 3.0.8-ADI-2011R1 uClinux kernel -We are usng uboot 2011.09 (ADI-2011R1) -the file uImage is written by the commands /bin/flash_erase /dev/mtd3 0 0 /bin/nandwrite /dev/mtd3 uImage -It is verified that the data are written properly using: cmp uImage /dev/mtd3 -In uboot however if I load the original data (using tftp at 0x200) and the one read from the nand flash (at 0x300) I observe few bytes mismatch as shown bellow: (The uImage is 0xC0 long) byte at 0x02027bc4 (0xa2) != byte at 0x03027bc4 (0xb2) byte at 0x0234f3f4 (0x05) != byte at 0x0334f3f4 (0x07) byte at 0x029393b4 (0x73) != byte at 0x039393b4 (0x71) byte at 0x02a7d564 (0x63) != byte at 0x03a7d564 (0x43) byte at 0x02b57104 (0x16) != byte at 0x03b57104 (0x06) byte at 0x02b5933f (0xbf) != byte at 0x03b5933f (0xbb) -If another nand flash partition is used (so I write the same data at a different nand flash offset) the same mismatch is observed at the same offsets relative to the beginning of the partition. - If I change the data I try to write in flash the mismatches become different at different locations. Still only a few mismatches -From uboot we can read/write in the nand flash without issues. No bad blocks are reported with those particular nand chip while I erase the nand flash. I've heard about ECC layout difference between uboot and linux kernel. Do you think it may be something like this? Thank you Dimitar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Blackfin BF54x Silicon revision 0.4 and uClinux
Hi Mike, Thank you for this information. Dimitar - Original Message - From: Mike Frysinger vap...@gentoo.org To: u-boot@lists.denx.de; Dimitar Penev d...@switchfin.org Sent: Sunday, August 26, 2012 4:27 AM Subject: Re: [U-Boot] Blackfin BF54x Silicon revision 0.4 and uClinux ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Blackfin BF54x Silicon revision 0.4 and uClinux
Hello Gents, My question is not directly applicable with u-boot but I think here I may find the answer which I still don't get from the Analog Device forum. Does anyone got working hardware based on Blackfin BF54x rev 0.4 (the current silicon revision) and uClinux http://blackfin.uclinux.org/gf/project/uclinux-dist ? I know about BF548 EZKIT Lite but it uses BF548 Rev 0.2. Thank you Dimitar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Blackfin BF547 board testing.
Hi Guys,
We have developed Blackfin based board using BF547-Rev04.
At the moment we face strange probably hardware issue.
Let me share few details
- GCC assumes rev 0.2 of the CPU is this OK with the rev 0.4 which we have
on board?
- The DDR routing due to a PCB mistake is not perfect now so we had to
reduce the SCLK to 75 MHz
- Now mtest in uboot is working OK for a very long time.
- as the uCinux boots we get 2 different kind of OOPS. The OOPS trace are
exactly the same on each try.
Which one of the OOPS we will get depends even from the place in memory
we put uImage before 'bootm' it.
Let me copy one of the OOPS at the end of this message.
The first reason for this behavior seems to be memory issue.
At the moment we have soldered two Micron memory chips MT46V64M8BN-5B. (On
the board we have footprints for 4 chips,
two are not soldered and their traces are hanging as a bridged taps now)
We are using Vtt active termination. The series resistors are 22 Ohm and
the Vtt pull-ups are 47 Ohm.
We have experimented a lot varying the SCLK and keeping EBIU_DDRCTL[0..2]
as per the excel document
available at http://docs.blackfin.uclinux.org/doku.php?id=bfin:sdram.
The most stable behavior we have got around SCLK-75MHz. For higher and lower
frequency we get worse results.
With SCLK=75 MHz mtest is working stable. Can we assume that our memory is
OK for this settings then?
The OOPS we get looks stable as well. All the trace data are exactly
repeatable.
Can you please point us to the way/direction so we narrow down the issue.
=
Freeing unused kernel memory: 120k freed
Undefined instruction
5 - May be used to emulate instructions that are not defined for
5 a particular processor implementation.
Kernel OOPS in progress
Deferred Exception context
CURRENT PROCESS:
COMM=mtdblock0 PID=141 CPU=0
invalid mm
return address: [0x0006a5fc]; contents of:
0x0006a5d0: 3044 a0ea 4ee2 e3ff ffd5 a060
0x0006a5e0: 0c00 1809 304d 6c66 5201 0127 a0a1 0484
0x0006a5f0: e2fe 7568 6c66 0127 3045 a0a1 [0484] e2fe
0x0006a600: 7561 e14a 001f e10a 60a0 9111 e2ff
ADSP-BF547-0.2(Detected 0.4) 375(MHz CCLK) 75(MHz SCLK) (mpu off)
Linux version 3.0.8-ADI-2011R1switchfin (root@Switchvoice) (gcc version
4.3.5 (ADI-2011R1-RC4) ) #2 Wed Aug 22 11:17:03 EEST 2012
SEQUENCER STATUS: Not tainted
SEQSTAT: 0021 IPEND: 8008 IMASK: 003f SYSCFG: 0006
Peripheral interrupts masked off
Kernel interrupts masked off
EXCAUSE : 0x21
physical IVG3 asserted : 0xffa0077c { _trap + 0x0 }
physical IVG15 asserted : 0xffa00fc4 { _evt_system_call + 0x0 }
logical irq 6 mapped : 0x6240 { _bfin_coretmr_interrupt + 0x0 }
logical irq 48 mapped : 0x000d7230 { _bfin_serial_dma_rx_int + 0x0 }
logical irq 49 mapped : 0x000d6fb4 { _bfin_serial_dma_tx_int + 0x0 }
RETE: 0x /* Maybe null pointer? */
RETN: 0x0216ff18 /* kernel dynamic memory (maybe user-space) */
RETX: 0x0480 /* Maybe fixed code section */
RETS: 0x000b419a { _blk_update_request + 0x7a }
PC : 0x0006a5fc { _bio_free + 0x48 }
DCPLB_FAULT_ADDR: 0x0204eca8 /* kernel dynamic memory (maybe user-space)
*/
ICPLB_FAULT_ADDR: 0x0006a5fc { _bio_free + 0x48 }
PROCESSOR STATE:
R0 : 0204a6a0R1 : 0204ec80R2 : R3 :
R4 : R5 : R6 : 1000R7 : 1000
P0 : 001fc064P1 : 0204a6a0P2 : 0204a6e4P3 : 0204a6a0
P4 : 0204eca0P5 : 0204a6a0FP : 0217592cSP : 0216fe3c
LB0: 000c2cf6LT0: 000c2cf6LC0:
LB1: 00066470LT1: 00066464LC1: 0008
B0 : 000cL0 : M0 : 0201b92cI0 : 0003
B1 : 001fL1 : M1 : 0001I1 : 0605ac00
B2 : 0018589cL2 : M2 : 0019I2 : 0204a6a0
B3 : 0001L3 : M3 : I3 :
A0.w: A0.x: A1.w: A1.x:
USP : ASTAT: 02003025
Hardware Trace:
0 Target : 0x4028 { _trap_c + 0x0 }
Source : 0xffa00710 { _exception_to_level5 + 0xa4 } JUMP.L
1 Target : 0xffa0066c { _exception_to_level5 + 0x0 }
Source : 0xffa00520 { _bfin_return_from_exception + 0x18 } RTX
2 Target : 0xffa00508 { _bfin_return_from_exception + 0x0 }
Source : 0xffa005c4 { _ex_trap_c + 0x74 } JUMP.S
3 Target : 0xffa00550 { _ex_trap_c + 0x0 }
Source : 0xffa007d6 { _trap + 0x5a } JUMP (P4)
4 Target : 0xffa0077c { _trap + 0x0 }
FAULT : 0x0006a5fc { _bio_free + 0x48 } 0x0484
Source : 0x0006a5fa { _bio_free + 0x46 } P1 = W[P4 + 2]
5 Target : 0x0006a5f4 { _bio_free + 0x40 }
Source : 0x0006a5e2 { _bio_free + 0x2e } IF CC JUMP pcrel
6 Target : 0x0006a5de { _bio_free + 0x2a }
Source : 0x0006a5ce { _bio_free + 0x1a } IF CC JUMP pcrel
7 Target : 0x0006a5b4 { _bio_free + 0x0 }
Source : 0x0006a60e { _bio_fs_destructor + 0xa } CALL pcrel
8 Target : 0x0006a604 {
[U-Boot] smc911x and CONFIG_NET_MULTI
Hi Gents, We have developed a custom blackfin board having two LAN9218 chips on board. Is the available smc911x driver tested with multiple network chips on board? The base address of the first chip should be set to CONFIG_SMC911X_BASE. On what physical address the second chip should be allocated so uboot finds it? Thank you Dimitar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Blackfin: br4: new board port
Hi Mike,
The patch is working on BR4 Appliance hardware.
Best Regards
Dimitar Penev
- Original Message -
From: Mike Frysinger vap...@gentoo.org
To: u-boot@lists.denx.de
Cc: Dimitar Penev d...@switchfin.org
Sent: Sunday, January 08, 2012 11:25 AM
Subject: [PATCH v2] Blackfin: br4: new board port
From: Dimitar Penev d...@switchfin.org
This adds support for the BR4 Appliance. It is a quad channel ISDN BRI
board based on Blackfin BF537 CPU.
Signed-off-by: Dimitar Penev d...@switchfin.org
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
v2
- rebased and applied feedback from Wolfgang
MAINTAINERS |1 +
board/br4/Makefile| 50
board/br4/br4.c | 30 +
board/br4/config.mk | 30 +
boards.cfg|1 +
include/configs/br4.h | 157
+
6 files changed, 269 insertions(+), 0 deletions(-)
create mode 100644 board/br4/Makefile
create mode 100644 board/br4/br4.c
create mode 100644 board/br4/config.mk
create mode 100644 include/configs/br4.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 3f83189..93249c2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1156,6 +1156,7 @@ Chong Huang chu...@ucrobotics.com
Dimitar Penev d...@switchfin.org
+ BR4 Appliance BF537
PR1 Appliance BF537
#
diff --git a/board/br4/Makefile b/board/br4/Makefile
new file mode 100644
index 000..6ae998f
--- /dev/null
+++ b/board/br4/Makefile
@@ -0,0 +1,50 @@
+#
+# U-boot - Makefile
+#
+# Copyright (c) Switchfin Org. d...@switchfin.org
+#
+# Copyright (c) 2005-2007 Analog Device Inc.
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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).o
+
+COBJS-y := $(BOARD).o
+
+SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS-y))
+
+$(LIB): $(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/br4/br4.c b/board/br4/br4.c
new file mode 100644
index 000..bc034e3
--- /dev/null
+++ b/board/br4/br4.c
@@ -0,0 +1,30 @@
+/*
+ * U-boot - main board file
+ *
+ * Copyright (c) Switchfin Org. d...@switchfin.org
+ *
+ * Copyright (c) 2005-2008 Analog Devices Inc.
+ *
+ * (C) Copyright 2000-2004
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include common.h
+#include net.h
+#include netdev.h
+
+int checkboard(void)
+{
+ printf(Board: Switchvoice BR4 Appliance\n);
+ printf( Support: http://www.switchvoice.com/\n;);
+ return 0;
+}
+
+#ifdef CONFIG_BFIN_MAC
+int board_eth_init(bd_t *bis)
+{
+ return bfin_EMAC_initialize(bis);
+}
+#endif
diff --git a/board/br4/config.mk b/board/br4/config.mk
new file mode 100644
index 000..9d66d26
--- /dev/null
+++ b/board/br4/config.mk
@@ -0,0 +1,30 @@
+#
+# Copyright (c) Switchfin Org. d...@switchfin.org
+#
+# Copyright (c) 2005-2008 Analog Device Inc.
+#
+# (C) Copyright 2001
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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
+#
+
+CFLAGS_lib
Re: [U-Boot] [PATCH v2] Blackfin: pr1: new board port
Hi Mike,
The patch is working on the PR1 Appliance hardware.
Best Regards
Dimitar Penev
- Original Message -
From: Mike Frysinger vap...@gentoo.org
To: u-boot@lists.denx.de
Cc: Dimitar Penev d...@switchfin.org
Sent: Sunday, January 08, 2012 11:24 AM
Subject: [PATCH v2] Blackfin: pr1: new board port
From: Dimitar Penev d...@switchfin.org
This add support for the PR1 Appliance - Asterisk based ISDN PRI PBX.
This board is Blackfin BF537 based. The schematics are not fully opened.
Signed-off-by: Dimitar Penev d...@switchfin.org
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
v2
- rebased and applied feedback from Wolfgang
MAINTAINERS |4 +
board/pr1/Makefile| 50
board/pr1/config.mk | 30 +
board/pr1/pr1.c | 30 +
boards.cfg|1 +
include/configs/pr1.h | 157
+
6 files changed, 272 insertions(+), 0 deletions(-)
create mode 100644 board/pr1/Makefile
create mode 100644 board/pr1/config.mk
create mode 100644 board/pr1/pr1.c
create mode 100644 include/configs/pr1.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 4bf12b5..3f83189 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1154,6 +1154,10 @@ Chong Huang chu...@ucrobotics.com
bf525-ucr2 BF525
+Dimitar Penev d...@switchfin.org
+
+ PR1 Appliance BF537
+
#
# NDS32 Systems: #
# #
diff --git a/board/pr1/Makefile b/board/pr1/Makefile
new file mode 100644
index 000..6ae998f
--- /dev/null
+++ b/board/pr1/Makefile
@@ -0,0 +1,50 @@
+#
+# U-boot - Makefile
+#
+# Copyright (c) Switchfin Org. d...@switchfin.org
+#
+# Copyright (c) 2005-2007 Analog Device Inc.
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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).o
+
+COBJS-y := $(BOARD).o
+
+SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS-y))
+
+$(LIB): $(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/pr1/config.mk b/board/pr1/config.mk
new file mode 100644
index 000..9d66d26
--- /dev/null
+++ b/board/pr1/config.mk
@@ -0,0 +1,30 @@
+#
+# Copyright (c) Switchfin Org. d...@switchfin.org
+#
+# Copyright (c) 2005-2008 Analog Device Inc.
+#
+# (C) Copyright 2001
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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
+#
+
+CFLAGS_lib += -O2
+CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
diff --git a/board/pr1/pr1.c b/board/pr1/pr1.c
new file mode 100644
index 000..bb907f3
--- /dev/null
+++ b/board/pr1/pr1.c
@@ -0,0 +1,30 @@
+/*
+ * U-boot - main board file
+ *
+ * Copyright (c) Switchfin Org. d...@switchfin.org
+ *
+ * Copyright (c) 2005-2008 Analog Devices Inc.
+ *
+ * (C) Copyright 2000-2004
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include common.h
+#include net.h
+#include netdev.h
+
+int checkboard(void)
+{
+ printf(Board: Switchvoice PR1 Appliance\n);
+ printf( Support: http://www.switchvoice.com/\n
Re: [U-Boot] [PATCH] Blackfin: br4: new board port
Dear Wolfgang Denk,
Signed-off-by: Dimitar Penev dpn at switchfin dot org
Cc: Mike Frysinger vapier {AT} gentoo {DOT} org
www.switchfin.org/patches/uBoot-br4-v1.patch
If you want to submit a patch, then please follow the rules explained
for example here: http://www.denx.de/wiki/U-Boot/Patches
Most of all, send the patch to the mailing list. Just posting a URL
will definitely be ignored.
I will try to fix my mail client and use plain text as it is explained for
the future.
Thanks
Dimitar Penev
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
We Klingons believe as you do -- the sick should die. Only the strong
should live.
-- Kras, Friday's Child, stardate 3497.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Blackfin: br4: new board port
Dear Wolfgang Denk, Dear Mike Frysinger, +#define CONFIG_HOSTNAME br4 +#define CONFIG_IPADDR 192.168.1.100 +#define CONFIG_GATEWAYIP 192.168.1.1 +#define CONFIG_SERVERIP 192.168.1.2 +#define CONFIG_TFTP_BLOCKSIZE 4404 NAK. i'm guessing you're only NAK-ing the middle three lines Right. I have to admit that I'm not sure i having the last ine is a clever idea, but in any case it's not my problem. I have not dug in the code to understand the impact in details but what I have observed is that the tftp transfer in our local network is getting speeded up few times with the last line added. It is for the files in the 10 MB size range in case it matters. Probably you can just mention the expected negative side of this line? Thank you Dimitar Penev 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 He'd heard her use that sweet, innocent tone of voice before. It meant that, pretty soon, there was going to be trouble. - Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Blackfin: br4: new board port
Dear Wolfgang Denk Dear Dimitar Penev, In message 003601ccada7$ce75c4b0$2901a8c0@dpn you wrote: I will try to fix my mail client and use plain text as it is explained for the future. You don't even need to fix your mail client. Just use git send-email. Thank you for the tip. I have installed git send-email package and it seems I am able to send patches properly now. Thank you. Dimitar Penev Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A memorandum is written not to inform the reader, but to protect the writer. -- Dean Acheson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Blackfin: br4: new board port
Hi Mike,
i tweaked a few things (like disabling the CONFIG_ETHADDR). same question
for
this board ... where is the MAC normally stored ?
The MAC for both PR1 and BR4 Appliance boards is only kept in the u-boot
environment
(variable 'ethaddr')
updated patch is below
Thank you.
Opps indeed I forgot to remove the NET_MULTI, sorry.
The patch is OK for me. With or without predefined static or random value
for 'ethaddr' from the u-boot code.
I tend towards the random generation (as it is done for bf537-stamp) as this
way some tests can be done before entering the final MAC.
In addition the MAC is not known before the enclosure labeling process.
From the other hand not having predefined MAC will force the testing person
to add it
and there is no chance we miss to update the MAC to the correct value.
Anyway I am OK with your version of the patch
Thank you
Dimitar
From 6ff79ef55cb414b0dfb08b8aa9db2baf8849545b Mon Sep 17 00:00:00 2001
From: Dimitar Penev d...@switchfin.org
Date: Fri, 25 Nov 2011 16:05:54 -0500
Subject: [PATCH] Blackfin: br4: new board port
This adds support for the BR4 Appliance. It is a quad channel ISDN BRI
board based on Blackfin BF537 CPU.
Signed-off-by: Dimitar Penev d...@switchfin.org
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
MAINTAINERS |1 +
board/br4/Makefile| 50 +++
board/br4/br4.c | 30 +
board/br4/config.mk | 30 +
boards.cfg|1 +
include/configs/br4.h | 160
+
6 files changed, 272 insertions(+), 0 deletions(-)
create mode 100644 board/br4/Makefile
create mode 100644 board/br4/br4.c
create mode 100644 board/br4/config.mk
create mode 100644 include/configs/br4.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 0c7e15a..5932b67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1136,6 +1136,7 @@ Chong Huang chu...@ucrobotics.com
Dimitar Penev d...@switchfin.org
+ BR4 Appliance BF537
PR1 Appliance BF537
#
diff --git a/board/br4/Makefile b/board/br4/Makefile
new file mode 100644
index 000..6ae998f
--- /dev/null
+++ b/board/br4/Makefile
@@ -0,0 +1,50 @@
+#
+# U-boot - Makefile
+#
+# Copyright (c) Switchfin Org. d...@switchfin.org
+#
+# Copyright (c) 2005-2007 Analog Device Inc.
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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).o
+
+COBJS-y := $(BOARD).o
+
+SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS-y))
+
+$(LIB): $(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/br4/br4.c b/board/br4/br4.c
new file mode 100644
index 000..bc034e3
--- /dev/null
+++ b/board/br4/br4.c
@@ -0,0 +1,30 @@
+/*
+ * U-boot - main board file
+ *
+ * Copyright (c) Switchfin Org. d...@switchfin.org
+ *
+ * Copyright (c) 2005-2008 Analog Devices Inc.
+ *
+ * (C) Copyright 2000-2004
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include common.h
+#include net.h
+#include netdev.h
+
+int checkboard(void)
+{
+ printf(Board: Switchvoice BR4 Appliance\n);
+ printf( Support: http://www.switchvoice.com/\n;);
+ return 0;
+}
+
+#ifdef CONFIG_BFIN_MAC
+int board_eth_init(bd_t *bis)
+{
+ return bfin_EMAC_initialize(bis);
+}
+#endif
diff --git a/board/br4/config.mk b/board/br4/config.mk
new file mode 100644
index 000..9d66d26
--- /dev/null
+++ b/board/br4/config.mk
@@ -0,0 +1,30 @@
+#
+# Copyright (c) Switchfin Org. d...@switchfin.org
+#
+# Copyright (c) 2005-2008 Analog Device Inc.
+#
+# (C) Copyright 2001
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can
[U-Boot] [PATCH] Blackfin: br4: new board port
Hi Guys,
The following patch adds BR4 Appliance support in u-boot.
It is quad channels ISDN BRI board based on Blackfin BF537 CPU
The patch is based on u-boot-2011R1-RC3 from the ADI u-boot git repository
It is pretty similar as the PR1 Appliance patch I have suggested recently.
My email client is folding the patch lines so I dare to post the link to the
patch instead.
Signed-off-by: Dimitar Penev dpn at switchfin dot org
Cc: Mike Frysinger vapier {AT} gentoo {DOT} org
www.switchfin.org/patches/uBoot-br4-v1.patch
Best Regards
Dimitar Penev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add PR1 Appliance - ISDN PRI board
Hi Mike, On Sunday 20 November 2011 15:24:12 Dimitar Penev wrote: I have noticed however that you have removed the random MAC generation which I would consider as a good feature. What is your reasoning behind this? MAC randomization should not be the default mode for boards. where does this board store its MAC address in general ? on the bf537-stamp, we use the last sector of the parallel flash to store the MAC so that it is saved across u-boot/linux updates and recovery. -mike Currently we keep the MAC as u-boot variable 'ethaddr' and pass it to Linux using the boot comand line. Best Regards Dimitar - Original Message - From: Mike Frysinger vap...@gentoo.org To: Dimitar Penev d...@switchfin.org Cc: u-boot@lists.denx.de Sent: Friday, November 25, 2011 10:55 PM Subject: Re: [U-Boot] [PATCH] Add PR1 Appliance - ISDN PRI board ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add PR1 Appliance - ISDN PRI board
Hi Mike, Currently we keep the MAC as u-boot variable 'ethaddr' and pass it to Linux using the boot comand line. right, generally all boards use the 'ethaddr' env var. the question is how does that get initialized ? many boards have dedicated storage so that even if the env gets erased, the value can be recovered from elsewhere. i guess this board doesn't have that redundancy ? Indeed, PR1 BR4 Appliance don't keep MAC in a dedicated storage. It is probably not a bad idea but at the moment we just use the u-boot environment to store our parameters. The 'ethaddr' variable is assigned manually by the person who test the boards Best Regards Dimitar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add PR1 Appliance - ISDN PRI board
Hi Mike, Your patch is nice and working and OK for me. :) I have noticed however that you have removed the random MAC generation which I would consider as a good feature. What is your reasoning behind this? Best Regards Dimitar - Original Message - From: Mike Frysinger vap...@gentoo.org To: Dimitar Penev d...@switchfin.org Cc: u-boot@lists.denx.de Sent: Saturday, November 19, 2011 10:17 PM Subject: Re: [U-Boot] [PATCH] Add PR1 Appliance - ISDN PRI board ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add PR1 Appliance - ISDN PRI board
Hi Mike,
Thank you for the review.
I am attaching the updated patch bellow.
Few comments in a reply to your remarks/questions.
---
+void board_reset(void)
+{
+ /* workaround for weak pull ups on ssel */
+ if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_SPI_MASTER)
+ bfin_reset_boot_spi_cs(GPIO_PF10);
+}
do you actually have this problem in the hardware ? or is this just left
over
from copying the old bf537 file ?
PR1 Appliance seems to boot from SPI FLASH properly without the
board_reset().
From the other side we use 10KOhm on the SSEL pin the same as in BF537-STAMP
I think
so I am not sure why we will have no issue if it is observed in BF537-STAMP.
Removing board_reset() for now
---
+#define CONFIG_SYS_NO_FLASH/* we have only NAND */
not true ... you have SPI too ;)
I am not sure if I understand properly.
As far as I understand the above macro enables/disables the parallel NOR
flashes.
If removed it I get building errors like
'CONFIG_SYS_MAX_FLASH_SECT' undeclared
'CONFIG_SYS_FLASH_BASE' undeclared
All those are parallel flash related I think.
Or do you refer to my comment only? Fixed.
---
+#define CONFIG_NET_MULTI 1
no longer needed - delete
The included patch is with the above line removed as per your advice.
If I test with the 2011R1-RC3 from the ADI repository I still need it
however.
Note that I have tested the patch (with CONFIG_NET_MULTI ) against the ADI
repository
(not the mainstream) and this is what I can confirm as working on PR1
Appliance.
---
Signed-off-by: Dimitar Penev dpn at switchfin dot org
Cc: Mike Frysinger vapier {AT} gentoo {DOT} org
www.switchfin.org/patches/uBoot-pr1-v2.patch
Best Regards
Dimitar Penev
- Original Message -
From: Mike Frysinger vap...@gentoo.org
To: Dimitar Penev d...@switchfin.org
Cc: u-boot@lists.denx.de
Sent: Saturday, November 19, 2011 7:42 AM
Subject: Re: [U-Boot] [PATCH] Add PR1 Appliance - ISDN PRI board
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add PR1 Appliance - ISDN PRI board
Hello,
I am supporting Switchfin GPL software (www.switchfin.org) which contains
supports of PR1 Appliance - Asterisk based ISDN PRI PBX.
This board is Blackfin BF537 based. The schematics is not fully opened.
The following patch adds PR1 Appliance support in u-boot.
It is based on u-boot-2011.09 from the ADI u-boot git repository
My email client is folding the patch line so I dare to post the link to the
patch instead.
Signed-off-by: Dimitar Penev dpn at switchfin dot org
Cc: Mike Frysinger vapier {AT} gentoo {DOT} org
www.switchfin.org/patches/uBoot-pr1.patch
Best Regards
Dimitar Penev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MT29F8G08MAAWC support in u-boot
Hi Guys, Our Blackfin based system was successfully using MT29F2G08AABWP NAND flash and u-boot. Recently due to the limited availability we decided to migrate to the new nand chips from Micron MT29F8G08MAAWC It uses new technology Multi-Level Cell However we are still not able to make it working. The capacity, bus width, etc are stored in the flash itself. The u-boot's nand driver however reads the chip ID and recognize this chip as 16 bit wide though from the partnumber it is clear that it is 8 bit device. Is there someone which know what we need to look at so we make those new chips from Micron working with u-boot nand driver. Thank you for your time! Dimitar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
