Re: [U-Boot] [ANN] U-Boot v2015.10-rc5 released
Hi Wolfgang, Tom, On Thu, Oct 15, 2015 at 9:28 AM, Wolfgang Denk wrote: > Dear Tom, > > In message <20151015004002.GX23893@bill-the-cat> you wrote: >> >> I'm just not sure what to do about CONFIG_API some days. I know one use >> case is for GRUB but I'd like to move away from that if possible >> (distros should be doing the generic distro bits and extlinux.conf). >> After that, I'm only hazily aware of the real use-cases. > > The major use case (as I understand it) are the FreeBSD users > who need this API for booting. I'm adding Rafal and Bartek to Cc: > as they should know best if this interface is still in wide use. Indeed, it's actively and widely used by the FreeBSD [last stage] bootloader. Thanks, Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] freebsd 8 installer on MPC8349E-mITX
On 2010-06-23, at 18:08, Zied Fakhfakh wrote: > Hi > am trying to boot, freebsd 8 instalelr on the MPC8349E-mITX. > > I loaded the ubldr: > MPC8349E-mITX> tftpboot $loadaddr freebsd8/boot/ubldr > Speed: 100, full duplex > Using TSEC0 device > TFTP from server 192.168.0.194; our IP address is 192.168.0.248 > Filename 'freebsd8/boot/ubldr'. > Load address: 0x80 > Loading: # > done > Bytes transferred = 177964 (2b72c hex) > > and than trying to boot: > MPC8349E-mITX> bootelf $loadaddr > ## Starting application at 0x00010080 ... > Bad trap at PC: 2ee08, SR: 3032, vector=300 > NIP: 0002EE08 XER: 2000 LR: 0002A2DC REGS: 0ff52b18 TRAP: 0300 DAR: > 1000 > MSR: 3032 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 11 > > GPR00: 0FF52C08 0FF52F50 1000 00035EF8 0008 > > GPR08: 0055 0021 3032 48044042 0D1A0082 > > GPR16: 0FFB5A14 0FFBC2C0 > > GPR24: 0FF52C24 0FF52C10 00035EF8 0FF52C60 1018 00032A8C > 1000 > Call backtrace: > 0FF55338 00017C78 0FF84100 0FF841BC 0FF94CBC 0FF943D0 0FF9461C > 0FF94BFC 0FF943D0 0FF94540 0FF97074 0FF79A24 0FF78600 > Exception in kernel pc 2ee08 signal 0 > Resetting the board. > > > U-Boot 2010.03 (Jun 22 2010 - 15:17:07) MPC83XX > .. . . . . . . . . . > > any idea ? Just making sure: have you got CONFIG_API enabled in your U-Boot config? Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] API License Terms
On 2009-09-01, at 20:08, Wolfgang Denk wrote:
>> 3) If presume that we cannot use the GPLv2 glue files in a
>> closed
>> source application.
>
> Correct.
There's also a BSD licensed version of the gluing code and the syscall
entry, which is used for integration of the FreeBSD loader(8) with U-
Boot through the API, so maybe using this code would be an option:
http://svn.freebsd.org/base/head/sys/boot/uboot/lib/glue.{c,h}
http://svn.freebsd.org/base/head/sys/boot/powerpc/uboot/start.S
Rafal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] API code - licensing
Dear Wolfgang, On 2009-07-27, at 09:35, Wolfgang Denk wrote: > I somehow had developed the impression thatthe API code was intended > to be some "next generation" implementation for standalone programs, > with one of the primary purposes being the implementation of > (potentially closed source) bootstrap loader code for FreeBSD. Yes, the API was meant to be generic and extensible mechanism for modern standalone applications, to replace the legacy jumptable mechanism at some point. The FreeBSD loader(8) was a successful test bed for it, so I surely recommend using the API :-) > But now I realize that the API code is actually linking against parts > of the U-Boot code, so any code based on the U-Bott API must in- > herently be GPLed. The demo application provided in the U-Boot source tree (examples/api) indeed re-uses some parts of the U-Boot code (to avoid code duplication), but in general this is not a requirement. The FreeBSD loader(8) is self-contained and does not include any U-Boot code, it just calls the API. kind regards, Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] export SPI functions to standalone apps
On 2009-07-19, at 04:22, Mike Frysinger wrote: > Signed-off-by: Mike Frysinger > --- > common/exports.c |8 > include/_exports.h |8 > include/exports.h |3 ++- > 3 files changed, 18 insertions(+), 1 deletions(-) > > diff --git a/common/exports.c b/common/exports.c > index ec4656b..b3b6e1f 100644 > --- a/common/exports.c > +++ b/common/exports.c > @@ -38,4 +38,12 @@ void jumptable_init (void) > gd->jt[XF_i2c_write] = (void *) i2c_write; > gd->jt[XF_i2c_read] = (void *) i2c_read; > #endif > +#ifdef CONFIG_CMD_SPI > + gd->jt[XF_spi_init] = (void *) spi_init; > + gd->jt[XF_spi_setup_slave] = (void *) spi_setup_slave; > + gd->jt[XF_spi_free_slave] = (void *) spi_free_slave; > + gd->jt[XF_spi_claim_bus] = (void *) spi_claim_bus; > + gd->jt[XF_spi_release_bus] = (void *) spi_release_bus; > + gd->jt[XF_spi_xfer] = (void *) spi_xfer; > +#endif > } Such conditional entries in the jumptable make this interface unstable, as the calls table is made dependent on configuration of a particular image built, while it should only depend on the interface version. The application in such case is entagled with the knowledge of how the underlying firmware was configured at build time. I know there are other calls already #ifdef'ed, but they should be all fixed. Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_API, EABI and raise()
Hi Stefan, On 2009-07-16, at 10:46, Stefan Roese wrote: > On Thursday 16 July 2009 10:37:34 Rafal Jaworowski wrote: >> On 2009-07-15, at 18:09, Mike Frysinger wrote: >>> On Wednesday 15 July 2009 11:15:46 Rafal Jaworowski wrote: >>>> On 2009-07-15, at 16:58, Mike Frysinger wrote: >>>>> On Tuesday 14 July 2009 09:47:26 Piotr Zięcik wrote: >>>>>> While working on U-Boot for our board we have found problem >>>>>> related >>>>>> to CONFIG_API option. In general, enabling it causes build >>>>>> failure. >>>>>> Our tests showed that problem exists also on other ARM U-Boot >>>>>> targets >>>>>> (for example davinci_dvevm). >>>>>> >>>>>> Do you think that this problem may be caused by your libgcc- >>>>>> related >>>>>> cleanups ? If so, do you have any idea how to fix it ? >>>>> >>>>> sounds more like it's always been a bug, but Jean's cleanup will >>>>> fix >>>>> it eventually >>>> >>>> CONFIG_API worked fine for ARM builds some time ago, and this >>>> breakage >>>> seems like a recent development. >>> >>> or, it still works fine if your toolchain doesnt suck and isnt >>> broken >> >> The toolchain is ELDK 4.2 and has worked fine for longer time. > > Just to make it clear: The libgcc removal patches for ARM from Jean- > Christophe > are not added yet. So if you see a problem with EABI etc, some other > patches > have to be the reason for this. And very likely Jean-Christophe's > patches > could fix the problems. Thanks for pointing this out, we'll look into it some more (I'm all for removing libgcc dependency, but was under the impression that parts of this rework was already included in main line, and thought there might be some loose ends or so). Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_API, EABI and raise()
On 2009-07-15, at 18:09, Mike Frysinger wrote: > On Wednesday 15 July 2009 11:15:46 Rafal Jaworowski wrote: >> On 2009-07-15, at 16:58, Mike Frysinger wrote: >>> On Tuesday 14 July 2009 09:47:26 Piotr Zięcik wrote: >>>> While working on U-Boot for our board we have found problem related >>>> to CONFIG_API option. In general, enabling it causes build failure. >>>> Our tests showed that problem exists also on other ARM U-Boot >>>> targets >>>> (for example davinci_dvevm). >>>> >>>> Do you think that this problem may be caused by your libgcc-related >>>> cleanups ? If so, do you have any idea how to fix it ? >>> >>> sounds more like it's always been a bug, but Jean's cleanup will fix >>> it eventually >> >> CONFIG_API worked fine for ARM builds some time ago, and this >> breakage >> seems like a recent development. > > or, it still works fine if your toolchain doesnt suck and isnt broken The toolchain is ELDK 4.2 and has worked fine for longer time. Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_API, EABI and raise()
On 2009-07-15, at 16:58, Mike Frysinger wrote: > On Tuesday 14 July 2009 09:47:26 Piotr Zięcik wrote: >> While working on U-Boot for our board we have found problem related >> to >> CONFIG_API option. In general, enabling it causes build failure. >> Our tests >> showed that problem exists also on other ARM U-Boot targets (for >> example >> davinci_dvevm). >> >> Do you think that this problem may be caused by your libgcc-related >> cleanups ? If so, do you have any idea how to fix it ? > > sounds more like it's always been a bug, but Jean's cleanup will fix > it > eventually CONFIG_API worked fine for ARM builds some time ago, and this breakage seems like a recent development. Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
Hi Peter, On 2009-07-14, at 17:20, Peter Tyser wrote: > I like the Linux and u-boot-v2 directory layout too the more I think > about it too. How about if I resend this series but with the final > directory structure looking like: > > /arch/$(ARCH)/lib/ > /lib/ > / > /libfdt/ > /lzma/ > /lzo/ > > /examples/ > /api/ > /standalone/ Not directly answering your question, but rather a minor naming nit: strictly speaking the 'api' subdir contents are also standalone applications... so the above naming scheme is not clear cut, although I don't have much better suggestions :-) The 'standalone' above use the legacy jumptable calls method, so maybe 'jumptable' dirname would work? Other thoughts? Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] Move api_examples to api/examples
On 2009-07-09, at 18:36, Peter Tyser wrote:
> On Thu, 2009-07-09 at 18:22 +0200, Rafal Jaworowski wrote:
>> On 2009-07-09, at 17:08, Peter Tyser wrote:
>>
>>> Signed-off-by: Peter Tyser
>>> ---
>>> Makefile|4 ++--
>>> {api_examples => api/examples}/.gitignore |0
>>> {api_examples => api/examples}/Makefile |8
>>> {api_examples => api/examples}/crt0.S |0
>>> {api_examples => api/examples}/demo.c |0
>>> {api_examples => api/examples}/glue.c |0
>>> {api_examples => api/examples}/glue.h |0
>>> {api_examples => api/examples}/libgenwrap.c |0
>>
>> Hi Peter,
>> Please don't do this. I would like to have api_examples stay clear
>> from the API proper and such organization was introduced on purpose.
>> While the core API code is integral part of U-Boot code image, the
>> example/demo/other app is physically separate tangible entity. I
>> think
>> it seems proper that directories' layout reflects this. What we could
>> do is provide a top level directory grouping all items non-integral
>> wrt U-Boot itself (examples, api_examples) and put them there.
>
> Hi Rafal,
> I don't really follow... The api_example/ directory is an example of
> how to use the functionality provided by the code in the api/
> directory,
> right? If so, they are very closely related and I'd argue that the
> api_example/ directory should be moved into api/ since conceptually it
> makes more sense as well as cleans up the directory structure.
The API core and its example/demo app are indeed closely related, but
the example/demo code is complementary to the core API, not part of
it. My concern is that putting examples in the core API directory is
misleading as would give an impression of the example being part of
the API, where it's a physically separate thing pertaining to another
domain (standalone applications as opposed to the integral U-Boot
code); I would prefer to keep them separate.
> If the number of API applications grows from the current "example",
> we're not going to put them in their own /api_app1, /api_app2, etc
> directories, are we? Wouldn't /api/app1, /api/app2, etc make more
> sense?
When we grow more example apps, they could simply all live in the
api_examples directory (which can be managed with a single makefile).
kind regards,
Rafal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] Move api_examples to api/examples
On 2009-07-09, at 17:08, Peter Tyser wrote:
> Signed-off-by: Peter Tyser
> ---
> Makefile|4 ++--
> {api_examples => api/examples}/.gitignore |0
> {api_examples => api/examples}/Makefile |8
> {api_examples => api/examples}/crt0.S |0
> {api_examples => api/examples}/demo.c |0
> {api_examples => api/examples}/glue.c |0
> {api_examples => api/examples}/glue.h |0
> {api_examples => api/examples}/libgenwrap.c |0
Hi Peter,
Please don't do this. I would like to have api_examples stay clear
from the API proper and such organization was introduced on purpose.
While the core API code is integral part of U-Boot code image, the
example/demo/other app is physically separate tangible entity. I think
it seems proper that directories' layout reflects this. What we could
do is provide a top level directory grouping all items non-integral
wrt U-Boot itself (examples, api_examples) and put them there.
Rafal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] api_examples/Makefile: Split up variable declarations
On 2009-06-23, at 01:01, Peter Tyser wrote: > This cleans up the Makefile a bit and simplifies future changes > > Signed-off-by: Peter Tyser > --- > These are some similar changes to the ones I made to the tools > directory recently. It gets rid of symlinking source files which > has the side benefit of resolving the out of tree build error > for the API code. Hi Peter, Thanks a lot for taking care of this. All 4 patches look fine, so "Acked-by" from me. Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Out-of-tree build of API code fails
Dear Wolfgang, On 2009-06-14, at 21:29, Wolfgang Denk wrote: > in message <63279ff4-75bf-44e5-914e-213c2bf41...@semihalf.com> you > wrote: >> > it seems the api_examples/ code fails when building out of tree: ... > Could you please have a look? Thanks in advance. Sure, I'll take a look. >>> >>> Did your 'having a look' result in any results, like a patch that >>> fixes the problem? >> >> At the time I looked at this the main line build was broken due to >> other issues, so I need to see to it again. > > This is still broken (and I don'e see any related main line build that > is broken), so could you *please* have a look again? I was actually working on this on Sat, but it seems like something obscure and I could not find the cause of the problem so far. I don't have much time right now to look into it any deeper though, so it has to wait, sorry (unless someone else can try to fix it). kind regards, Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] API Licence
On 2009-05-19, at 00:13, Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <20090518212049.gj17...@game.jcrosoft.org> you wrote: >> >> I've to write an application that need to use the mmc and net but >> can not >> be under GPL > > MMC is not exported to API, is it? It is, in the same way as all other storage means: the API lets to read raw blocks from it. kind regards, Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Out-of-tree build of API code fails
On 2009-05-15, at 23:19, Wolfgang Denk wrote: > In message <0ad43a8e-402b-41f0-bab1-e6d7f7537...@semihalf.com> you > wrote: >> Dear Wolfgang, >> >> On 2009-03-29, at 00:03, Wolfgang Denk wrote: >> >>> Dear Rafal, >>> >>> it seems the api_examples/ code fails when building out of tree: >> >> ... >> >>> Could you please have a look? Thanks in advance. >> >> Sure, I'll take a look. > > Did your 'having a look' result in any results, like a patch that > fixes the problem? At the time I looked at this the main line build was broken due to other issues, so I need to see to it again. kind regards, Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory problems on mpc8572ds
On 2009-05-14, at 19:22, Sebastian Andrzej Siewior wrote: > Hello, > > my mpc8572ds (2x 512 MiB ram) had initially u-boot 1.3.0-rc2 and I > haven't notice any problems. Today I updated u-boot to v2009.03 > because > I was not able to boot current vanilla linux kernel in smp mode. > Since then I experience random kernel opses. I thing it has > something to > do with memory setup. The settings in the ddr controller changed from > (v1.3.0-rc2): > - ddr->sdram_mode 0x00400a62; > - ddr->sdram_data_init = 0x; > - ddr->sdram_cfg_2 = 0x04401000; > > to (v2009.03): > - ddr->sdram_mode 0x00440a62 > - ddr->sdram_data_init 0xdeadbeef > - ddr->sdram_cfg_2 0x24401000 > > I cherry-picked commit 6a819783 aka "fsl-ddr: Fix two bugs in the ddr > infrastructure" but nothing improved. > > Now I've picked v1.3.0-rc2 and linux v2.6.29. With that combination > everything seems to work however I experience sometimes ICE while > compiling. If I continue to compile from that point there is no ICE > anymore so it does not look like a gcc bug to me. > > Any suggestions? Someone with similar problems? I can confirm this. We have been suffering from instabilities of the main line U-Boot on MPC8572DS since a long time ago. It is strongly correlated with memory controller settings: the same h/w unit works fine with 1.3.0-rc2 (Freescale LTIB), while using anything newer from main line leads to hangs and/or corruptions. We tried to nail down the issue, but could not find anything conclusive in the given time, so just stick with that old (but stable) 1.3.0 derivative... Sometimes the corruptions could be observed using U-Boot mtest, sometimes not, but usually everything looked fine until more memory intensive operations at the OS level: heavier network traffic would cause checksum errors showing up and other corruptions, including hangs. Interleaved mode seemed to have *some* effect: typically disabling interleaved config would give somewhat less corrupt-prone behaviour (it takes much longer to trigger the faults, but they would pop up eventually). Other data point: we observed much often the above problems with rev1.1 of the silicon, rev1.0 is also failing, but 1.1 is very quick to err. Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Out-of-tree build of API code fails
Dear Wolfgang, On 2009-03-29, at 00:03, Wolfgang Denk wrote: > Dear Rafal, > > it seems the api_examples/ code fails when building out of tree: ... > Could you please have a look? Thanks in advance. Sure, I'll take a look. kind regards, Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
On 2009-03-26, at 15:21, Jon Smirl wrote:
> Libraries appear to be the problem. A program that just returns is 100
> bytes, add a puts("hello world") and it is 65KB.
>
> I had expected the u-boot app examples to be smart and use the copy of
> those libraries in the u-boot image. For example the demo program in
> api_examples uses printf (65K library) instead of building an api
> calling into u-boot for printf.
While I can understand your position, let me explain that the idea
behind the API was to provide calls to really elementary operations
and printf() wasn't considered as such (we only have print, get and
test a single character as far as console ops go); things like pre-
formatting should be done in the application...
The demo application is just a demo, it links in the same printf-
formatting code that U-Boot library uses, but specific standalone
applications are supposed to implement their own formatting routines.
Rafal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] API: Improve glue mid-layer of the API demo application.
- Extend ub_dev_read() and ub_dev_recv() so they return the length actually
read, which allows for better control and error handling (this introduces
additional error code API_ESYSC returned by the glue mid-layer).
- Clean up definitions naming and usage.
- Other minor cosmetics.
Note these changes do not touch the API proper, so the interface between
U-Boot and standalone applications remains unchanged.
Signed-off-by: Rafal Jaworowski
---
api_examples/demo.c |8 ++
api_examples/glue.c | 58 +
api_examples/glue.h | 16 -
include/api_public.h |1 +
4 files changed, 39 insertions(+), 44 deletions(-)
diff --git a/api_examples/demo.c b/api_examples/demo.c
index 2510ed8..df9c4bd 100644
--- a/api_examples/demo.c
+++ b/api_examples/demo.c
@@ -43,12 +43,11 @@ static char buf[BUF_SZ];
int main(int argc, char *argv[])
{
- int rv = 0;
- int h, i, j;
- int devs_no;
+ int rv = 0, h, i, j, devs_no;
struct api_signature *sig = NULL;
ulong start, now;
struct device_info *di;
+ lbasize_t rlen;
if (!api_search_sig(&sig))
return -1;
@@ -96,7 +95,6 @@ int main(int argc, char *argv[])
if (devs_no == 0)
return -1;
-
printf("\n*** Show devices ***\n");
for (i = 0; i < devs_no; i++) {
test_dump_di(i);
@@ -133,7 +131,7 @@ int main(int argc, char *argv[])
if ((rv = ub_dev_open(i)) != 0)
errf("open device %d error %d\n", i, rv);
- else if ((rv = ub_dev_read(i, buf, 1, 0)) != 0)
+ else if ((rv = ub_dev_read(i, buf, 1, 0, &rlen)) != 0)
errf("could not read from device %d, error %d\n", i,
rv);
else {
printf("Sector 0 dump (512B):\n");
diff --git a/api_examples/glue.c b/api_examples/glue.c
index 200b163..eff6a7e 100644
--- a/api_examples/glue.c
+++ b/api_examples/glue.c
@@ -1,7 +1,5 @@
/*
- * (C) Copyright 2007 Semihalf
- *
- * Written by: Rafal Jaworowski
+ * (C) Copyright 2007-2008 Semihalf, Rafal Jaworowski
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -57,8 +55,8 @@ static int valid_sig(struct api_signature *sig)
*
* returns 1/0 depending on found/not found result
*/
-int api_search_sig(struct api_signature **sig) {
-
+int api_search_sig(struct api_signature **sig)
+{
unsigned char *sp;
uint32_t search_start = 0;
uint32_t search_end = 0;
@@ -133,8 +131,7 @@ void ub_reset(void)
syscall(API_RESET, NULL);
}
-#define MR_MAX 5
-static struct mem_region mr[MR_MAX];
+static struct mem_region mr[UB_MAX_MR];
static struct sys_info si;
struct sys_info * ub_get_sys_info(void)
@@ -143,7 +140,7 @@ struct sys_info * ub_get_sys_info(void)
memset(&si, 0, sizeof(struct sys_info));
si.mr = mr;
- si.mr_no = MR_MAX;
+ si.mr_no = UB_MAX_MR;
memset(&mr, 0, sizeof(mr));
if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si))
@@ -178,17 +175,15 @@ unsigned long ub_get_timer(unsigned long base)
*
* devices
*
- * Devices are identified by handles: numbers 0, 1, 2, ..., MAX_DEVS-1
+ * Devices are identified by handles: numbers 0, 1, 2, ..., UB_MAX_DEV-1
*
***/
-#define MAX_DEVS 6
-
-static struct device_info devices[MAX_DEVS];
+static struct device_info devices[UB_MAX_DEV];
struct device_info * ub_dev_get(int i)
{
- return ((i < 0 || i >= MAX_DEVS) ? NULL : &devices[i]);
+ return ((i < 0 || i >= UB_MAX_DEV) ? NULL : &devices[i]);
}
/*
@@ -202,7 +197,7 @@ int ub_dev_enum(void)
struct device_info *di;
int n = 0;
- memset(&devices, 0, sizeof(struct device_info) * MAX_DEVS);
+ memset(&devices, 0, sizeof(struct device_info) * UB_MAX_DEV);
di = &devices[0];
if (!syscall(API_DEV_ENUM, NULL, di))
@@ -210,7 +205,7 @@ int ub_dev_enum(void)
while (di->cookie != NULL) {
- if (++n >= MAX_DEVS)
+ if (++n >= UB_MAX_DEV)
break;
/* take another device_info */
@@ -236,7 +231,7 @@ int ub_dev_open(int handle)
struct device_info *di;
int err = 0;
- if (handle < 0 || handle >= MAX_DEVS)
+ if (handle < 0 || handle >= UB_MAX_DEV)
return API_EINVAL;
di = &devices[handle];
@@ -251,7 +246,7 @@ int ub_dev_close(int handle)
{
struct device_info *di;
- if (handle < 0 || handle >= MAX_DEVS)
+ if (handle < 0 || handle >= UB_MAX_DEV)
return API_EINVAL;
di = &devices[handle];
@@ -272,7 +267,7 @@ int ub_dev_close(int ha
[U-Boot] [PATCH 1/4] API: Use stack pointer as API signature search hint in the glue layer.
De-hardcode range in RAM we search for the API signature. Instead use the stack
pointer as a hint to narrow down the range in which the signature could reside
(it is malloc'ed on the U-Boot heap, and is hoped to remain in some proximity
from stack area). Adjust PowerPC code in API demo to the new scheme.
Signed-off-by: Rafal Czubak
Signed-off-by: Rafal Jaworowski
---
api_examples/crt0.S | 14 ++
api_examples/glue.c | 11 +--
api_examples/glue.h |8
3 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/api_examples/crt0.S b/api_examples/crt0.S
index 8d4f706..3129a07 100644
--- a/api_examples/crt0.S
+++ b/api_examples/crt0.S
@@ -29,6 +29,9 @@
.globl _start
_start:
+ lis %r11, search_h...@ha
+ addi%r11, %r11, search_h...@l
+ stw %r1, 0(%r11)
b main
@@ -39,12 +42,15 @@ syscall:
lwz %r11, 0(%r11)
mtctr %r11
bctr
-
+#else
+#error No support for this arch!
+#endif
.globl syscall_ptr
syscall_ptr:
.align 4
.long 0
-#else
-#error No support for this arch!
-#endif
+
+ .globl search_hint
+search_hint:
+ .long 0
diff --git a/api_examples/glue.c b/api_examples/glue.c
index 2bf47ae..200b163 100644
--- a/api_examples/glue.c
+++ b/api_examples/glue.c
@@ -60,13 +60,20 @@ static int valid_sig(struct api_signature *sig)
int api_search_sig(struct api_signature **sig) {
unsigned char *sp;
+ uint32_t search_start = 0;
+ uint32_t search_end = 0;
if (sig == NULL)
return 0;
- sp = (unsigned char *)API_SEARCH_START;
+ if (search_hint == 0)
+ search_hint = 255 * 1024 * 1024;
- while ((sp + (int)API_SIG_MAGLEN) < (unsigned char *)API_SEARCH_END) {
+ search_start = search_hint & ~0x000f;
+ search_end = search_start + API_SEARCH_LEN - API_SIG_MAGLEN;
+
+ sp = (unsigned char *)search_start;
+ while ((sp + API_SIG_MAGLEN) < (unsigned char *)search_end) {
if (!memcmp(sp, API_SIG_MAGIC, API_SIG_MAGLEN)) {
*sig = (struct api_signature *)sp;
if (valid_sig(*sig))
diff --git a/api_examples/glue.h b/api_examples/glue.h
index a82f783..0adb8b3 100644
--- a/api_examples/glue.h
+++ b/api_examples/glue.h
@@ -30,12 +30,12 @@
#ifndef _API_GLUE_H_
#define _API_GLUE_H_
-#define API_SEARCH_START (255 * 1024 * 1024) /* start at 1MB below
top RAM */
-#define API_SEARCH_END (256 * 1024 * 1024 - 1) /* ...and search to the
end */
+#define API_SEARCH_LEN (3 * 1024 * 1024) /* 3MB search range */
-intsyscall(int, int *, ...);
-void * syscall_ptr;
+extern void *syscall_ptr;
+extern uint32_t search_hint;
+intsyscall(int, int *, ...);
intapi_search_sig(struct api_signature **sig);
/*
--
1.5.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] API: Provide syscall entry point for the ARM architecture.
Signed-off-by: Rafal Czubak Acked-by: Rafal Jaworowski --- api_examples/Makefile |7 +++ api_examples/crt0.S | 17 - lib_arm/board.c |5 + 3 files changed, 24 insertions(+), 5 deletions(-) diff --git a/api_examples/Makefile b/api_examples/Makefile index 5666f48..4c01437 100644 --- a/api_examples/Makefile +++ b/api_examples/Makefile @@ -23,10 +23,9 @@ ifeq ($(ARCH),ppc) LOAD_ADDR = 0x4 endif - -#ifeq ($(ARCH),arm) -#LOAD_ADDR = 0xc10 -#endif +ifeq ($(ARCH),arm) +LOAD_ADDR = 0x100 +endif include $(TOPDIR)/config.mk diff --git a/api_examples/crt0.S b/api_examples/crt0.S index 3129a07..6daf127 100644 --- a/api_examples/crt0.S +++ b/api_examples/crt0.S @@ -26,7 +26,6 @@ #if defined(CONFIG_PPC) .text - .globl _start _start: lis %r11, search_h...@ha @@ -42,6 +41,22 @@ syscall: lwz %r11, 0(%r11) mtctr %r11 bctr + +#elif defined(CONFIG_ARM) + + .text + .globl _start +_start: + ldr ip, =search_hint + str sp, [ip] + b main + + + .globl syscall +syscall: + ldr ip, =syscall_ptr + ldr pc, [ip] + #else #error No support for this arch! #endif diff --git a/lib_arm/board.c b/lib_arm/board.c index 2358beb..4cb3f2e 100644 --- a/lib_arm/board.c +++ b/lib_arm/board.c @@ -404,6 +404,11 @@ void start_armboot (void) jumptable_init (); +#if defined(CONFIG_API) + /* Initialize API */ + api_init (); +#endif + console_init_r (); /* fully init console as a device */ #if defined(CONFIG_MISC_INIT_R) -- 1.5.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] API: Only output test data when reading was successful.
Signed-off-by: Rafal Czubak
---
api_examples/demo.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/api_examples/demo.c b/api_examples/demo.c
index 69ac318..2510ed8 100644
--- a/api_examples/demo.c
+++ b/api_examples/demo.c
@@ -135,9 +135,10 @@ int main(int argc, char *argv[])
else if ((rv = ub_dev_read(i, buf, 1, 0)) != 0)
errf("could not read from device %d, error %d\n", i,
rv);
-
- printf("Sector 0 dump (512B):\n");
- test_dump_buf(buf, 512);
+ else {
+ printf("Sector 0 dump (512B):\n");
+ test_dump_buf(buf, 512);
+ }
ub_dev_close(i);
}
@@ -178,6 +179,7 @@ int main(int argc, char *argv[])
printf("%s = %s\n", env, ub_env_get(env));
/* reset */
+ printf("\n*** Resetting board ***\n");
ub_reset();
printf("\nHmm, reset returned...?!\n");
--
1.5.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Inefficient code in NetLoop() ?
Stefan Roese wrote: > On Friday 26 September 2008, Wolfgang Denk wrote: Am I reading this correctly that we eth_halt() and eth_init() the network interface for each and every call to NetLoop? >>> Yes, it looks that way. Ripe for gutting. >> I didn't have much time to look into the code, so I'm just speculating >> - maybe this is needed for switching interfaces in case of errors? > > Some ethernet interfaces (e.g. ppc4xx) need to get stopped after the network > transaction. Otherwise the interface will continue to DMA data to the buffers > and this could break OS booting. So please don't remove the eth_halt() after > the transaction is finished. I share Stefan's concerns. Isn't in general the eth_init()/eth_halt() construct because of polling mode where the network controller needs to make sure to operate in well defined states? In our deployments of using U-Boot networking facilities in standalone apps, there were problems when not doing the full eth_init()/eth_halt() sequence: without closing eth_halt() after the initial successfull transaction the network interface would choke and not work after some time, and all subsequent transfers would fail. kind regards, Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Location of jump table in global_data structure
Peter Tyser wrote: *snip* >>> Do others view this issue as a problem that should be fixed? >> Yes. >> >>> If others feel that the jt pointer should be moved to the 2nd item in >>> global_data structure let me know and I can generate a patch. >> Add a comment and police it is my vote. > > That's definitely an improvement, but doesn't handle both > adding/removing fields from the global_data structure in a clean manner. > I'd still lean towards moving the jt pointer to one of the earlier > fields of the structs as well as adding a comment. Then at least the > jump table portion of the API would be stable, even if accessing the > "global_data fields" API wouldn't. Right now, neither API is stable:) > > If anyone has any other clever ideas on improving the API, I'd be happy > to investigate/implement. There already is a modern API for external applications in U-Boot since 1.3.2 (but not enabled by default). Please see 'api/README' and 'api_examples' in the U-Boot tree. So far it has been used successfully on PowerPC and ARM; there's no support for AVR arch yet, but providing the syscall entry point for it shouldn't be a big deal for someone with AVR knowledge. Let me know if you'd be willing to chew on it (I don't have AVR h/w but can help/support regarding the API itself). kind regards, Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enquiry for code supporting for MPC8572pc.Thanks!
lifengkai wrote: > I downloaded the U-boot code yesterday, I can see that there is support for > Freescale MPC85XX, but no specifically code supporting for MPC8572pc. > > So I am wondering when the code for MPC8572 will be relased? Will it be > soon? Support for the MPC8572 has been posted only recently, so it's not included in the mainline yet and you need to patch your sources manually; see: http://www.nabble.com/-U-Boot---PATCH-1-3--mpc85xx%3A-Add-support-for-the-MPC8572DS-reference-board-td18947664.html Note this is for the MPC8572DS, but it should get you started with your device. kind regards, Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
