u-boot on iMX.RT117x NOR
Hi, I just found out that u-boot has some support for RT117x, this is great! I could not find a better forum to ask, I will appreciate a redirect. I need u-boot to boot from the SPI NOR flash, I have the EVKB evaluation board. The SPL that is generated is not ELF and no instructions of how to use it are available. I am using NXP-MCUBootUtility to flash in SWD mode, not sure what I should configure and how. I tried to place this on top of the flash as raw binary and it does not work, I am waiting for a life sign at UART1 which is redirected to the debug USB port, as far as I saw the SPL should output a string to the console once started. Any hint of how to progress? Any documentation? It would be exciting to have u-boot as a bootloader. Thanks, Alon
Re: [U-Boot] [mips][cfi] Unable to write into flash under qemu
On 5 July 2016 at 19:10, Daniel Schwierzeck
<daniel.schwierz...@gmail.com> wrote:
>
> Hi Alon,
>
> +cc Paul, Stefan
>
> Am 05.07.2016 um 14:04 schrieb Alon Bar-Lev:
> > Hi,
> >
> > Found the debug setting.
> >
> > When I try to erase flash under qemu I get the following error, the
> > erase actually succeeds in the backed file, I see sector as 0xff.
> >
> > Can anyone check if problem is within u-boot or qemu?
> >
> > Thanks!
>
> I've found the problem. Paul sent a fix [1] for pflash in June 2013
> to make 32 Bit access working with YAMON bootloader.
>
> The fix mirrors the flash status value in the upper 16 Bits of the return
> value. Thus U-Boot gets a value of 0x800080 in flash_full_status_check()
> after a block erase command. U-Boot compares the status value in
> flash_isequal() with the expected value of 0x80 but that fails.
>
> Because of this I think pflash support for Malta is broken since Qemu 1.6.0.
>
> A possible fix could be this:
Hi,
Thanks again.
How do we merge this fix?
Regards,
Alon
---
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -608,7 +608,7 @@ static int flash_full_status_check (flash_info_t * info,
> flash_sect_t sector,
> case CFI_CMDSET_INTEL_EXTENDED:
> case CFI_CMDSET_INTEL_STANDARD:
> if ((retcode == ERR_OK)
> - && !flash_isequal (info, sector, 0, FLASH_STATUS_DONE)) {
> + && !flash_isset (info, sector, 0, FLASH_STATUS_DONE)) {
> retcode = ERR_INVAL;
> printf ("Flash %s error at address %lx\n", prompt,
> info->start[sector]);
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [mips][cfi] Unable to write into flash under qemu
On 5 July 2016 at 20:34, Daniel Schwierzeck <daniel.schwierz...@gmail.com> wrote: > > > Am 05.07.2016 um 19:17 schrieb Alon Bar-Lev: >> On 5 July 2016 at 20:05, Daniel Schwierzeck >> <daniel.schwierz...@gmail.com> wrote: >>> >> >> >> Can you please try to copy from sector in flash to another as I've shown? >> It seems to happen especially in this case. >> Maybe it is just impossible... >> >> >> > > I think it's a bug in flash_write_cfibuffer(). It looks like the flash status > value is written to the destination address. It works if you disable > CONFIG_SYS_FLASH_USE_BUFFER_WRITE in include/configs/malta.h. > Thank you so much for your help. I can confirm this is working, however, it takes about forever to complete. For now I will copy to ram and back to flash. Regards, Alon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [mips][cfi] Unable to write into flash under qemu
On 5 July 2016 at 20:05, Daniel Schwierzeck <daniel.schwierz...@gmail.com> wrote: > > > Am 05.07.2016 um 18:50 schrieb Alon Bar-Lev: >> Thank you so much! >> Erase does not complain any more. > > please do not top-quote on a mailing list. > Sorry. >> >> However, write is not working. >> >> Result is always something like: >> be04: 00800080 00800080 00800080 00800080 > > hm, I can't reproduce that: > > $ qemu-system-mips -M malta -cpu 24Kc -m 256 -nographic -drive > if=pflash,file=/work/u-boot-mips/pflash.bin,format=raw -netdev > user,id=ubtest,tftp=/work/u-boot-mips -device pcnet,netdev=ubtest > > malta # md BE04 4 > be04: > malta # erase BE04 +1 > > . done > Erased 1 sectors > malta # md BE04 4 > be04: Can you please try to copy from sector in flash to another as I've shown? It seems to happen especially in this case. Maybe it is just impossible... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [mips][cfi] Unable to write into flash under qemu
be60:
be70:
be80:
be90:
bea0:
beb0:
bec0:
bed0:
bee0:
bef0:
malta # md BE04
be04: 00800080 00800080 00800080 00800080
be040010:
be040020:
be040030:
be040040:
be040050:
be040060:
be040070:
be040080:
be040090:
be0400a0:
be0400b0:
be0400c0:
be0400d0:
be0400e0:
be0400f0:
malta #
On 5 July 2016 at 19:10, Daniel Schwierzeck
<daniel.schwierz...@gmail.com> wrote:
>
> Hi Alon,
>
> +cc Paul, Stefan
>
> Am 05.07.2016 um 14:04 schrieb Alon Bar-Lev:
> > Hi,
> >
> > Found the debug setting.
> >
> > When I try to erase flash under qemu I get the following error, the
> > erase actually succeeds in the backed file, I see sector as 0xff.
> >
> > Can anyone check if problem is within u-boot or qemu?
> >
> > Thanks!
>
> I've found the problem. Paul sent a fix [1] for pflash in June 2013
> to make 32 Bit access working with YAMON bootloader.
>
> The fix mirrors the flash status value in the upper 16 Bits of the return
> value. Thus U-Boot gets a value of 0x800080 in flash_full_status_check()
> after a block erase command. U-Boot compares the status value in
> flash_isequal() with the expected value of 0x80 but that fails.
>
> Because of this I think pflash support for Malta is broken since Qemu 1.6.0.
>
> A possible fix could be this:
>
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -608,7 +608,7 @@ static int flash_full_status_check (flash_info_t * info,
> flash_sect_t sector,
> case CFI_CMDSET_INTEL_EXTENDED:
> case CFI_CMDSET_INTEL_STANDARD:
> if ((retcode == ERR_OK)
> - && !flash_isequal (info, sector, 0, FLASH_STATUS_DONE)) {
> + && !flash_isset (info, sector, 0, FLASH_STATUS_DONE)) {
> retcode = ERR_INVAL;
> printf ("Flash %s error at address %lx\n", prompt,
> info->start[sector]);
>
>
>
> BTW: you can enable Qemu pflash debug output in hw/block/pflash_cfi01.c
>
> >
> > ---
> >
> > malta # erase BE23 BE23
> >
> > fwc addr be23 cmd 50 0050 32bit x 32 bit
> > fwc addr be23 cmd 20 0020 32bit x 32 bit
> > fwc addr be23 cmd d0 00d0 32bit x 32 bit
> > flash_is_busy: 0
> > is= cmd 80(?) addr be23 is= 00800080 0080
> > Flash erase error at address be23
> > fwc addr be23 cmd ff 00ff 32bit x 32 bit
> > done
> >
> > ---
> >
> > user1@localhost ~/linux-course/embedded/qemu $ qemu-system-mips -M
> > malta -nographic -net nic,netdev=eth0 -netdev
> > tap,id=eth0,ifname=vm0,script=/bin/true -drive
> > if=pflash,file=/tmp/flash,format=raw -m 256
> >
> >
> >
> >
> > On 5 July 2016 at 03:08, Alon Bar-Lev <alon.bar...@gmail.com> wrote:
> >>
> >> Hello,
> >>
> >> I am using malta board within qemu. I tried recent releases and master of
> >> both.
> >> Two years ago in qemu-1.5 and qemu-1.6 I could use erase and cp.b in order
> >> to erase and write to the flash.
> >> Now when I try to erase flash I get an error suggesting the erase failed,
> >> however, I do see 0xff all over in the device backed file (-pflash).
> &
Re: [U-Boot] [mips][cfi] Unable to write into flash under qemu
: BE00 RO BE01 RO BE02 RO BE03 RO BE04 BE05BE06BE07BE08BE09 BE0ABE0BBE0CBE0DBE0E BE0FBE10BE11BE12BE13 BE14BE15BE16BE17BE18 BE19BE1ABE1BBE1CBE1D BE1EBE1FBE20BE21BE22 BE23BE24BE25BE26BE27 BE28BE29BE2ABE2BBE2C BE2DBE2EBE2FBE30BE31 BE32BE33BE34BE35BE36 BE37BE38BE39BE3ABE3B BE3CBE3DBE3E RO BE3F RO malta # erase BE23 BE23 fwc addr be23 cmd 50 0050 32bit x 32 bit fwc addr be23 cmd 20 0020 32bit x 32 bit fwc addr be23 cmd d0 00d0 32bit x 32 bit flash_is_busy: 0 is= cmd 80(?) addr be23 is= 00800080 0080 Flash erase error at address be23 fwc addr be23 cmd ff 00ff 32bit x 32 bit done malta # On 5 July 2016 at 03:08, Alon Bar-Lev <alon.bar...@gmail.com> wrote: > > Hello, > > I am using malta board within qemu. I tried recent releases and master of > both. > Two years ago in qemu-1.5 and qemu-1.6 I could use erase and cp.b in order to > erase and write to the flash. > Now when I try to erase flash I get an error suggesting the erase failed, > however, I do see 0xff all over in the device backed file (-pflash). > When I try to write I also receive a failure message. > > I am unsure how to debug this, I went back in time and tried the qemu-1.6 and > got same error. I suspect it is has something to do with u-boot CFI driver. > > Can anyone help determine if issue is at qemu side or at u-boot side? How can > I debug this? > > Thanks, > Alon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [mips][cfi] Unable to write into flash under qemu
Hello, I am using malta board within qemu. I tried recent releases and master of both. Two years ago in qemu-1.5 and qemu-1.6 I could use erase and cp.b in order to erase and write to the flash. Now when I try to erase flash I get an error suggesting the erase failed, however, I do see 0xff all over in the device backed file (-pflash). When I try to write I also receive a failure message. I am unsure how to debug this, I went back in time and tried the qemu-1.6 and got same error. I suspect it is has something to do with u-boot CFI driver. Can anyone help determine if issue is at qemu side or at u-boot side? How can I debug this? Thanks, Alon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [build] conflict of include/image.h with /usr/include/image.h
Hi,
I guess this applies to everything else in include directory. Usually I
know how to fix that, but the -idirafter/tmp/u-boot/arch/powerpc/include
seems to be important to build system, and is also causing the issue, so I
am unsure about the implications.
---
gcc -Wp,-MD,tools/.aisimage.o.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -include /tmp/u-boot/include/libfdt_env.h
-idirafterinclude -idirafter/tmp/u-boot/arch/powerpc/include
-I/tmp/u-boot/lib/libfdt -I/tmp/u-boot/tools
-DCONFIG_SYS_TEXT_BASE=0xf01000 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES
-D_GNU_SOURCE -c -o tools/aisimage.o tools/aisimage.c
In file included from /usr/include/image.h:22:0,
from tools/aisimage.c:10:
/usr/include/rgbpixel.h:61:3: error: expected specifier-qualifier-list
before ‘RGBpixel’
In file included from tools/aisimage.c:10:0:
/usr/include/image.h:40:1: error: unknown type name ‘class’
/usr/include/image.h:41:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘{’ token
tools/aisimage.c:22:1: error: unknown type name ‘table_entry_t’
---
Workaround is to copy include/image.h into tools/, but I believe this is
not the right way to go.
What will be the proper solution? moving shared includes into own directory?
Regards,
Alon Bar-Lev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ppc] qemu-ppce500 howto
On Sun, May 25, 2014 at 1:08 PM, Alexander Graf ag...@suse.de wrote: On 24.05.14 09:23, Alon Bar-Lev wrote: On Thu, May 22, 2014 at 12:04 PM, Alexander Graf ag...@suse.de wrote: On 22.05.14 09:52, Alon Bar-Lev wrote: Hi, Trying to run the qemu-ppce500 within qemu. I am using -bios u-boot.bin and no luck, I get live signal. I am using latest u-boot master and qemu master. Command: $ ./qemu-system-ppc -M ppce500 -nographic -bios u-boot.bin Tried to load u-boot as well, same. Yes, that command should work with the right patches :). Unfortunately they are not in master yet, but instead waiting in my queue: https://github.com/agraf/qemu Please give things a try with the ppc-next branch in there. That should get things working for you. WORKING! thanks! Is there any support for flush and/or mtd for this target (-drive if=pflash, -mtdblock)? I haven't implemented pflash yet, sorry. Do you need the flash device for configuration storage or as backing storage for your kernel? Well, I wish both... :) boot qemu as if it were a target 1. put u-boot on pflash, and boot from it. 2. have backing storage for kernel (can be mtd). 3. have data partition (can be mtd). we can skip (1) as -bios is good enough... but for (2), (3) I do not see solution but have either mtd or other block device support... is that possible? Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ppc] qemu-ppce500 howto
On Sun, May 25, 2014 at 2:16 PM, Alexander Graf ag...@suse.de wrote: On 25.05.2014, at 13:10, Alon Bar-Lev alon.bar...@gmail.com wrote: On Sun, May 25, 2014 at 1:08 PM, Alexander Graf ag...@suse.de wrote: On 24.05.14 09:23, Alon Bar-Lev wrote: On Thu, May 22, 2014 at 12:04 PM, Alexander Graf ag...@suse.de wrote: On 22.05.14 09:52, Alon Bar-Lev wrote: Hi, Trying to run the qemu-ppce500 within qemu. I am using -bios u-boot.bin and no luck, I get live signal. I am using latest u-boot master and qemu master. Command: $ ./qemu-system-ppc -M ppce500 -nographic -bios u-boot.bin Tried to load u-boot as well, same. Yes, that command should work with the right patches :). Unfortunately they are not in master yet, but instead waiting in my queue: https://github.com/agraf/qemu Please give things a try with the ppc-next branch in there. That should get things working for you. WORKING! thanks! Is there any support for flush and/or mtd for this target (-drive if=pflash, -mtdblock)? I haven't implemented pflash yet, sorry. Do you need the flash device for configuration storage or as backing storage for your kernel? Well, I wish both... :) boot qemu as if it were a target 1. put u-boot on pflash, and boot from it. 2. have backing storage for kernel (can be mtd). 3. have data partition (can be mtd). we can skip (1) as -bios is good enough... but for (2), (3) I do not For (2) you can use the -kernel option. It should make the payload's physical address available through an environment variable. If it's a uImage, it will get loaded automatically. For (3) you can use all the emulated block storage options QEMU provides, such as virtio-pci or ahci. ahci works, thanks I did not know this notation is possible: qemu \ -device ahci,id=ahci0 \ -drive if=none,file=/tmp/img1,format=raw,id=drive-sata0-0-0 \ -device ide-drive,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0 Now I see mass storage device on pci bus. Thanks for the reference! Now, I am almost sure we are missing commands within the u-boot configuration to allow accessing the ide/scsi, fsinfo and friends. see solution but have either mtd or other block device support... is that possible? It's definitely possible, yes :). I simply didn't implement any mtd device emulation so far in the QEMU machine model. But patches are definitely welcome! I would have glad to... However, unfortunately, I am not at that level... :( Thanks! Alon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ppc] qemu-ppce500 howto
On Thu, May 22, 2014 at 12:04 PM, Alexander Graf ag...@suse.de wrote: On 22.05.14 09:52, Alon Bar-Lev wrote: Hi, Trying to run the qemu-ppce500 within qemu. I am using -bios u-boot.bin and no luck, I get live signal. I am using latest u-boot master and qemu master. Command: $ ./qemu-system-ppc -M ppce500 -nographic -bios u-boot.bin Tried to load u-boot as well, same. Yes, that command should work with the right patches :). Unfortunately they are not in master yet, but instead waiting in my queue: https://github.com/agraf/qemu Please give things a try with the ppc-next branch in there. That should get things working for you. WORKING! thanks! Is there any support for flush and/or mtd for this target (-drive if=pflash, -mtdblock)? If you also want to run this using KVM, please keep in mind that you need a few extra patches that are in my kvm-ppc-queue branch as well. Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ppc] qemu-ppce500 howto
Hi, Trying to run the qemu-ppce500 within qemu. I am using -bios u-boot.bin and no luck, I get live signal. I am using latest u-boot master and qemu master. Command: $ ./qemu-system-ppc -M ppce500 -nographic -bios u-boot.bin Tried to load u-boot as well, same. Are there any patches pending or any tweak that should be done? Is there any way to provide more information? I tried: $ ./qemu-system-ppc -M ppce500 -nographic -M ppce500 -m 256 -s -S $ gdb (gdb) target remote :1234 Remote debugging using :1234 warning: Can not parse XML target description; XML support was disabled at compile time 0x in ?? () (gdb) load u-boot Loading section .bootpg, size 0x2f4 lma 0xf0 Load failed How can I inject the firmware using gdb? Thanks! Alon Bar-Lev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [mips] malta configuration works in qemu-1.5 does not in qemu-1.6
Hello, master is: 15c5cdf from Fri Nov 8 15:25:29 2013 -0500 u-boot-2013.10 Working in qemu-1.5.3. Does not work in qemu-1.6.1. The command prompt is not displayed, 100% cpu consumption. --- $ qemu-system-mips -M malta -nographic -drive if=pflash,file=/tmp/flash -m 256 U-Boot 2013.10-00249-g15c5cdf (Nov 10 2013 - 18:00:48) Board: MIPS Malta CoreLV (Qemu) DRAM: 256 MiB --- Any idea what the difference? any fix pending somewhere? Regards, Alon Bar-Lev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [mips] malta configuration works in qemu-1.5 does not in qemu-1.6
On Mon, Nov 11, 2013 at 12:25 PM, Gabor Juhos juh...@openwrt.org wrote: 2013.11.11. 10:52 keltezéssel, Daniel Schwierzeck írta: 2013/11/10 Alon Bar-Lev alon.bar...@gmail.com: Hello, master is: 15c5cdf from Fri Nov 8 15:25:29 2013 -0500 u-boot-2013.10 Working in qemu-1.5.3. Does not work in qemu-1.6.1. The command prompt is not displayed, 100% cpu consumption. --- $ qemu-system-mips -M malta -nographic -drive if=pflash,file=/tmp/flash -m 256 U-Boot 2013.10-00249-g15c5cdf (Nov 10 2013 - 18:00:48) Board: MIPS Malta CoreLV (Qemu) DRAM: 256 MiB --- Any idea what the difference? any fix pending somewhere? it is obviously am upstream change in qemu, which requires a fix in u-boot. Paul or Gabor, do you have an idea? It is broken since the following change in qemu: commit a427338b222b43197c2776cbc996936df0302f51 Author: Paul Burton paul.bur...@imgtec.com Date: Fri Jun 14 08:30:44 2013 +0100 mips_malta: correct reading MIPS revision at 0x1fc00010 Rather than modifying the BIOS code at its original location, copy it for the 0x1fc0 region modify the copy. This means the original ROM code is correctly readable at 0x1e10 whilst the MIPS revision is readable at 0x1fc00010. Additionally the code previously operated on target memory which would later be overwritten by the BIOS image upon CPU reset if the -bios argument was used to specify the BIOS image. This led to the written MIPS revision being lost. Copying using rom_copy when -bios is used fixes this issue. Signed-off-by: Paul Burton paul.bur...@imgtec.com Signed-off-by: Leon Alrae leon.al...@imgtec.com Signed-off-by: Aurelien Jarno aurel...@aurel32.net Due to that change, we are getting a CPU exception while probing the flash at the 0x1fc0 address. Changing the MALTA_FLASH_BASE constant to 0x1e00 in 'arch/mips/include/asm/malta.h' fixes the problem. I will send a patch for that. -Gabor Thanks for quick response! I confirm this works in qemu-1.5 and qemu-1.6. Regards, Alon Bar-Lev. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add support to Colibri PXA-270 board
This configuration is based on the trizepsiv board, and the
work Daniel Mack did in the past [1].
The following files were taken as-is from trizepsiv board:
- lowlevel_init.S
- pxavoltage.S
- u-boot.lds
The main module is the same except it does not use multi
serial and does not have usb support.
The configuration is based on Daniel Mack work, with zeros
when trizepsiv required configuration while Daniel did not
provide any.
After modification, u-boot is running, can access the
on-board flash, can access network using Ethernet and
can boot Linux kernel.
Although there are few colibri boards, the name colibri for
the board is the same as the name the linux kernel has for
the Colibri PXA-270 board.
Signed-off-by: Alon Bar-Lev alon.bar...@gmail.com
[1]
http://www.mail-archive.com/u-boot-users%40lists.sourceforge.net/msg01498.html
---
diff --git a/Makefile b/Makefile
index 49b83c0..4e5e290 100644
--- a/Makefile
+++ b/Makefile
@@ -3039,6 +3039,9 @@ pxa255_idp_config:unconfig
trizepsiv_config : unconfig
@$(MKCONFIG) $(@:_config=) arm pxa trizepsiv
+colibri_config : unconfig
+ @$(MKCONFIG) $(@:_config=) arm pxa colibri
+
wepep250_config: unconfig
@$(MKCONFIG) $(@:_config=) arm pxa wepep250
diff --git a/board/colibri/Makefile b/board/colibri/Makefile
new file mode 100644
index 000..efd67e1
--- /dev/null
+++ b/board/colibri/Makefile
@@ -0,0 +1,51 @@
+#
+# (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).a
+
+COBJS := $(BOARD).o
+SOBJS := lowlevel_init.o pxavoltage.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/colibri/colibri.c b/board/colibri/colibri.c
new file mode 100644
index 000..fd91836
--- /dev/null
+++ b/board/colibri/colibri.c
@@ -0,0 +1,74 @@
+/*
+ * (C) Copyright 2007
+ * Stefano Babic, DENX Gmbh, sba...@denx.de
+ *
+ * (C) Copyright 2004
+ * Robert Whaley, Applied Data Systems, Inc. rwha...@applieddata.net
+ *
+ * (C) Copyright 2002
+ * Kyle Harris, Nexus Technologies, Inc. khar...@nexus-tech.net
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH www.elinos.com
+ * Marius Groeger mgroe...@sysgo.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 common.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* - */
+
+int board_init (void)
+{
+ /* memory and cpu-speed are setup before relocation */
+ /* so we do _nothing_ here */
+
+ /* arch number of Board */
+ gd-bd-bi_arch_number = MACH_TYPE_COLIBRI;
+
+ /* adress of boot parameters */
+ gd-bd-bi_boot_params = 0xa100;
+
+ return 0;
+}
+
+int board_late_init(void)
+{
+ setenv(stdout, serial);
+ setenv(stdin, serial);
+ setenv(stderr, serial);
+ return 0
Re: [U-Boot] [PATCH] Add support to Colibri PXA-270 board
Hello, It was not my intention to add publicity my name, but provide a solution for users, as it took a lot of work to make it work without many changes from other implementation. Any way to do it using a reuse would be super, although this is not the only duplication in u-boot board tree... Alon. On Tue, Apr 7, 2009 at 2:55 PM, Detlev Zundel d...@denx.de wrote: Hi Alon, a new board port without a single (C)opyright by your name - must have been a hard day copying ;) This configuration is based on the trizepsiv board, and the work Daniel Mack did in the past [1]. The following files were taken as-is from trizepsiv board: - lowlevel_init.S - pxavoltage.S - u-boot.lds Isn't this a clear sign to try and find a way to reuse the code for both boards? Simply copying a file verbatim is always a mistake. Who will copy the bugfixes in the future? I added Stefano on CC, maybe he has some good input on how to share code here. Cheers Detlev -- Today people don't go to rock concerts to listen to the music, because you can't. They go there to be part of the environment. -- Peter Eisenman -- 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] Add support to Colibri PXA-270 board
I don't understand why you are so angry... There is no simple implementation of code reuse within the boards. You know the code much better than I do. Please free to drop this implementation. Alon. On Tue, Apr 7, 2009 at 9:22 PM, Detlev Zundel d...@denx.de wrote: Hi Alon, It was not my intention to add publicity my name, but provide a solution for users, as it took a lot of work to make it work without many changes from other implementation. Adding someones name to code that one has written is primarily not for publicity reasons but for somple tracking reasons. Who do you think people will turn to if they see problems in the code? What would you say if someone mailed you about a problem in your code which you have never seen before? Any way to do it using a reuse would be super, although this is not the only duplication in u-boot board tree... Yes, and maybe you realize how *damn* (sorry) some of us work to eliminate this. I never tire of stating that the cost of fixing a problem in software is exponential to the time of its discovery. Translated into U-Boot context this means, that we do *not* allow simple code duplication. If such a case slips through the review process, this is nowhere near a reason to allow it the next time. So please, reconsider adding to the mess instead of decreasing it or even keeping the mess-level constant ;) Cheers Detlev -- The 82558 B-step and later generation devices do not maintain a link in D3 if PME is disabled or if the device does not have power. -- Intel documentation -- 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] Toradex Colibri PXA-320
Hello, Has anyone got this working? Toradex does not seem to support open source, and forward people to its partners, while these seems to have a solution, but do not publish their work as they should. I succeeded in making the Colibri PXA-270, using trizepsiv board as base and previous work of Danial Mach [1]. I will post the work as soon as I can. However, I need to make the PXA-320 board working too... One of the main issues is that this board has only NAND flash and it is not clear to me how much of the NAND is available during bootstrap. I appreciate any help, Alon Bar-Lev. [1] http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg01498.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
