Re: [U-Boot-Users] Compilation problem for TI3430 board.

[Jerry Van Baren]

Radha Krishna wrote:
>  Hi,
>
>I have downloaded U-boot and trying to compile it for the
>Target omap3430sdp_config. 
>   
>   Using commands 

[snip]

> $ make CROSS_COMPILE=arm-none-linux-gnueabi- omap3430sdp_config
> ./mkconfig: line 2: $'\r': command not found
> make: *** [omap3430sdp_config] Error 127

Is that telling you that you have DOS line endings (+ i.e. \r\n) 
as opposed to unix line endings (\n only)?

> $ make CROSS_COMPILE=arm-none-linux-gnueabi-
> System not configured - see README
> make: *** [all] Error 1
> 
>Could somebody tell me steps to compile U-Boot for
>  TI3430.
>
>Best Regards,
>Krishna.

My best guess,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH] Add note on dereferencing /aliases pointers

[Jerry Van Baren]

Replace the "must quote special characters" note with a hint on
how to dereference /aliases pointers by omitting the leading "/".
This feature was introduced by Kumar Gala as a libfdt enhancement
in commit ed035708235332c3c117ee3bb1a426063f03cfcb.

Example:

=> fdt print /aliases
aliases {
ethernet0 = "/[EMAIL PROTECTED]/[EMAIL PROTECTED]";
ethernet1 = "/[EMAIL PROTECTED]/[EMAIL PROTECTED]";
serial0 = "/[EMAIL PROTECTED]/[EMAIL PROTECTED]";
serial1 = "/[EMAIL PROTECTED]/[EMAIL PROTECTED]";
pci0 = "/[EMAIL PROTECTED]";
};
=> fdt print ethernet0
[EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
cell-index = <0x1>;
reg = <0x2000 0x200>;
interrupts = <0x20>;
interrupt-parent = <0x2>;
local-mac-address = [00 00 00 00 00 00];
rx-clock-name = "none";
tx-clock-name = "clk9";
phy-handle = <0x3>;
phy-connection-type = "rgmii-id";
pio-handle = <0x4>;
};

Signed-off-by: Gerald Van Baren <[EMAIL PROTECTED]>
---

I thought it would be useful to add this hint to the "help fdt" printout.
I replace the "quoting special characters" note since it is only slightly
useful - hopefully quoting special characters is second nature to our
target audience.

If nobody has any objections to this and the previously posted libfdt
update changesets, I plan to issue a u-boot-fdt pull request by Monday.

Best regards,
gvb

 common/cmd_fdt.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index d3b19dd..05a328f 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -799,6 +799,6 @@ U_BOOT_CMD(
"fdt rsvmem add  - Add a mem reserve\n"
"fdt rsvmem delete- Delete a mem reserves\n"
"fdt chosen - Add/update the /chosen branch in the tree\n"
-   "NOTE: If the path or property you are setting/printing has a '#' 
character\n"
-   " or spaces, you MUST escape it with a \\ character or quote it 
with \".\n"
+   "NOTE: Dereference aliases by omiting the leading '/', "
+   "e.g. fdt print ethernet0.\n"
 );
-- 
1.5.6.3


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] GT-64120 PCI init

[Jerry Van Baren]

Richard Danter wrote:
> Hi all,
> 
> I have an old MIPS board with a GT-64120 that I would like to port
> U-Boot to. I have so far got it to boot from flash, init SDRAM and a
> serial console and give me a prompt so I can run some commands. I am
> also able to write flash for saving env vars, etc. To make this really
> useful however I need to get PCI working and then Ethernet.
> 
> I don't see any 64120 driver/init code in the sources so unless I have
> missed something I guess I am going to have to write some.

Looks like it.

> Having not done this before can anyone suggest where to start?

Data sheets if you have them.

Google says linux drivers may be a useful reference.
   

> Thanks
> Rich

Good luck,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] bootm as a script -- requires HUSH?

[Jerry Van Baren]

Kumar Gala wrote:
> On Aug 7, 2008, at 2:29 PM, Wolfgang Denk wrote:
> 
>> In message  
>> <[EMAIL PROTECTED]> you wrote:
>>> if I understand Wolfgang and Jerry they'd like to recode the control
>>> flow of the bootm command in the scripting env u-boot provides.
>>>
>>> This seems to imply that we'd require HUSH as the simple parser
>>> doesn't seem to provide any control statements like (if..then..else).
>>>
>>> is this correct?
>> I woul like to avoid that, if possible.
> 
> Which implies to me the sequence has to be a simple ordered sequence w/ 
> o any if/than/else aspects to it.  Am I missing something?
> 
> - k

Nope.

Remaining to be shown: how far apart "reality" is from "goal".

gvb

"I've always used my ignorance as a weapon. I don't know why things 
can't be done. Engineers spend a lot of time telling us why things can't 
be done. Sometimes they're right. But sometimes they're not."

- Garry Hoyt

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] bootm as a script -- requires HUSH?

[Jerry Van Baren]

Kumar Gala wrote:
> 
> On Aug 7, 2008, at 12:21 PM, Jerry Van Baren wrote:
> 
>> Kumar Gala wrote:
>>> if I understand Wolfgang and Jerry they'd like to recode the control  
>>> flow of the bootm command in the scripting env u-boot provides.
>>> This seems to imply that we'd require HUSH as the simple parser  
>>> doesn't seem to provide any control statements like (if..then..else).
>>> is this correct?
>>> - k
>>
>> Yes.
> 
> Than I think the ideas you guys have aren't beneficial to anyone.  What 
> benefit to we gain by doing this?  Its going to be slower and larger.
> 
> - k

...for some subset of "anyone."

A lot of people resisted moving to the linux 2.6 kernel because it is 
slower and larger than the 2.4 kernel.  A lot of embedded devices (and 
probably some servers and desktops) are still running 2.4 kernels.  I 
would not conclude that 2.6 isn't beneficial to anyone.

Maybe the destination turns into a failure, but half the fun is planning 
the trip.

gvb


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] bootm as a script -- requires HUSH?

[Jerry Van Baren]

Kumar Gala wrote:
> if I understand Wolfgang and Jerry they'd like to recode the control  
> flow of the bootm command in the scripting env u-boot provides.
> 
> This seems to imply that we'd require HUSH as the simple parser  
> doesn't seem to provide any control statements like (if..then..else).
> 
> is this correct?
> 
> - k

Yes.

gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] Allow console input to be disabled

[Jerry Van Baren]

Detlev Zundel wrote:
> Hi Haavard,
> 
>> Mark Jackson <[EMAIL PROTECTED]> wrote:
>>> Added CONFIG_SILENT_CONSOLE_INPUT define.
>>>
>>> When used (in conjunction with CONFIG_SILENT_CONSOLE) it disables all 
>>> console input.
>> Does anyone have an opinion about this? I think it's a nice thing to
>> have.
> 
> Hm, defining this and then "setenv silent=1;saveenv;reset" and we have
> lost any chance to access u-boot command line?  This looks pretty
> dangerous to me, so I do not particularly like it.
> 
> What is the original motivation to skip the input?
> 
> Cheers
>   Detlev

Dual-use of a serial port: Mark originally asked about dynamically 
inhibiting u-boot's use of the serial port for normal use, but allowing 
u-boot to use it for development/debug, selected by a jumper:
   
Hardware starved software development. :-/

For completeness, the gmane thread for the patch is here:
   

For what it is worth, I'm with Haavard - it seems useful.  WRT the 
dangerous part - it's intended use is for debug, so presumably it will 
be the developer that locks himself out of the console and will have the 
tools to break back in.  From that POV, it isn't any more dangerous than 
all the other ways a user/developer can brick a board (starting with 
erasing flash ;-).

Best regards,
gvb


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Any schedule or plan to publish your "testing" branch?

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> Yes, William hit the point. Actually It seems my work is based on two
>> different custodian trees, for example, Scott's NAND tree and
>> u-boot-at91 tree. If the 2 two trees do not merge each other,
>> sometimes I got screwed. I guess `git ' may help at this situation,
>> but I don't know how. :-)  I just wanted to know the status of the
>> NAND tree. Maybe I did not express myself clearly in the last email.
> 
> You can create your own local development branch, and merge both  the
> NAND testing branch and the at91 stuff into this branch. There may be
> merge  conflicts,  of  course,  but  I  think  both  trees are pretty
> orthogonal to each other, so chances for such conflicts are  probably
> small.

...and if there *are* merge conflicts, you can contribute back to the 
u-boot list (a) that there is a pending conflict and (b) a resolution, 
if you have one.  Having the knowledge of a merge conflict *before* the 
merge window opens is useful.  Having a proposed resolution is even more 
useful.

Thanks,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] outline of bootm script

[Jerry Van Baren]

Kumar Gala wrote:
> 
> On Aug 6, 2008, at 2:55 PM, Jerry Van Baren wrote:

[snip]

>> Having said that, I was thinking and would advocate pushing 
>> functionality out of bootm and into other commands, as appropriate.  
>> As an example, bootm doesn't need to do *any* fdt stuff, the "fdt" 
>> built-in has all the capability we need (or should).
> 
> except for locating the fdt at the right location and dealing w/initrd 
> (but that could possibly be fixed).
> 
>>  The same may be also true about load_os and load_initrd - they are 
>> copy-with-(optional)-
>> decompression operations (we may need additional commands for these).
>>
>> Philosophy: bootm should do only bootm stuff.  It (probably) should 
>> not do any image stuff (find/copy/decompress/verify).  It (probably) 
>> should not do any fdt stuff (board fixup, other?).  Etc...
> 
> This DOES NOT WORK... sorry I'm trying to make progress on this and I'm 
> not getting suggestions on a solutions just gripes about what I'm 
> suggesting.
> 
> The problem with breaking things up is that you HAVE to disable 
> interrupts and USB before you can reasonable load the OS image.  Are we 
> could to add a command for each "prereq".  How does a user know if they 
> need to "disable_caches" on their board or not?

Understood, there are some things that inherently must be done in bootm. 
That is why it is a philosophy and not a rule. ;-)

> Also there is logic in the bootm that knows how to layout the images 
> based on the constraints of memory.  Let use an example (assume OS image 
> will be loaded at 0):
> 
> bootm 100 - fff0
> 
> we load to 0, the resulting size is 1234151 bytes.  So we set "filesize" 
> to 0x12D4E7.  Since the fdt is in flash we have to copy it to memory.
> 
> So what address do we copy it to?  0x12D4E7?  No because we have to be 
> 8-byte aligned. So 0x12D4F0?  No because we have to ensure space for the 
> kernel .bss.  So we have to encode all that logic in the script?  That's 
> just asking for pain.
> 
> - k

I agree with you, ideally the script would be just a sequence of
   cmd && cmd && cmd && cmd
with no conditionals other than, if a cmd failed, it aborts the sequence 
(I'm assuming the last "cmd" would be where the point of no return is 
embedded: copying the image over the interrupt vectors, etc.).

My thoughts are that addresses would be handled by setting env variables 
initially and/or as a side effect of a cmd (yeah, side effects are 
yucky) and what is currently hard-coded as conditionals in the code 
would be re-scripted as /n/ scripts, where /n/ is some subset of the 
permutations of however many conditionals the current bootm has.

We will have to see how it plays out in reality...
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] outline of bootm script

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:

[snip]

>> Aside: verify should be an image verify command, not a env variable flag 
>> (see below).  This is probably true of most of the current env 
> 
> We alreay have a verify command. It's called "imls".



>> variables: the reason we need them is because we kept throwing stuff 
>> into "bootm" and then controlling it with env variables rather than 
>> having a sequence and controlling it with what commands are in the 
>> sequence.  (Part of my simplification argument...)
> 
> Hint: keep it backwards compatible, please.

Yes, and then deprecate it.  ;-)

>> I also was thinking we should invent a new major/minor command as you 
>> outlined, but it didn't occur to me that "bootm" would be a good major 
>> command.  This is a good idea: a bare "bootm  (|-) " 
>> could be used for backward compatibility and "bootm " for New 
>> Improved[tm] functionality.
> 
> How do your differentiate beween  and  then?

Don't use deadbeef as a command?  ;-)  With judicious choices for subcmd 
names, we can first check for subcmd and fall through to the backward 
compatibility.

[snip]

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] outline of bootm script

[Jerry Van Baren]

Kumar Gala wrote:
> On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
> 
>> Kumar Gala wrote:
>>> here's a rough start at an outline for the bootm script based on  
>>> the  code (I've only outlined the Linux/PPC boot case its seems the  
>>> most  complicated).  One of the first things we clearly need is a  
>>> imload  command.  Thoughts on the various disable_{interrupts, usb,  
>>> caches} ?
>>> - k
>> Another rough start on an outline (only cmd_bootm.c, need to add  
>> image.c information):
>>  <http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm>
>>
>> Goal is to identify the major pieces of the sequence, identify what  
>> commands we have and what we need to make a scripted equivalent  
>> sequence for (ultimately) each path through the sequence.
> 
> I added a few bullets about functionality I'd like to see the new  
> sequence to be capable of it.

Thanks for updating the page.

> one idea is having "stages" of bootm handled as sub commands:
> 
> bootm start 
> bootm prep(disable interrupts, stop usb, disable caches)
> bootm load_os (decompress OS image)
> bootm load_fdt(relocates fdt to proper place, setup bootargs, initrd  
> prep, board setup?? [or do via fdt boardsetup command])

fdt boardsetup - absolutely!

> bootm load_initrd
> bootm jump
> 
> bootm restore (undo anything prep did, reset state tracking)

Ooo, that sounds hard.  If we are only re-enabling interrupts/usb/caches 
it probably is manageable, but my hackles.

> And we keep state around so the next stage can run w/o a lot of  
> arguments and you have to execute these in order, and only once.  But  
> you can intermix other commands between the stages.
> 
> We could also have some "bootm query " to expose the internal  
> state if that's useful.  We could completely get rid of the various  
> "env" vars that impact bootm and just make them state variables  
> ("verify", "autostart", "bootm_size", "bootm_low", ...)

State is bad.

Aside: verify should be an image verify command, not a env variable flag 
(see below).  This is probably true of most of the current env 
variables: the reason we need them is because we kept throwing stuff 
into "bootm" and then controlling it with env variables rather than 
having a sequence and controlling it with what commands are in the 
sequence.  (Part of my simplification argument...)

> Also, bootm would be the sequence of:
>bootm start 
>bootm prep
>bootm load_os
>bootm load_fdt
>bootm load_initrd
>bootm jump
> 
> comments?
> 
> - k

I also was thinking we should invent a new major/minor command as you 
outlined, but it didn't occur to me that "bootm" would be a good major 
command.  This is a good idea: a bare "bootm  (|-) " 
could be used for backward compatibility and "bootm " for New 
Improved[tm] functionality.

Having said that, I was thinking and would advocate pushing 
functionality out of bootm and into other commands, as appropriate.  As 
an example, bootm doesn't need to do *any* fdt stuff, the "fdt" built-in 
has all the capability we need (or should).  The same may be also true 
about load_os and load_initrd - they are copy-with-(optional)-
decompression operations (we may need additional commands for these).

Philosophy: bootm should do only bootm stuff.  It (probably) should not 
do any image stuff (find/copy/decompress/verify).  It (probably) should 
not do any fdt stuff (board fixup, other?).  Etc...

Thanks,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH][FOR 1.3.4] 85xx: Don't move interrupt vector to low memory

[Jerry Van Baren]

Scott Wood wrote:
> On Wed, Aug 06, 2008 at 04:42:51PM +0200, Wolfgang Denk wrote:
>> In message <[EMAIL PROTECTED]> you wrote:
 Oops? This is expected and normal behaviour. Did anybody complain
 about this?
> 
> It's hit me before when I foolishly try to load something at address
> zero -- why do we put u-boot at the end of RAM, and put up with the
> relocation weirdness, if not to allow loading things at zero?
> 
>>> Real, any reason why?  I understand on classic PPC this might be the  
>>> case but I see no reason for it to be so on book-e parts.
>> Well, one reason might be to have identical code for all PPC systems ?
> 
> It's already 85xx-specific code.
> 
>>> Any they are.  I'm just removing a second relocation that is a hold  
>>> over from how 6xx PPC exception vectors work.
>> Not only 6xx. Actually all PPC.
> 
> No, not all PPC.  Book-E exceptions are different.
> 
> -Scott

One nice thing about not relocating the exception vectors to 0 is that 
it would allow us to recover from a failed bootm all the way up to the 
jump to linux (or whomever) rather than having to reset the board to 
recover from a failure late in the bootm sequence.

Unfortunately, it would be Book-E specific and probably not worth coding 
Yet Another Special Case in the already overcomplex bootm code.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] NFS TFTP problem

[Jerry Van Baren]

cjjoy1980 wrote:
> I have enabled nfs booting on ppc based embedded board.  I had placed my
> kernel and rootfs in tftp directory, and had set the u-boot enivironment
> varialbes as: 
>setenv bootfile /image/kernel 
>setenv root_path /tftpboot/image 
> 
> The board was booting with this configuration... 
> 
> Now I have placed the kernel image and rootfs in /exports directory and have
> set the uboot variables as: 
>setenv bootfile /exports/image/kernel 
>setenv root_path /exports/image 
> 
> I am not able to boot the board with the above directory.  I am getting the
> error 
> 
>Loading: T 
>TFTP error: 'File not found' (1) 
>Starting again. 
> 
> TFTP by default looks for /tftpboot directory.. How can we make the server
> to fetch files apart from the default one??

You cannot make the TFTP server fetch files apart from the default one. 
  Furthermore, you don't want to.

TFTP inherently has *NO* concept of security: no authentication - 
*anybody* can read *any* file in the TFTP directory and potentially can 
write any file they want into the TFTP directory.

As a result, TFTP servers are (and should be) severely restrictive of 
what directories they serve files out of and are willing to store files 
into (if configured to allow writing - generally a bad idea).

You can configure your TFTP server to serve the same directory as you 
export via NFS and your TFTP load will start working again.
THIS IS A VERY, VERY BAD IDEA!

As pointed out by Ben, you can symlink your image file so that it 
appears in your TFTP directory again - this is the best solution if you 
*must* move your image into the NFS directory.  You need to decide if 
you have a good reason to move your image *out* of your TFTP directory.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] outline of bootm script

[Jerry Van Baren]

Kumar Gala wrote:
> here's a rough start at an outline for the bootm script based on the  
> code (I've only outlined the Linux/PPC boot case its seems the most  
> complicated).  One of the first things we clearly need is a imload  
> command.  Thoughts on the various disable_{interrupts, usb, caches} ?
> 
> - k

Another rough start on an outline (only cmd_bootm.c, need to add image.c 
information):
   

Goal is to identify the major pieces of the sequence, identify what 
commands we have and what we need to make a scripted equivalent sequence 
for (ultimately) each path through the sequence.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Kumar Gala wrote:
> 
> On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
> 
>> Kumar Gala wrote:
>>> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:

[snip]

>>>> What do you think?
>>> While this is a cleaner implementation of what I've implemented w/ 
>>> ft_env_setup() it still doesn't completely solve my problem.  We'd  
>>> need to have a command to deal with image loading separate from 
>>> bootm  since the 'fdt' processing that does occur today is in the 
>>> middle of  the bootm flow.
>>> bootm:
>>> 1. verify and uncompress kernel image
>>> 2. relocate fdt (if needed)
>>> 3. ft_board_setup()
>>> 4. verify and uncompress ramdisk
>>> 5. update initrd info in device tree
>>> 6. jump to kernel
>>> I don't see how we can accomplish the same steps w/o breaking bootm  
>>> down into a set of builtin commands to handle the various steps and  
>>> providing enough information between the steps to accomplish the 
>>> next  step.
>>
>> Yes, that is Wolfgang's (and my) proposal: rationalize the built-in 
>> "bootm" to do just #6.  Steps 1-5 already exist as built-in commands 
>> or commands could be created almost trivially to invoke the existing 
>> code.  The current "bootm" behavior would then be emulated by a bootm 
>> script chaining them together.  All the different "bootm" behaviors 
>> would then be in the script (customizable by the user) rather than 
>> being hard-compiled into the actual bootm built-in command.
> 
> As I look at this more and more I think trying to re-encode the control 
> flow of the bootm command in a script is just insane.  There are too 
> many special cases we have to deal with that we'd just being moving from 
> C code into the script.

My assumption is that a given board/config/user will likely be using 
exactly one of the n!/k!(n-k)! possibilities implemented in the current 
"bootm" (I don't know what n and k are, but n is pretty large and k is 
hard to determine :-O).  I figure, in the worst case, a given user may 
want two or three possibilities.

By selecting from a (smallish) set of "simple" bootX scripts, I'm 
speculating that each script will not need conditional logic other than 
"&&" to bail out if an error occurs.  I'm also suspicious that replacing 
"bootm" with a simplified "bootm" with a (single) "bootm" script isn't 
going to be workable (as you contend - script complexity)... the 
solution I would propose if that happens is to maintain "bootm" as is as 
a backwards compatible CONFIG_ option and create a new "bootsimple" (or 
some such) command that is what bootm would have been if we had hush 
scripting (and prescience[1]) a few years ago.

> Unless there is some believed simplification I'm missing I don't think 
> going through all this effort produces anything that is significantly 
> better.

To make an omelet, you have to break some eggs. :-)  I see Wolfgang 
illustrated the current complexity with a list of bootm hack^H^H^H^H 
customizations in a separate message.

> My needs are meet with the simple ft_env_setup() call out.  Beyond that 
> trying to rework bootm for legacy images, CONFIG_FIT, booting w/dts, 
> boot w/o dts, linux, *bsd, vxworks, etc just seems like a lot of work 
> w/o any real benefit.

That is the practical approach for now, but that is also how we got to 
here - incrementally adding complexity to bootm.

Best regards,
gvb

[1] 
<http://en.wikipedia.org/wiki/Minor_characters_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Gogrilla_Mincefriend>

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Kumar Gala wrote:
> On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:

[snip]

>> One idea that has been spinning in my mind for some time is  to  make
>> the  "run"  command to execute the content of an environment variable
>> optional. Instead, we could try and handle environment variable names
>> similar to command names, i. e. instead of typing "run foo; run  bar"
>> you  could  just  write  "foo;  bar" (I woull probably still keep the
>> "run" command around to allow for the implicit error handling as used
>> in "run foo bar" without forcing the user to use the  hush  shell  to
>> get the equivalent "foo && bar").

[snip]

>> With such an implementation, we could move the FDT  handling  into  a
>> command  sequence  stored  in a "bootm" environment variable, and the
>> last part of this variable would be "builtin bootm" to run  the  real
>> (simplified) command.
>>
>> What do you think?
> 
> While this is a cleaner implementation of what I've implemented w/ 
> ft_env_setup() it still doesn't completely solve my problem.  We'd  
> need to have a command to deal with image loading separate from bootm  
> since the 'fdt' processing that does occur today is in the middle of  
> the bootm flow.
> 
> bootm:
> 1. verify and uncompress kernel image
> 2. relocate fdt (if needed)
> 3. ft_board_setup()
> 4. verify and uncompress ramdisk
> 5. update initrd info in device tree
> 6. jump to kernel
> 
> I don't see how we can accomplish the same steps w/o breaking bootm  
> down into a set of builtin commands to handle the various steps and  
> providing enough information between the steps to accomplish the next  
> step.

Yes, that is Wolfgang's (and my) proposal: rationalize the built-in 
"bootm" to do just #6.  Steps 1-5 already exist as built-in commands or 
commands could be created almost trivially to invoke the existing code. 
  The current "bootm" behavior would then be emulated by a bootm script 
chaining them together.  All the different "bootm" behaviors would then 
be in the script (customizable by the user) rather than being 
hard-compiled into the actual bootm built-in command.

Rather than using the C preprocessor (and deductions based on 
parameters) to select the "appropriate" bootm behavior, an appropriate 
script would be used (there would be quite a few possible scripts, 
depending on _which_ "bootm" behavior is needed for a specific 
board/config).  (Despite just having "dissed" cpp bootm behavior 
generation, I'm thinking that we would want to use the cpp to generate a 
default script that would emulate the current bootm behavior.)

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Wolfgang Denk wrote:
>> One minor flaw, I don't see how "bootm" the env script could run "bootm" 
>> the built-in command, because it would instead recursively run "bootm" 
>> the env script if scripts have higher priority and the command line 
>> "bootm" would run the built-in "bootm" if scripts have lower priority. 
> 
> That's why I think we should have an explicit "builtin" command, i. e.
> command with the name "builtin" that will always run the corresponding
> builtin command, no if there is a "command alias" or not - similar to
> the bash command:

Ahh, I missed the point that "builtin" was a command, not a concept. 
Yes, that solves the dilemma neatly.

WRT Albert's comment:
> ... and make sure that one can *never* define an environment variable 
> called 'builtin', and even remove any such definition if found in the 
> environment when reading it from persistent memory at boot.

...another way of handling this would be to special-case the "builtin" 
command so that it takes precedence over a "builtin" env variable (i.e. 
ignore an env variable named "builtin").  I'm not wild about 
auto-deleting env variables.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> My current best thought is to create a new "boot simple" (boots? 
>> bootsm?) command that contains only the essence of bootm.  I would then 
>> change the command "bootm" to do a hush script run of the env variable 
>> "bootm" (i.e. the command "bootm" would really just be "run bootm"). 
>> The env variable "bootm" would then have to be created with the complex 
>> (board/config appropriate) sequence that is currently hardcoded in the 
>> command "bootm", with the last command being "boots", of course.  This 
>> would be selected by a new CONFIG_ configuration so that old boards 
>> would go on as is until or unless the maintainer chose to move forward.
> 
> Hm... if we go to such efforts, we might even go one step farther and
> solve the problem in a more general way.
> 
> One idea that has been spinning in my mind for some time is  to  make
> the  "run"  command to execute the content of an environment variable
> optional. Instead, we could try and handle environment variable names
> similar to command names, i. e. instead of typing "run foo; run  bar"
> you  could  just  write  "foo;  bar" (I woull probably still keep the
> "run" command around to allow for the implicit error handling as used
> in "run foo bar" without forcing the user to use the  hush  shell  to
> get the equivalent "foo && bar").
> 
> Then it's just a matter of defining the search order: if the variable
> name space gets searched before the command names, we could  redefine
> all builtin commands. [Probbaly the search order (variables before or
> after   builtin  commands)  can  be  even  mad  selectable  using  an
> environment variable :-) ].
> 
> A new "builtin" command would allow to stillr efer to the original
> builtin commands.
> 
> With such an implementation, we could move the FDT  handling  into  a
> command  sequence  stored  in a "bootm" environment variable, and the
> last part of this variable would be "builtin bootm" to run  the  real
> (simplified) command.
> 
> What do you think?

That would be REALLY cool!  It would take some initial work, but the 
reward would be really simple and transparent expandability for the 
command set.  As with the "bootm" command, we might end up with simpler 
code (I don't think too many commands are as bad as bootm, however).

One minor flaw, I don't see how "bootm" the env script could run "bootm" 
the built-in command, because it would instead recursively run "bootm" 
the env script if scripts have higher priority and the command line 
"bootm" would run the built-in "bootm" if scripts have lower priority. 
The way I see it, env scripts should have higher priority than built-in 
commands and would supercede the built-in.  Hmm, one possible way out of 
the dilemma would be to support quoting built-in commands to force them, 
rather than the env script: `bootm` would be the built-in command (just 
as a concept, I don't know how back-tick quoting would conflict with 
existing hush parsing).

gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] simplify bootm command

[Jerry Van Baren]

Kumar Gala wrote:
> If we really want to simplify what bootm does than I think we should  
> remove ft_board_setup() from lib_ppc/bootm.c and expect any actually  
> modification of the device tree to have already occurred.
> 
> Is this something we'd really be willing to do?
> 
> - k

I don't think so.  We would horribly break backward compatibility and 
make a severe mess for those trying to Just Ship Product[tm].

My current best thought is to create a new "boot simple" (boots? 
bootsm?) command that contains only the essence of bootm.  I would then 
change the command "bootm" to do a hush script run of the env variable 
"bootm" (i.e. the command "bootm" would really just be "run bootm"). 
The env variable "bootm" would then have to be created with the complex 
(board/config appropriate) sequence that is currently hardcoded in the 
command "bootm", with the last command being "boots", of course.  This 
would be selected by a new CONFIG_ configuration so that old boards 
would go on as is until or unless the maintainer chose to move forward.

We probably would be able to auto-create the appropriate bootm script 
string via the C preprocessor (ala the current "bootm" command), in 
which case we could transparently replace the hardcoded "bootm" command 
with a bootm script, remaining backwards compatible.  I'm thinking the 
New Improved[tm] "bootm" command would look for a "bootm" env variable 
and, if it was not found, run a cpp-generated built-in script string 
that implemented the present "bootm" sequence.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Increasing U-Boot partition size

[Jerry Van Baren]

David Hawkins wrote:
>> Arrr, my insanity.  Wolfgang is correct, of course.
>>
> 
> Gee, and I was just going to ask why on earth you liked
> high-boot :)
> 
> I've seen one novel use of high-boot that could make it
> useful if you're lazy and can't be bothered plugging in
> your debugger ;)

Or the hardware weenies have it in a different building.

> Assuming your board has a toggle switch that sets the
> state of BMS in the RCW (as most Freescale boards do),
> you can put a 'good' version of U-Boot at say the
> high-boot location, and the test version at the low-boot.
> If the low-boot version doesn't boot, power-down, flip the
> BMS toggle switch, power-up and boot-high, reflash to
> the next low-boot test version, and continue.
> 
> I personally haven't tried the trick, but it sounded
> like a nice idea.

That works great.  It saved my a$$ there more than once.  :-/  (The 
Freescale eval boards generally support this - very handy.)

> Low-boot is the only sane method for booting, since
> high-boot sticks the bootloader 8MB into your 32MB/64MB/etc
> Flash ... I mean who uses 8MB Flash these days ... :)
> 
> Cheers,
> Dave

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Jerry Van Baren]

Kumar Gala wrote:
> 
> On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote:
> 
>> Kumar Gala wrote:
>>> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
>>>> In message 
>>>> <[EMAIL PROTECTED]>  you wrote:
>>>>> Added the 'fdtcmd' environment variable as a way to provide 'fdt'  
>>>>> commands
>>>>> that the user can supply to manipulate the device tree after  
>>>>> ft_board_setup()
>>>>> and before the tree is handled to the kernel.
>>>> Where exactly is the needed, i. e. which spoecific situation  do  you
>>>> have  in  mind  where  this function cannot be implemented as part of
>>>> either a "preboot" or a standard "bootcmd" command sequence?
>>> The situation is if we are fixing up or adding properties or nodes 
>>> via  the ft_board_setup() how do I go about modifying that before 
>>> the  device tree is handed to the kernel.
>>> An example would be if we start adding the i2c node via code in 
>>> u-boot  and after we have done that we want to add a frequency 
>>> property at  runtime w/o changing the u-boot code.
>>> - k
>>
>> My original way long ago initial cut didn't do the board and /chosen 
>> fixups as part of the bootm execution.  My original intent was that we 
>> would run "fdt chosen" and "fdt bd" and whatever else was necessary 
>> before running "bootm", including addressing Kumar's need.
>>
>> Unfortunately, it would have also broken backwards compatibility and 
>> so the concept was sacrificed for backwards compatibility.  :-/
>>
>> Is there a better way of doing this... perhaps have a flag that says 
>> if "fdt chosen" and/or "fdt bd" is run, don't re-run it as part of 
>> bootm? Maybe have an env variable that suppressed the calling of "fdt 
>> chosen" and "fdt bd" in bootm ("nofdtfixup"?)?  Still ugly, but it 
>> would maintain backwards compatibility but also allow us finer grained 
>> control of when "fdt chosen" and "fdt bd" (add "fdt cpu"?) is run and 
>> allow our users to wedge additional fdt stuff in the boot sequence.
> 
> Is that really any better than having the ability to "execute" an 
> environment variable that has 'fdt' commands in it as part of bootm?
> 
> - k

I don't like it that bootm is calling out to all sorts of functions that 
could better be scripted.  It complicates the bootm code (badly!), it 
prevents users from doing clever things (because it hard codes the calls 
and sequences of the calls to loosely related functions), and it 
violates the unix principle of doing only one thing and doing it well 
(bootm code is one big ugly awkward swissarmyknife[tm] tool).

Best regards,
gvb

P.S. This battle was probably lost many years ago, but it still makes me 
feel better to pound the desk and shout.  Oh-oh, people are looking...

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Increasing U-Boot partition size

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>> Your choices are 0xfff0 and zero, based on the BMS (Boot Memory 
>>> Space) bit of the low reset control word.
>>>
>>> -Scott
>> ...and of the two options, I recommend 0xfff0 ("boot high").  Note 
>> that the start of u-boot is 0xfff0 but the reset vector itself is 
>> 0xfff00100 (or 0x0100 for "boot low").  The first 0x100 bytes has 
>> the u-boot signature and version info.
> 
> I disagree.
> 
> High-booting systems are a PITA. You always lose a full  megabyte  at
> the  end of the flash of which usually only 256 kB or less are needed
> for U-Boot, wasting 0.75 MB.
> 
> Also, systems with varying number of flash banks and/or flash sizes
> are not really straightforward to handle.
> 
> Low-booting is much, much saner.
> 
> Best regards,
> 
> Wolfgang Denk

Arrr, my insanity.  Wolfgang is correct, of course.

Sorry,
gvb


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Increasing U-Boot partition size

[Jerry Van Baren]

Scott Wood wrote:
> Jatin Sharma wrote:
>> I have Freescale MPC8347. Can you confirm that I have to have U-Boot
>> start at 0xFFF0?
> 
> Your choices are 0xfff0 and zero, based on the BMS (Boot Memory 
> Space) bit of the low reset control word.
> 
> -Scott

...and of the two options, I recommend 0xfff0 ("boot high").  Note 
that the start of u-boot is 0xfff0 but the reset vector itself is 
0xfff00100 (or 0x0100 for "boot low").  The first 0x100 bytes has 
the u-boot signature and version info.

HTH,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot

[Jerry Van Baren]

Kumar Gala wrote:
> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
> 
>> In message <[EMAIL PROTECTED]>  
>> you wrote:
>>> Added the 'fdtcmd' environment variable as a way to provide 'fdt'  
>>> commands
>>> that the user can supply to manipulate the device tree after  
>>> ft_board_setup()
>>> and before the tree is handled to the kernel.
>> Where exactly is the needed, i. e. which spoecific situation  do  you
>> have  in  mind  where  this function cannot be implemented as part of
>> either a "preboot" or a standard "bootcmd" command sequence?
> 
> The situation is if we are fixing up or adding properties or nodes via  
> the ft_board_setup() how do I go about modifying that before the  
> device tree is handed to the kernel.
> 
> An example would be if we start adding the i2c node via code in u-boot  
> and after we have done that we want to add a frequency property at  
> runtime w/o changing the u-boot code.
> 
> - k

My original way long ago initial cut didn't do the board and /chosen 
fixups as part of the bootm execution.  My original intent was that we 
would run "fdt chosen" and "fdt bd" and whatever else was necessary 
before running "bootm", including addressing Kumar's need.

Unfortunately, it would have also broken backwards compatibility and so 
the concept was sacrificed for backwards compatibility.  :-/

Is there a better way of doing this... perhaps have a flag that says if 
"fdt chosen" and/or "fdt bd" is run, don't re-run it as part of bootm? 
Maybe have an env variable that suppressed the calling of "fdt chosen" 
and "fdt bd" in bootm ("nofdtfixup"?)?  Still ugly, but it would 
maintain backwards compatibility but also allow us finer grained control 
of when "fdt chosen" and "fdt bd" (add "fdt cpu"?) is run and allow our 
users to wedge additional fdt stuff in the boot sequence.

gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command

[Jerry Van Baren]

David Gibson wrote:
> On Sat, Aug 02, 2008 at 08:51:54PM -0400, Jerry Van Baren wrote:

[snip]

>> I've CC:ed David Gibson in case he has some advice - the concept is to  
>> indicate a dereference of /aliases nodes so that us lazy engineers don't  
>> have to cut'n'paste the whole long path from the alias.  Kumar  
>> originally proposed to do it automagically and I countered proposing  
>> using "*" to indicate the next path name should be looked up in /aliases  
>> and the result used instead (i.e. dereferenced).  Discussion thread:
>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/43575/focus=44941>
> 
> No, I really don't think using this "dereference" character is a good
> idea.  If you're going to expand aliases, you should do it as real OF
> does - see section 4.3 of IEEE1275.  Essentially it's the *lack* of a
> leading '/' character that triggers alias expansion.  So you could use
> e.g.
>   /[EMAIL PROTECTED]/[EMAIL PROTECTED]
> or
>   soc/[EMAIL PROTECTED]
> or
>   ethernet0

Ahh, I didn't read far enough.  The algorithm in section 4.3 is much 
better thought out than either of our proposals.

[snip]

> If you're interepreting them in one place, you should probably
> interpret them everywhwere and have a single "resolve pathname"
> function.

Yes.

> In fact, I should quite possibly put such a function into libfdt.

That would be very useful.  :-)

Thanks,
gvb


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Marvell db64460 / mpc7447 migration from U-boot 1.1.2 to U-boot 1.3.3

[Jerry Van Baren]

Stephen Horton wrote:
> Hello folks,
> 
> In a current work project, I have inherited a compactPCI board that has 
> an mpc7447/7448 powerpc processor as well as a Marvell system 
> controller, model mv64462 (stripped down mv64460). The board has a 
> somewhat working U-boot 1.1.2 loader (using db64460 platform) and a 
> Gentoo Linux port (kernel version 2.6.9 built using arch/ppc) running on 
> it from long ago and a company far far away. It looks like the company 
> contracted with Timesys to pull together the initial software. To 
> prepare for an upcoming deployment, I would like to bring the OS 
> up-to-date on this board with a newer kernel (targeting 2.6.24r3), as 
> well as migrate U-boot to 1.3.3 and fix some bugs along the way.
> 
> My Linux kernel work is going very well, but with U-boot I’m stuck. I 
> have what I believe ‘may’ be the working U-boot 1.1.2 source code, and I 
> have migrated all of the board’s customizations from various files into 
> the 1.3.3 stream; however, I can get –no- console output on the serial 
> port. I don’t have access to a remote debugger, so I’m working in the 
> dark and have no idea how far, if at all, the initialization is 
> progressing. Does anyone know of any tips to help me along?  Any changes 
> in mpsc device initialization from 1.1.2 to 1.3.3 that could help me? 
> Any clues?
> 
> Regards,
> 
> Stephen

Suggestion: first make sure your 1.1.2 source is working (fix as 
necessary) before trying to pull it forward.

How are you reloading flash when you brick the board?  What capabilities 
does your hardware have for debugging - can it halt the processor and 
show the registers?

Are there any LEDs you can blink when you get to a certain place in the 
code, and then move the blinkin' successfully further in the init 
sequence?  Can you hook a logic analyzer or scope to a bus and do a bus 
write to indicate progress?

Is is a memory size / organization issue?  Despite Wolfgang's best 
efforts, u-boot keeps growing.  :-/  If you are lucky, the problem is 
simply that a memory section outgrew its allocation.

Good luck,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Power.org open-firmware/device trees ePAPR reference

[Jerry Van Baren]

David Hawkins wrote:
> Hi,
> 
> I just received an email from Power.org referencing this document:
> 
> http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
> 
>   "The ePAPR is loosely related to the IEEE 1275 Open Firmware
>standard—IEEE Standard for Boot (Initialization Configuration)
>Firmware: Core Requirements and Practices."
> 
> It looks to have a nice description of device trees.
> 
> I see lots of familiar U-Boot developer names in the acknowledgments,
> so I imagine U-Boot is probably compliant with this specification
> already.
> 
> Looks like a useful document to reference somewhere on the Denx
> documentation area.
> 
> Cheers,
> Dave

Hi Dave,

Thanks for the pointer.  I have a collection of useful IEEE-1275 / FDT 
pointers on my custodian page and added your reference to the collection:


Some of these references may deserve a higher visibility location.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] using a flat device tree to drive u-boot config

[Jerry Van Baren]

Scott Wood wrote:
> Ben Warren wrote:
>> On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <[EMAIL PROTECTED]> wrote:
>>> I find a device tree much easier to figure out than a tangled mess of header
>>> files, #defines, and #ifdefs...
>> In many ways, yes.  But are you an average Joe or a Linux kernel 
>> propellerhead?
> 
> Is u-boot work normally done by average Joes, and does the average Joe 
> really find the preprocessor mess more intuitive than a "propellerhead"?
> 
> While we're at it, let's re-write u-boot in Visual Basic. :-)

NO, No, no!  In FORTH. :-P

> -Scott

gvb %;-)

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command

[Jerry Van Baren]

Kumar Gala wrote:
> 
> On Jul 9, 2008, at 12:02 PM, Jerry Van Baren wrote:
> 
>>
>> Thinking out loud... we could define the syntax that a leading "*" 
>> indicates the first part of the path is a dereference of /aliases.
>>
>> Assuming
>>  /aliases/soc = /[EMAIL PROTECTED]
>>  /aliases/ethernet0 = /[EMAIL PROTECTED]/.../enet0
>> then
>>  print *soc/enet0
>> and
>>  print *ethernet0
>> would both work and print the right thing.  You *would* have to know 
>> that the first element of the path is an /aliases dereference.  Your 
>> original patch did not require that piece of knowledge (but silently 
>> and automagically, which makes me nervous).
> 
> did we come to resolution on this?  I'd like to see this in 1.3.5.
> 
> - k

Hi Kumar,

I think we have basic resolution - I would like to see it in 1.3.5 too. 
  I haven't pushed on this, waiting for 1.3.5 window to open (or some 
free time, whichever comes last).

I've CC:ed David Gibson in case he has some advice - the concept is to 
indicate a dereference of /aliases nodes so that us lazy engineers don't 
have to cut'n'paste the whole long path from the alias.  Kumar 
originally proposed to do it automagically and I countered proposing 
using "*" to indicate the next path name should be looked up in /aliases 
and the result used instead (i.e. dereferenced).  Discussion thread:
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/43575/focus=44941>

Looking at the ieee1275 doc
<http://playground.sun.com/pub/1275/coredoc/1275-1994/1275.ps.gz>
it looks like "*" will work for a dereference delimiter as it is not 
listed as one of the permitted punctuation characters in a node name. 
Quoting 3.2.1.1 Node names:
--
The driver name field is a sequence of between one and 31 letters, 
digits, and punctuation characters from the set ", . _ + - ". Uppercase 
and lowercase characters are distinct.
--

We do have a problem with property names, where "*" _is_ a legal name 
component.  Quoting 3.2.2.1.1 Property names:
--
The property name is a human-readable text string consisting of one to 
thirty-one printable characters. Property names shall not contain 
uppercase characters or the characters "/", "\", ":", "[", "]" and "@".
--
Note that "*" is not proscribed, making it a legal character in a 
property name.

Having noted that, I'm willing to take the risk and use "*" for the 
"alias dereference" separator.

Looking back at the original patch, Kumar's original patch only did the 
/aliases dereference for the "fdt print" command.  I'm thinking more 
general purpose: being able to dereference /aliases in all "fdt" 
commands.  This seems helpful for the "fdt set" command, for instance. 
Whether this is reasonable to implement remains to be seen...

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Changing u-boot relocation scheme

[Jerry Van Baren]

Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 11:21:12 -0400
> Jerry Van Baren <[EMAIL PROTECTED]> wrote:
> 
>> The relocation information is in the ELF file until and unless we remove 
>> it.  "Normal" ELF executables retain that relocation information... that 
>> is exactly what the "L" (it) is for.  The linux loader (elf loader) 
>> loads an executable into an arbitrary memory location and relocates it 
>> by fixing up addresses based on the relocation table.
> 
> You're mixing two different relocation tables. Statically linked
> executables (like u-boot) normally don't have any relocation
> information in them after they are fully linked. Dynamically linked
> executables, position-independent executables (PIE) and shared
> libraries have dynamic relocations which are not only in the ELF file,
> but in a loadable segment so that they can be accessed at run time.
> 
> The relocation information from the .o files are not preserved in the
> final executable unless you specify the --emit-relocs flags, which
> exists purely for debugging purposes. The relocations used by the
> dynamic loader come from an entirely different, simpler set of
> relocation types which are normally not found in .o files.
> 
> Why do you think objdump has two different options for dumping normal
> (-r) vs. dynamic (-R) relocations?
> 
> And no, Linux ELF executables can _not_ be loaded into an arbitrary
> memory location unless they are PIE. Shared libraries, however, can be
> loaded at arbitrary memory locations, though things like pre-linking
> might make it more optimal to try to place them at the same address
> everywhere.

Thanks for the explanation.  I have not worked at this level with 
executable formats in a long time.  My experience harks back to Z80 
formats (I forgot which, but post-CPM which loaded into a fixed address) 
  and .COM and .EXE formats which have rudimentary relocation fixup 
information so that they could be run at arbitrary addresses.  Those are 
non-virtual (or didn't use the MMU) formats, equivalent to your PIE 
reference.

> Ok, I'll stop the chest-beating now. But please stop trying to tell
> people that adding a powerpc-specific option (which nobody seems to
> know how really works) to the command line will work on any other
> architectures than powerpc.

Fair enough.

> Haavard

Discovering my banner is labeled "obsolete",
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Changing u-boot relocation scheme

[Jerry Van Baren]

kenneth johansson wrote:
> On Fri, 2008-07-25 at 17:23 +0200, Haavard Skinnemoen wrote:

[snip]

>> There will obviously be a fair amount of arch-specific code required to
>> make the actual relocation work though.
> 
> So the gain of using dynamic relocation is that we have fever relocation
> types to implement and objcopy is not going to strip away the relocation
> section as it do for non dynamic relocs. 
> 
> still the code to actually do the relocation is architecture dependent
> and non existing. At least for powerpc we have a much easier option of
> having gcc generate a fixup table. 

EVERYTHING *already* exists, we just aren't using it right.  That is 
what the elf loader does in a "normal" system.  Grant did it on the 
PowerPC architecture - look at the archives, he didn't write new code 
for this, it's already in there.

Here is the reversion back to the old way:
   
If you un-revert it (re-revert it?), you will have what Grant did.  For 
some set of PowerPC platforms, it Just Works[tm].  For other 
architectures and platforms, start from this and make it work.

Note the list of changed files - no source file changes in it:
  board/cogent/u-boot.lds |1 +
  board/hymod/u-boot.lds  |1 +
  board/mousse/u-boot.lds |1 +
  board/rsdproto/u-boot.lds   |1 +
  cpu/mpc512x/config.mk   |2 +-
  cpu/mpc5xx/config.mk|2 +-
  cpu/mpc5xx/u-boot.lds   |1 +
  cpu/mpc5xxx/config.mk   |2 +-
  cpu/mpc5xxx/u-boot-customlayout.lds |1 +
  cpu/mpc5xxx/u-boot.lds  |1 +
  cpu/mpc8220/config.mk   |2 +-
  cpu/mpc8220/u-boot.lds  |1 +
  cpu/mpc824x/config.mk   |2 +-
  cpu/mpc824x/u-boot.lds  |1 +
  cpu/mpc8260/config.mk   |2 +-
  cpu/mpc8260/u-boot.lds  |1 +
  cpu/mpc83xx/config.mk   |2 +-
  cpu/mpc83xx/u-boot.lds  |1 +
  include/common.h|8 
  19 files changed, 18 insertions(+), 15 deletions(-)

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Changing u-boot relocation scheme

[Jerry Van Baren]

vb wrote:
> On Fri, Jul 25, 2008 at 7:33 AM, kenneth johansson <[EMAIL PROTECTED]> wrote:
> 
>> here is a patch to generate dynamic relocations in the elf file. What is
>> the next step? objcopy -j .rela.dyn -O binary  u-boot dyn_reloc_table ??
>>
>> 
>> --- config.mk
>> +++ config.mk
>> @@ -215,7 +215,8 @@
>>
>>  AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
>>
>> -LDFLAGS += -Bstatic -T $(LDSCRIPT) $(PLATFORM_LDFLAGS)
>> +#LDFLAGS += -Bstatic -T $(LDSCRIPT) $(PLATFORM_LDFLAGS)
>> +LDFLAGS += -Bstatic -shared -T $(LDSCRIPT) $(PLATFORM_LDFLAGS)
>>  ifneq ($(TEXT_BASE),)
>>  LDFLAGS += -Ttext $(TEXT_BASE)
>>  endif
>>
> 
> Interesting, but after this step we have a file which can't be
> converted to a runnable binary without resolving the relocation
> information first, right? This is not good then, as we need something
> to run from reset.
> 
> I think this discussion covers much more ground than needed: certainly
> the problem of running the same executable at different addresses has
> been solved many times over, for different architectures and file
> formats. The thing is that unless we want the loader be part of u-boot
> we can not use those standard solutions. And I don't think we want,
> because it would be an unnecessary complication.
> 
> I still believe that my original suggestion of determining the
> addresses of pointers to relocate by comparing to stripped binaries is
> the simplest way to do it across architectures. Apparently the same
> could be achieved by using -mrelocatable on powerPc, this still
> remains to  be seen.
> 
> cheers,
> /vb

Well, to circle back around, Grant Likely *DID* ELF-based relocation 
*SUCCESSFULLY* so it *CAN* be done the right way.  He just didn't have a 
full recipe that worked over all "popular" compiler versions, didn't 
have the time to identify /why/ it didn't work on certain compiler 
versions, and didn't try to run on architectures that he didn't have 
physical access to.

Doing the relocation the right way will be much more future-proof than 
doing it a different wrong way.

The relocation information is in the ELF file until and unless we remove 
it.  "Normal" ELF executables retain that relocation information... that 
is exactly what the "L" (it) is for.  The linux loader (elf loader) 
loads an executable into an arbitrary memory location and relocates it 
by fixing up addresses based on the relocation table.

To reiterate, Grant had a proof-of-concept (well beyond p-o-c, actually) 
that did everything you are asking for, but the right way and even in 
the same architecture that you are interested in.  Despite the chest 
beating that has gone on in this thread about supporting other 
architectures, I'm 100% positive that they are also supported with fixup 
tables, if only we knew enough to use them.

You can stand on the *shoulders* of giants or their toes.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Jerry Van Baren]

Jerry Van Baren wrote:
> So you should be able to use
>0xE080..0xE0FF - 2nd "copy" of the first bank
>0xE100..0xE17F - 1st "copy" of the second bank
> you will double your available consecutive memory.  You can do the same 
> thing with the third and fourth banks of memory, but you will still have 
> a gap between the first pair and second pair.  This will reduce your 
> four fragments / three holes to two fragments / one hole.  Solved half 
> your problem anyway.
>0xE480..0xE4FF - 2nd "copy" of the first bank
>0xE500..0xE57F - 1st "copy" of the second bank
doh!^^

s/first/third/
s/second/fourth/

Sorry for the cut&paste error.
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Jerry Van Baren]

Stuart Wood wrote:
> Wolfgamg
> 
> 
>> What has the MMU to do with it?
>>
>> Just program your memory controller such that the 4 banks form a
>> contiguous region.
> 
> The memory controller unfortunatly can  not map the SDRAM banks as
> contiguous region. That IS the main problem. For the SDRAM I'm using
> It ends up giving me region sizes of 8MBytes.
> 
> U-Boot runs in the first region, and we down load into the second region.
> If the down load is larger than the region size it gets corrupted.

IOW, your hardware sucks.  Not the first time *that* has happened.

> So the thought is to enable the MMU to do the address translation.
> Or is there another way to handle this?

No.

Wait, there is half a way.  If your SDRAM banks are not fully decoded 
(and they most likely are *not*), if you use the address last "copy" of 
the first bank and the first "copy" of the second bank, you will have 
two bank's worth of contiguous memory.

> It appears to happen when the image size becomes larger then a bank of
>> SDRAM. I've got a 32 MByte SDRAM
>> that appears as 4 banks of 8 MBytes.
>> 
>> The system is using u-boot 1.1.3 and we will move to 1.3.3 soon.
>> The memory regions are broken up like this.
>> 
>> 0xE000 - 0xE07F
>> 0xE100 - 0xE17F
>> 0xE400 - 0xE47F
>> 0xE500 - 0xE57F

So you should be able to use
   0xE080..0xE0FF - 2nd "copy" of the first bank
   0xE100..0xE17F - 1st "copy" of the second bank
you will double your available consecutive memory.  You can do the same 
thing with the third and fourth banks of memory, but you will still have 
a gap between the first pair and second pair.  This will reduce your 
four fragments / three holes to two fragments / one hole.  Solved half 
your problem anyway.
   0xE480..0xE4FF - 2nd "copy" of the first bank
   0xE500..0xE57F - 1st "copy" of the second bank

HTH,
gvb


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Changing u-boot relocation scheme

[Jerry Van Baren]

vb wrote:
> Wolfgang, thank you for your reply, let me try to explain myself a bit 
> clearer:
> 
> On Wed, Jul 23, 2008 at 8:18 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
>> In message <[EMAIL PROTECTED]> you wrote:
>>
>>> some companies). If these added modules were not written in position
>>> independent manner (namely, using structures with multiple stage
>>> indirect pointers interleaved with data), the effort to make these
>>> modules work in u-boot is very exhausting.
>> I don't understand what you mean. Either you link statically with the
>> U-Boot image, or you use standalone programs. In both situations no
>> such problem as described by you exists.
> 
> we talk here about modules statically linked into the u-boot image.
> Allow me to illustrate the problem I am trying to solve. Consider
> adding this code to a u-boot source file on a ppc460gt platform:
> 
> vvv
> 87a88,105
>> int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
>>
>> int  (*pf)(struct cmd_tbl_s *, int, int, char *[]) = do_ptrt;
>>
>> int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
>> {
>>   printf ("pointer is %p\n", pf);
>>   printf ("function is %p\n", do_ptrt);
>>   return 0;
>> }
>>
>> U_BOOT_CMD(
>>   ptrt, CFG_MAXARGS, 1,   do_ptrt,
>>   "ptrt\n",
>>   ""
>> );
>>
> ^^^
> 
> And this is what happens when this command is invoked:
> 
> vvv
> => ptrt
> pointer is fffb2754
> function is 0ffb7754
> 
> 
> So, the value of 'pf' is equal to the address of do_ptrt() *before*
> relocation. The fact that there is a GOT and a sophisticated linker
> script did not prevent this from happening.

OK, now I'm curious: what happens if you make the pf() pointer constant? 
  This will (should) change it from an initialized variable in the .data 
section to a constant in the .rodata section.  I'm wondering if the 
.rodata section gets relocation information where the .data section doesn't.

int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);

const int (*pf)(struct cmd_tbl_s *, int, int, char *[]) = do_ptrt;

int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
   printf ("pointer is %p\n", pf);
   printf ("function is %p\n", do_ptrt);
   return 0;
}

Thanks,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Changing u-boot relocation scheme

[Jerry Van Baren]

vb wrote:
> Wolfgang,
> 
> I wonder if you would consider (and accept a patch) changing the
> u-boot architecture as described below.
> 
> As we all are well aware u-boot is a great software package which
> speeds up bringing up new hardware immensely, its popularity is
> obviously growing very fast. One thing which (IMO anyway) slows down
> its acceptance is the way it handles relocating of itself into an
> arbitrary DRAM area. (Arbitrary meaning that it depends on many
> factors and the exact address can't be assigned ahead of time).

One thing (IMO anyway) that allows u-boot to Just Work[tm] is that it 
relocates itself to the best location available, automatically adjusting 
to the probed memory configuration.

There.  Fixed that.  ;-)

> While this relocation is seamless for u-boot in its released form, it
> becomes a pain each time a module needs to be added (not necessarily
> for following release to the Open Source community, for instance used
> for inhouse installations which include tens of thousand units for
> some companies). If these added modules were not written in position
> independent manner (namely, using structures with multiple stage
> indirect pointers interleaved with data), the effort to make these
> modules work in u-boot is very exhausting.

You lost me here.

What is a module?
How does a it relate to u-boot?
Why does it need to be relocated?
Why isn't it written in position independent manner?
How is your relocation methodology going to fixup a module's data 
structures?
What pointers are in your data structures?  Why do they need to be 
relocated?

> Here is the suggested alternative. I will talk about recent PPC
> platforms, but it could be done very similar for most of the other
> platforms I believe.
> 
> In general the PPC u-boot image consists of three parts: the bulk of
> code and data, the startup page (the top 4k mapped out of reset), and
> the reset vector (the top four bytes in the address space). The bulk
> is usually aligned at a certain address matching the bootprom size,
> and there is a gap between the bulk and the startup page.
> 
> Now, let's say we link and purge the bulk section twice, once locating
> it at offset 0 and once at the normal u-boot TEXT_BASE, building two
> binary images (not including the top 4k in both cases).
> 
> Then we compare the two images and identify all locations which are
> different. All these locations are 4 byte aligned, and all differ by
> the same amount - equal TEXT_BASE. Now we can build a table of offsets
> which need to be changed when the program is moved into a different
> location, include this table in the resulting image between the bulk
> and the startup page, and use this table when relocating code.


Gcc supports "proper" relocation, if only we knew how to make it work 
for all "reasonable" versions of gcc (and Grant's conclusion is that 
many versions of gcc in use today do *not* support the relocation).
   

Grant Likely created a patch that did this in the 1.3.0 timeframe, but 
ended up reverting it due to toolset problems - it was a patch before 
its time.

To read up on the history, follow this search:


> Basically, this implements a poor man's loader, and it will be
> sufficient in case the image we are dealing with is a flat binary
> (which is of course the case with u-boot). This will allow to add any
> code to u-boot without much worries about being able to relocate it
> properly. We would do away with storing certain structures in certain
> sections, dealing with GOT, etc.
> 
> I made some experiments, and this seems feasible, this could be done
> as a local customization, but I would much prefer to release it to the
> u-boot community and make it part of mainline - will you consider such
> a patch?
> 
> Thank you for reading this far, please let me know what you think,

On one hand, your proposal sounds fairly simple and independent of the 
gcc version.  The primary cost would be extra build steps
1) Link at TEXT_BASE
2) Link at address 0
3) Binary diff the two to find addresses that need relocation
4) Rebuild with the diff table (compile the diff table and relink)

On the other hand, the skeptic in me says it ain't that easy.  Go ahead, 
prove me wrong.  ;-)

> Vadim

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.

Re: [U-Boot-Users] Need Some Help

[Jerry Van Baren]

[EMAIL PROTECTED] wrote:
> Please do not use HTML on this mailing list.  All
> messages to this list must be in plain text.
> 
> Mondesir, Alshine wrote:
> 
>> My latest endeavor has me cross compiling a stand
>> alone application for > MPC8548 PPC for a U-Boot
>> Based target.  There is no Operating System to
>> run on the target to speak of, just my application.
>> I'm building the application in Code Warrior
>> using an 8548_init.S hardware initialization file.
>  
>> 1) My first thought was that this should be as
>> simple as using the .ELF image that codewarrior
>> produces, right?  So I build a simple hello_world
>> application and sent it down to my target.  U-Boot
>> recognizes it as an ELF image, sets up the
>> segments, and tries to run it!  But then low and
>> behold, the U-Boot flash image comes up again. 
>  
>> => bootelf 40
> 
>> => bootm 40
>  
>> How do I go about exporting my code warrior
>> application so that I can run it as stand-alone
>> on a U-Boot based target?  Thanks so much
> 
> I suspect that your application is using a device
> or resource that neither U-Boot nor your
> application have properly initialized.
> 
> What is your display device for your hello_world
> application?  Where is this device initialized?
> 
> Sincerely,
> 
> Ken Fuchs

...and are you (Alshine) loading your application in a valid location? 
I see 0x2000 and following.  I suspect those locations are used by 
your version of u-boot.  You probably want to link your test app at 
0x40 or somewhere up high like that.

>> => bootelf 40
>> Loading .init @ 0x2000 (972 bytes)

[snip]

>> ## Starting application at 0x2044 ...

gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] u-boot.bin

[Jerry Van Baren]

Fundu wrote:
>> Please bottom post.
> will do.
> 
>> Run "${CROSS_COMPILE}strip -s u-boot
>> -o=u-boot.strip" and you will see 
>> that u-boot.strip is approximately the same size as
>> u-boot.bin.  NOTE: I 
>> would *NOT* recommend stripping the ELF file unless you
>> have a real need to do so.
> that make it much clear thx. is the stripped out file of any use ? it won't 
> work with gdb ? so then under what situation would you want to strip.
> 
> TIA.

The two reasons I can think of for stripping elf files...
1) Make it smaller if you have to transport it on/over a size sensitive 
medium (floppy, modem).  Maybe also to cram more on a limited size 
embedded file system.

2) Most proprietary packages strip their packages to try to prevent 
their "valuable intellectual property" from leaking out.  (This has 
limited real value, but PHBs think it is a very valuable thing to do.)

To reiterate, there is almost no reason to strip elf files.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] u-boot.bin

[Jerry Van Baren]

Fundu wrote:
> Thanks gvb!
> that definitely makes sense. 
> 
> i see the u-boot.elf file is a lot bigger than the u-boot.bin. why is that ?

Hi Fundu,

Please bottom post.

Run "${CROSS_COMPILE}objdump -h u-boot" and you will see that there are 
lots of non-loaded segments (symbols, etc.) in there.

Run "${CROSS_COMPILE}strip -s u-boot -o=u-boot.strip" and you will see 
that u-boot.strip is approximately the same size as u-boot.bin.  NOTE: I 
would *NOT* recommend stripping the ELF file unless you have a real need 
to do so.

gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] u-boot.bin

[Jerry Van Baren]

Fundu wrote:
> ok, looks like 0x27051956 is uboot magic number (from start.S)
> why is the CFG_MONITOR_BASE points to the magic number ? 

Because that is the definition.  From the file README:

- CFG_MONITOR_BASE:
 Physical start address of boot monitor code (set by
 make config files to be same as the text base address
 (TEXT_BASE) used when linking) - same as
 CFG_FLASH_BASE when booting from flash.

> --- On Tue, 7/22/08, Fundu <[EMAIL PROTECTED]> wrote:
> 
>> From: Fundu <[EMAIL PROTECTED]>
>> Subject: [U-Boot-Users] u-boot.bin
>> To: u-boot-users@lists.sourceforge.net
>> Date: Tuesday, July 22, 2008, 3:44 PM
>> i'm working on taishan ppc440gx.
>>
>> now here's what i noticed. snippet of u-boot.bin opened
>> with a hex editor.
>>
>>
>> fffb : 27051956 552d426f 6f742031 2e322e30 

This is the start, it should be (and probably is) at fffc.  Why does 
your dump start at fff*b* (one byte before where it should)?

>> '..VU-Boot 1.2.0
>> fffc000f : 20284a75 6c203232 20323030 38202d20   (Jul 22
>> 2008 -
>> fffc001f : 31343a31 363a3037 2900  
>> 14:16:07)...
>> fffc002f :     
>> 
>> fffc003f :     
>> 
>>
>> and my u-boot.map  
>>
>> .text   0xfffc0x2aa9c
>>  cpu/ppc4xx/start.o(.text)
>>  .text  0xfffc 0x2704 cpu/ppc4xx/start.o

Note the start address is fffc, not fffb.

[snip]

>> couple of question.
>> 1) this line ".text   0xfffc   
>> 0x2aa9c" from u-boot.map 
>> which means .text starts at 0xfffc and with length of
>> 0x2aa9c. right ?

Yes.

>> then looking at the hex dump of u-boot.bin looks like
>> there's some data right after first word (U-Boot
>> 1.2.0...) 
>> what am i missing ? 

The first word is the u-boot magic number, followed by the u-boot build 
information (text).

>> 2) when ppc440gx reset it has 0xfffc in its program
>> counter, the instr at this location is a branch instr.
>> right ?

Yes.  See cpu/ppc4xx/start.S

>> b) this branch should go to TEXT_BASE which is 0xfffc
>> in my case. 

No, it jumps to the start of some CPU initialization code in the last 4K 
page (when released from reset, only the last 4K page is mapped).  That 
code maps the rest of memory and jumps to the traditional PPC startup 
code.  0xfffc isn't involved.

>> and that location contains 0x05195655. which looks like a
>> "rlwimix" instr. (rotate left word immediate then
>> mask insert). does this look start of monitor ?

No, it looks like operator error.

>> Any insight on how the bootldr starts up would be
>> appreciated too.
>> thanks ! 

HTH,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Trouble with Make Command

[Jerry Van Baren]

Rugunda, Solo wrote:
> Hi
> 
> I am fairly new to Uboot. I am having trouble running the "make" command
> from the "u-boot-1.1.4/tools #" prompt.
> 
> When I do a make, this is the error I get
> 
> Makefile:108: /config.mk: No such file or directory
> make: *** No rule to make target `/config.mk'.  Stop.

Hi Solo,

Run make in your top level directory, "u-boot-1.1.4", not in the tools 
subdirectory.

By the way, the prompt "#" indicates you are running make as root.  You 
should not need to.  Running as root for anything that doesn't need root 
access (essentially everything but host configuration) is a poor 
practice and discouraged.

HTH,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation

[Jerry Van Baren]

Timur Tabi wrote:
> David Hawkins wrote:
>> Hi Timur,

[snip]

>> If you need I2C speed tracking code, why not just re-read
>> the I2C controller registers, and determine the speed from
>> there? That is independent of relocation.
> 
> I suppose we could do that.

That won't work for soft (bit-banged) I2C.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

[Jerry Van Baren]

David Hawkins wrote:
> Hi Jerry,

[snip]

>> Most processors available today have debug registers.  If the 
>> processor used on a given target has a debug register set and the 
>> registers can be set to trigger on a write to a range, that would give 
>> you an exception. You would not necessarily have to handle the 
>> exception "properly", simply enter a spin loop so that the processor 
>> stops in a known state with enough information to identify the root 
>> cause.
> 
> Haven't seen that type of register on the MPC8349EA, it might
> exist, I just didn't look :)

"e300 Power Architecture Core Family Reference Manual, Rev. 2" Chapter 
10 "Debug Features" Section 10.1.3 "Data Address Breakpoint Registers 
(DABR, DABR2)"

Unfortunately, it looks like it only handles exact address matches, not 
a range.

The e500 core appears to be able to do ranges.  Unfortunately, this is 
of limited value since it is an unusual capability.  (Chapter "8.4 Book 
E Debug Events" section 8.4.2.4 "Data Address Compare (DAC) Mode")

[snip]

> Yep, a repeatable bug can be traced using a debugger. The
> hard part is making the bug repeatable.
> 
>> It would be nice to have a technique to trap these pre-relocation 
>> bugs. They don't happen often, but they *do* happen and they are hard 
>> to find (until they bite you and then they are hard to identify).
>>
>> What are the capabilities of your debugger?  Can you set a hardware 
>> breakpoint range on your flash and have it trigger on start up?  If 
>> so, we should add it to our FAQ and add the technique to our toolbox.
> 
> Its a BDI2000.
> 
> I don't recall seeing a trap on range feature.

Nope, looks like it is beyond the capability of the e300 core.  The BDI 
hardware breakpoints are just playing with the core's debug registers, 
so it isn't going to do any better than the core (and the software 
breakpoints require software assist, so they don't work when running in 
flash).

> This is a tricky one to put in the FAQ, as it really shouldn't
> happen :)
> 
> We managed to get pretty far with the debugger; we eventually
> found the address at which things died, however, the debugger
> wasn't able to give us an explanation. It was the logic analyzer
> on the flash/local-bus that showed the reason. So perhaps thats
> something that can be added to the FAQ. Let me know if you
> want something coherent, and I can write a 'logic analyzer tricks
> and tips' section for the FAQ.
> 
> Cheers,
> Dave

One really good trick is how to hook a logic analyzer to those 
itty-bitty balls on the processor.  Back when I was a boy, processors 
had 40 legs and no balls.  :-D  You must have a board with a logic 
analyzer connector.

Thanks,
gvb


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

[Jerry Van Baren]

David Hawkins wrote:
> Hi all,
> 
> We recently debugged a problem where a Flash write on
> MPC8349E and MPC8349EA processor boards was accidentally
> occurring during board initialization.
> 
> Under the right conditions, the write appears to put
> the flash into a command-mode, rather than read-data mode,
> and further reads from the flash return invalid data
> (as far as the processor is concerned). The write was
> coming from drivers code that we had not introduced,
> and depends on the address of the flash write which
> changes depending on the section sizes, so the cause
> of the bug was not initially obvious.

Thanks for the complete write up on your findings.  That was very helpful.

[snip]

> Writes to boot Flash could be disabled early on in the
> boot sequence, and then enabled again after relocation.
> This would protect against writes to the boot flash.
> 
> The downside of this change, would be that flash writes
> would not work if you stopped the processor between the
> time writes were disabled, and then enabled.

[snip]

> The fix will also not expose the accidental introduction
> of flash writes in the future, it'll just stop those
> writes from having any effect.

IOW, it simply hides the bug.  :-(

> It would be nicer to generate an exception if a write to
> flash occurs during the period before relocation, at least
> that way the introduction of an accidental flash write
> would be detected immediately. I could have a look at
> the 83xx MMU settings during that time and see if there
> was an alternative solution using that.

Using the MMU that early is going to be some work and has risks of other 
mysterious lockups when done wrong.  MMUs are different for different 
processors and, often, within different branches of the same family of 
processors.  This will add to the complexity.

MMU == complexity == risk.  :-(

Most processors available today have debug registers.  If the processor 
used on a given target has a debug register set and the registers can be 
set to trigger on a write to a range, that would give you an exception. 
  You would not necessarily have to handle the exception "properly", 
simply enter a spin loop so that the processor stops in a known state 
with enough information to identify the root cause.

Pros:
* Get an exception identifying a bad bug occurrence rather than silent 
pass (mostly) or failure (mysteriously).

Cons:
* More complexity == risk
* Debug capabilities, like the MMU, are different for different 
processors and families.  This could be complex and could turn into an 
ifdefhell.
* It may be easier and better to use a debugger (e.g. BDI-3000) to 
control the hardware breakpoint registers.  A debugger may get unhappy 
or may simply undo our doings if we directly control the hardware 
breakpoint registers.

> The 440EP manual indicates that a protect error would
> occur if a write is attempted to a read-only bank.
> 
> I figured I'd gauge if there was any interest in adding
> this feature before looking into it further.

It would be nice to have a technique to trap these pre-relocation bugs. 
  They don't happen often, but they *do* happen and they are hard to 
find (until they bite you and then they are hard to identify).

What are the capabilities of your debugger?  Can you set a hardware 
breakpoint range on your flash and have it trigger on start up?  If so, 
we should add it to our FAQ and add the technique to our toolbox.

> Cheers,
> Dave

Thanks,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] question of "flattened device tree"

[Jerry Van Baren]

[EMAIL PROTECTED] wrote:
> hello,
> 
> under U-Boot, some board configuration files contain "flattened device 
> tree"
> elements, such as "OF_CPU", "OF_STDOUT_PATH", etc. while in booting 
> Linux, a
> separate file dtb is used.
> 
> if both are used, what's the relationship about them?
> 
> thanks.
> 
> -lxg

Processor and board are???

I believe your question is indicating that you are using an older 
version of u-boot with "CONFIG_OF_FLAT_TREE" defined.  This has been 
deprecated and has been removed in the latest u-boot.  The current code 
no longer defines or uses "OF_CPU", "OF_STDOUT_PATH", etc.

Please update your u-boot and switch to using CONFIG_OF_LIBFDT and dts 
files from a recent version of the linux kernel source (or edit your dts 
file to pick up the improvements shown in the linux version).

Don't forget to include an /aliases node pointing to the proper hardware 
configurations.  The u-boot code now uses that to find the fdt pieces 
for its fixups rather than "OF_CPU", "OF_STDOUT_PATH", etc.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] HELP, trying to remove complier warnings

[Jerry Van Baren]

Kumar Gala wrote:
> On Jul 10, 2008, at 1:43 PM, Scott Wood wrote:
> 
>> Wolfgang Denk wrote:
>>> In message <[EMAIL PROTECTED] 
 you wrote:
 Try adding -fno-strict-aliasing
>>> No, we don't want to hush up compiler warnings, we want to fix the
>>> problems instead.
>> It's not silencing a warning (if it were, it'd be a -W flag); it's
>> disabling an incompatible optimization.
> 
> Did we come to any resolution on this?
> 
> I'm with Scott in that trying to re-write the code isn't worth the  
> pain and its reasonable to disable the optimization until someone is  
> willing to update to a newer dlmalloc which might not have the issue.
> 
> - k

FWIIW, +1 for me too.

gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Freescale MPC8349EMDS hang on boot

[Jerry Van Baren]

Ira Snyder wrote:
> On Fri, Jul 18, 2008 at 02:17:48PM -0400, Jerry Van Baren wrote:
>>> I checked include/configs/MPC8349EMDS.h and didn't find any obvious
>>> config options for disabling the cache.
>>>
>>> The hang happens before the relocation to RAM. The "I2C:" line where it
>>> hangs is printed before the relocation. There are "SPI:" and "DRAM:"
>>> lines that should also be printed before the relocation to RAM.
>> I2C is used to read the SPD configuration off the memory DIMM. 
>> Interesting, but I'm not sure what it is telling us...
>>
> 
> Yep. Note that there is an access to the BCSR registers that I added.
> Removing the access makes the problem go away, even with the .data
> section 32 byte aligned. There shouldn't be any problem reading the
> BCSR registers, though.
> 
> What I'm getting at is maybe it is neither of these that is the real
> problem, it could just be that the BCSR access plus the alignment of the
> .data section triggers the real problem, whatever it may be.

Hmmm, interesting point: reading the BCSR is implicated.  Are you sure 
that reading the BCSR is safe *at this point in time*?  Have you 
confirmed CS1 is configured this early in the boot sequence?

[snip]

>> What is your build host running (OS, distribution)?  Any chance of doing 
>> a clean OS and ELDK installation on a different machine?
>>
> 
> I'm running Ubuntu Hardy. My test machine here has a completely clean,
> not updated installation of Hardy on it as well, I could try installing
> and building with that. I also have access to a CentOS 4 machine that I
> could install ELDK-4.2 onto. It has ELDK-4.1 already installed. I'll try
> ELDK-4.2 on the CentOS machine as soon as the install media is finished
> downloading, which will take a while. It might be Monday before I have a
> chance to get back to you with the results.

That is so low a probability that I wouldn't bother unless I were really 
desperate.

> Thanks again,
> Ira

Have a good weekend,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Freescale MPC8349EMDS hang on boot

[Jerry Van Baren]

Ira Snyder wrote:
> On Fri, Jul 18, 2008 at 07:59:36AM -0400, Jerry Van Baren wrote:
>> Hi Ira,
>>
>> This is a long shot, but could there be a problem with the DDR SDRAM  
>> and/or its initialization?
> 
> I suppose it could be, but this seems unlikely. Why would aligning the
> start of a section to a 32 byte boundary make the ram initialization fail,
> but any other alignment works?

Not the initialization itself, but an incorrect initialization can cause 
funny things to happen when the SDRAM is used.  As you note here and 
below, doesn't look like this is the problem.

The thought was that your moving memory contents around ("misaligning" 
it) causes changes to the bus cycles which make it work or not.

> Also, I have two nearly identical boards here. One is a MPC8349EMDS
> Rev-3.1 (it's an EA board, using DDR2) and another, older MPC8349EMDS
> Rev-1.1 (it's an E board, using plain DDR). Both fail in exactly the
> same way.

That is useful to know (I think).  It doesn't sound like a hardware problem.

>> Are you using a factory-provided DIMM?  What  
>> if you try a different one (preferably a different brand/size)?
>>
> 
> Yes, both boards have the factory provided memory. There are different
> DIMMs on each of the two boards. The DDR is Micron, the DDR2 I don't
> recognize the manufacturer for. Hopefully they're different enough.
> Unfortunately, I don't have any more memory that fits these boards.

Good enough, especially since you are using DIMMs that are provided with 
the boards and thus (should be) used around the world without problems.

>> I'm not familiar with the board configuration, I presume instruction  
>> caches are enabled.  Are data caches enabled too?  What happens if you  
>> disable cache(s)?
> 
> Yes, both caches are enabled. I'm not really sure how to turn them off
> without effecting the bootup sequence. It looks like they are assumed to
> enabled during parts of startup in cpu/mpc83xx/start.S

That is the trick using data cache for the stack before the SDRAM is 
initialized, not really what I was referring to.  My question probably 
is immaterial because your failure occurs before (at?) SDRAM 
initialization, before the caches would be enabled as real caches.

> I checked include/configs/MPC8349EMDS.h and didn't find any obvious
> config options for disabling the cache.
> 
> The hang happens before the relocation to RAM. The "I2C:" line where it
> hangs is printed before the relocation. There are "SPI:" and "DRAM:"
> lines that should also be printed before the relocation to RAM.

I2C is used to read the SPD configuration off the memory DIMM. 
Interesting, but I'm not sure what it is telling us...

>> Best regards,
>> gvb
> 
> As some added information, I tried building with ELDK-4.1 (rather than
> ELDK-4.2, which I have been using) and was unable to get the lockup.
> However, in the past I did get several similar lockups using ELDK-4.1,
> which went away when I upgraded to ELDK-4.2 (the problems prompted the
> upgrade). Unfortunately, I just thought the problem was my code at the
> time, and so I did not keep any images around.
> 
> Thanks for your help,
> Ira

Weird behavior that changes with different builds and/or shifting things 
in memory quite often are build tools or memory problems.  It doesn't 
sound like you are having memory problems, but your build tools sound 
suspicious.  There are lots of people running ELDK4.1 and 4.2 (myself 
included - on debian, cross compiling for a MPC8360) so that probably 
isn't the problem.

What is your build host running (OS, distribution)?  Any chance of doing 
a clean OS and ELDK installation on a different machine?

Running low on theories,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Freescale MPC8349EMDS hang on boot

[Jerry Van Baren]

Ira Snyder wrote:
> On Thu, Jul 17, 2008 at 04:54:53PM -0500, Kim Phillips wrote:
>> On Wed, 16 Jul 2008 15:28:21 -0700
>> Ira Snyder <[EMAIL PROTECTED]> wrote:
>>
>>> During the development, I noticed that adding and removing certain
>>> pieces of debugging code (which did not change any program state) caused
>>> the board to hang on boot, like so:

[snip]

> 
> Hello Kim,
> 
> Thanks for looking at this problem so quickly. I'll try reverting the
> patch as soon as I'm done writing this email and post the results here.
> 
> I spent this afternoon trying to narrow down the problem exhibited by
> the changes in my earlier email. I managed to narrow it down to the
> .data section's start address being a multiple of 32 bytes, and the
> bcsr code in checkboard().
> 
> I have attached a patch which causes my board to hang on boot in exactly
> the same way that the earlier patch does. Removing the line from the
> linker script makes the board boot perfectly, as long as the .data
> section's start address is not on a 32 byte boundary by coincidence.
> 
> Ira
> 
> 
> 
> diff --git a/board/freescale/mpc8349emds/mpc8349emds.c 
> b/board/freescale/mpc8349emds/mpc8349emds.c
> index 9a312c3..f4792a9 100644
> --- a/board/freescale/mpc8349emds/mpc8349emds.c
> +++ b/board/freescale/mpc8349emds/mpc8349emds.c
> @@ -165,6 +165,13 @@ int fixed_sdram(void)
>  
>  int checkboard (void)
>  {
> + volatile immap_t *immr = (immap_t *)CFG_IMMR;
> + volatile u8 *bcsr = (u8 *)CFG_BCSR;
> + int in_pci_slot;
> +
> + /* in a pci slot or standalone */
> + in_pci_slot = (bcsr[10] & 0x80) ? 1 : 0;
> +
>   puts("Board: Freescale MPC8349EMDS\n");
>   return 0;
>  }
> diff --git a/cpu/mpc83xx/u-boot.lds b/cpu/mpc83xx/u-boot.lds
> index 99ad675..f605eab 100644
> --- a/cpu/mpc83xx/u-boot.lds
> +++ b/cpu/mpc83xx/u-boot.lds
> @@ -79,6 +79,7 @@ SECTIONS
>__got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >> 2;
>__fixup_entries = (. - _FIXUP_TABLE_) >> 2;
>  
> +  . = ALIGN(32);
>.data:
>{
>  *(.data)

Hi Ira,

This is a long shot, but could there be a problem with the DDR SDRAM 
and/or its initialization?  Are you using a factory-provided DIMM?  What 
if you try a different one (preferably a different brand/size)?

I'm not familiar with the board configuration, I presume instruction 
caches are enabled.  Are data caches enabled too?  What happens if you 
disable cache(s)?

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] v1.3.4-rc1 released

[Jerry Van Baren]

Jerry Van Baren wrote:
> Wolfgang Denk wrote:
>> In message <[EMAIL PROTECTED]> you wrote:
>>> Didnt know this ... so we must change something in common/main.c :-(
>> Yes.
>>
>>> Whats with something like this?
>> Looks way too complicated to me. What do you think about the PATCH /
>> RFC I posted yesterday?
>>
>> Best regards,
>>
>> Wolfgang Denk
> 
> I presume you considered and discarded using a special #define (e.g. 
> CONFIG_AUTOBOOT_PROMPT_0) for the no value case.  It only hurts our 
> #ifdef hellcount a little and changes our "touch" count from  to 5 
> (4 if I fix sacsng).
> 
> diff --git a/common/main.c b/common/main.c
> index 79ad291..09e6033 100644
> --- a/common/main.c
> +++ b/common/main.c
> @@ -115,8 +115,10 @@ static __inline__ int abortboot(int bootdelay)
>  u_int presskey_max = 0;
>  u_int i;
> 
> -#  ifdef CONFIG_AUTOBOOT_PROMPT
> +#  if defined(CONFIG_AUTOBOOT_PROMPT)
>  printf(CONFIG_AUTOBOOT_PROMPT, bootdelay);
> +#  elif defined(CONFIG_AUTOBOOT_PROMPT_0)
> +   c

Arrr, missed the  key and other sorts of evil
+   printf(CONFIG_AUTOBOOT_PROMPT_0);

>   #  endif
> 
>   #  ifdef CONFIG_AUTOBOOT_DELAY_STR

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] v1.3.4-rc1 released

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> Didnt know this ... so we must change something in common/main.c :-(
> 
> Yes.
> 
>> Whats with something like this?
> 
> Looks way too complicated to me. What do you think about the PATCH /
> RFC I posted yesterday?
> 
> Best regards,
> 
> Wolfgang Denk

I presume you considered and discarded using a special #define (e.g. 
CONFIG_AUTOBOOT_PROMPT_0) for the no value case.  It only hurts our 
#ifdef hellcount a little and changes our "touch" count from  to 5 
(4 if I fix sacsng).

diff --git a/common/main.c b/common/main.c
index 79ad291..09e6033 100644
--- a/common/main.c
+++ b/common/main.c
@@ -115,8 +115,10 @@ static __inline__ int abortboot(int bootdelay)
 u_int presskey_max = 0;
 u_int i;

-#  ifdef CONFIG_AUTOBOOT_PROMPT
+#  if defined(CONFIG_AUTOBOOT_PROMPT)
 printf(CONFIG_AUTOBOOT_PROMPT, bootdelay);
+#  elif defined(CONFIG_AUTOBOOT_PROMPT_0)
+   c
  #  endif

  #  ifdef CONFIG_AUTOBOOT_DELAY_STR

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH - RFC] Fix printf() format problems with configurable prompts

[Jerry Van Baren]

Wolfgang Denk wrote:
> U-Boot allows for configurable prompt strings using the
> CONFIG_AUTOBOOT_PROMPT resp. CONFIG_MENUPROMPT definitions. So far,
> the assumption was that any such user defined problts would contain
> exactly one "%d" format specifier. But some boards did not.
> 
> To allow for flexible boot prompts without adding too complex code we
> now allow to specify the whole list of printf() arguments in the user
> definition. This is powerful, but requires a responsible user who
> really understands what he is doing, as he needs to know for exanple

s/exanple/example/

> which variables are available in the respective context.
> 
> Signed-off-by: Wolfgang Denk <[EMAIL PROTECTED]>
> ---
> 
> This is an attempt to fix the
>   main.c:215: warning: too many arguments for format
>   main.c:119: warning: too many arguments for format
> warnings we got for some boards.
> 
> I am not exactly happy about providing the complete list of printf()
> arguments in a #define, but this seems to be the solution that (1)
> requires the least changes to the code and (2) does not add memory
> footprint (like we would need if we added some format parsing
> function).
> 
> Comments / critique welcome.

Hi Wolfgang,

It seems a lot simpler to reformat the couple of boards that don't have 
%d in their string to add the "in %d seconds" type phrase.

The downside (risk!) of this is that some companies may be unhappy if 
their boot prompt changes (ripple effect through manuals, humans trained 
to see certain strings, programs expect-ing certain strings, etc.).

I'm OK with doing this to sacsng and Heiko Schocher is OK with sc3 (he 
published a patch this afternoon).  That leaves only three boards at 
risk: hymod, motionpro, and voiceblue.

$ grep -A 1 CONFIG_AUTOBOOT_PROMPT include/configs/*.h |less | grep -v 
'%d' | grep -v -- '--' | grep -v CONFIG_AUTOBOOT_DELAY_STR | grep -v 
CONFIG_AUTOBOOT_STOP_STR

include/configs/hymod.h-"press 
 to stop\n"

include/configs/motionpro.h-"press 
\"\" to stop\n"

include/configs/sacsng.h:#define CONFIG_AUTOBOOT_PROMPT "Autobooting...\n"

include/configs/sc3.h:#define CONFIG_AUTOBOOT_PROMPT"\nSC3 - 
booting... stop with ENTER\n"

include/configs/voiceblue.h:#define CONFIG_AUTOBOOT_PROMPT 
"\nVoiceBlue Enterprise - booting...\n"


Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] v1.3.4-rc1 released

[Jerry Van Baren]

Wolfgang Denk wrote:
> Hello,
> 
> the first release candidate for v1.3.4 is out.

:-)

> Well,  actually  it's more some mile stone than a real release
> candidate as we still have a couple  of  issues  that  need  to  be
> fixed before we can consider a release:

:-(

> - sacsng:
>   main.c: In function 'abortboot':
>   main.c:119: warning: too many arguments for format
> 
>   Here we need some clever idea to deal with configurable command prompts.
>   I will look into this asap.

I'll look at this tonight.  Maybe the code is being more clever than it 
should be or maybe I was simply stupider than I should have been.

Best regards,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] Round the serial port clock divisor value returned by calc_divisor()

[Jerry Van Baren]

Hugo Villeneuve wrote:
> Round the serial port clock divisor value returned by
> calc_divisor()
> 
> Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]>

Acked-by: Gerald Van Baren <[EMAIL PROTECTED]>

(Hopefully this stops Wolfgang's pain!)

> 
> ---
> 
>  drivers/serial/serial.c |   12 +++-
>  1 files changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
> index 4ccaee2..8bbfcf9 100644
> --- a/drivers/serial/serial.c
> +++ b/drivers/serial/serial.c
> @@ -124,8 +124,6 @@ static NS16550_t serial_ports[4] = {
>  
>  static int calc_divisor (NS16550_t port)
>  {
> - uint32_t clk_divisor;
> -
>  #ifdef CONFIG_OMAP1510
>   /* If can't cleanly clock 115200 set div to 1 */
>   if ((CFG_NS16550_CLK == 1200) && (gd->baudrate == 115200)) {
> @@ -149,15 +147,11 @@ static int calc_divisor (NS16550_t port)
>  
>   /* Compute divisor value. Normally, we should simply return:
>*   CFG_NS16550_CLK) / MODE_X_DIV / gd->baudrate
> -  * but we need to round that value by adding 0.5 (2/4).
> +  * but we need to round that value by adding 0.5.
>* Rounding is especially important at high baud rates.
>*/
> - clk_divisor = (((4 * CFG_NS16550_CLK) /
> - (MODE_X_DIV * gd->baudrate)) + 2) / 4;
> -
> - debug("NS16550 clock divisor = %d\n", clk_divisor);
> -
> - return clk_divisor;
> + return (CFG_NS16550_CLK + (gd->baudrate * (MODE_X_DIV / 2))) /
> + (MODE_X_DIV * gd->baudrate);
>  }
>  
>  #if !defined(CONFIG_SERIAL_MULTI)
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> U-Boot-Users mailing list
> U-Boot-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] Request for pointers: EP8548A v1.1

[Jerry Van Baren]

Hi Andy, Embedded Planet,

I have some Embedded Planet/Freescale EP8548A v1.1 boards that I need to 
pull both u-boot and linux forward into the fdt era.  The LTIB-based 
delivery is ancient (1.1.4 hacked), I would like to get u-boot to the 
tip of git and linux somewhere close to the tip.  I'm assuming linux 
won't be difficult once I get u-boot pulled forward.

Apparently EP didn't submit their u-boot EP8548A board port back into 
the master repo (git.denx.de). :-(  I've done some googling for sources 
and repositories and came up pretty dry.  The git repos on 
 are pretty old.  Like the main u-boot 
repo, the fsl u-boot one doesn't have the ep8548 board config.

I have the ltib u-boot source ("U-Boot 1.1.4 EKB-22022006"), but a 
fast-forward instead of a slow-forward would be nice to have.  Has 
anybody worked with the EP8548A to pull it forward into the Modern Era?

Thanks,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH v2] Round the serial port clock divisor value returned by calc_divisor()

[Jerry Van Baren]

This formula is better at avoiding integer overflow.

Signed-off-by: Gerald Van Baren <[EMAIL PROTECTED]>
---

This is my latest entry in the baud rate rounding dual.  Since it doesn't
multiply the master BRG clock but instead adds the baud rate scaled by
1/2 the clock multiplier, it should not overflow (for a master clock
right at the edge of overflowing itself, it still will overflow, but
that is pretty unlikely).

This compiles OK on the mpc7448hpc2.  I have only tested it on a
calculator.  I have NOT tested it on real hardware.

 drivers/serial/serial.c |   16 +---
 1 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index 4ccaee2..7f43540 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -124,7 +124,6 @@ static NS16550_t serial_ports[4] = {
 
 static int calc_divisor (NS16550_t port)
 {
-   uint32_t clk_divisor;
 
 #ifdef CONFIG_OMAP1510
/* If can't cleanly clock 115200 set div to 1 */
@@ -147,17 +146,12 @@ static int calc_divisor (NS16550_t port)
 #define MODE_X_DIV 16
 #endif
 
-   /* Compute divisor value. Normally, we should simply return:
-*   CFG_NS16550_CLK) / MODE_X_DIV / gd->baudrate
-* but we need to round that value by adding 0.5 (2/4).
-* Rounding is especially important at high baud rates.
+   /*
+* Compute divisor value, rounding it properly.  Rounding is
+* especially important at high baud rates.
 */
-   clk_divisor = (((4 * CFG_NS16550_CLK) /
-   (MODE_X_DIV * gd->baudrate)) + 2) / 4;
-
-   debug("NS16550 clock divisor = %d\n", clk_divisor);
-
-   return clk_divisor;
+   return (CFG_NS16550_CLK + (gd->baudrate * (MODE_X_DIV / 2))) /
+   (MODE_X_DIV * gd->baudrate);
 }
 
 #if !defined(CONFIG_SERIAL_MULTI)
-- 
1.5.6


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren]

Foreword:  As Wolfgang noted, Robin's emails apparently are being 
discarded by Sourceforge.  I'm dual-subscribed - home and work - and 
only received emails from Robin on the email that was directly addressed 
to me.

Robin Getz wrote:
> On Fri 11 Jul 2008 14:52, Jerry Van Baren pondered:
>> Ben Warren wrote:
>>> Robin Getz wrote:
>>>> I was trying out U-Boot 1.1.3 with a new(er) router netgear WGR614v6 - 
>>>> firmware version V2.0.19_1.0.19NA, on a Blackfin BF537-STAMP.
>>>>
>>>> http://kbserver.netgear.com/products/wgr614v6.asp
>>>>
>>>> and found that dhcp fails :( 
>>>> bfin> dhcp
>>>> BOOTP broadcast 1
>>>> BOOTP broadcast 2
>>>> BOOTP broadcast 3
>>>> BOOTP broadcast 4
>>>> BOOTP broadcast 5
>>>>
>>>> Retry count exceeded; starting again
>>>>
>>>> When turning on some more verbose debug messages (in the net driver & in 
> the 
>>>> network code, not all of which exists in U-Boot release or trunk), we can 
> see 
>>>> exactly what is going on...
>>>>
>>>> =
>> First DHCP request...
>>
>>>> bfin> dhcp
>>>> Eth_halt: ..
>>>> Eth_init: ..
>>>> BOOTP broadcast 1
>>>> setting transaction ID to 3268fe22
>>>> BFIN EMAC send: length = 343
>>>> BFIN EMAC rx: length = 552
>>>> packet received
>>>> packet received
>>>> Receive from protocol 0x800
>>>> Got IP
>>>> len=308, v=45
>>>> passing packet len= 280
>>>> DHCPHandler: got packet: (src=67, dst=68, len=280) state: 3
>>>> Filtering pkt = 0
>>>> DHCPHandler: got DHCP packet: (src=67, dst=68, len=280) state: 3
>>>> DHCP: state=SELECTING bp_file: ""
>>>> TRANSITIONING TO REQUESTING STATE
>>>> IP was: 0.0.0.0
>>>> IP now: 192.168.0.9
>> ...worked.
> 
> No - the DCHP server offered an address, When U-Boot does a DHCPREQUEST 
> (confirming it can have that address) it gets a DHCP NAK.

Right.  My confusion.

>>>> Bootfile:
>>>> DhcpSendRequestPkt: Sending DHCPREQUEST
>> Why is the second DHCP request being sent? 
> 
> This is not a 2nd DHCP request being sent. This is part of the DHCP protocol.

Right.  My confusion.

>> What is the second DHCP  
>> request asking for (sniff the net with wireshark). 
> 
> I can send you the wireshark file, but it is exactly as I described.
> 
> http://www.ietf.org/rfc/rfc1533.txt
> 
> Client sends DHCPDISCOVER
> server sends DHCPOFFER
> Client sends DHCPREQUEST
> Server sends ARP
> Client responds to ARP before it should
> Server sends DHCPNAK, because someone on the network is using the IP number 
> (and doesn't bother to check the MAC - and notice that is the machine that it 
> just gave the IP number to).
> Clients tosses the offer info (it did get NAKed), and starts over.

RFC-1533 is "DHCP Options and BOOTP Vendor Extensions".  RFC-2131 
"Dynamic Host Configuration Protocol" appears to be the right RFC.

The above sequence is somewhat odd and I would contend that it should be 
classified as a DHCP server bug.  Quoting from RFC-2131:

-
2.2 Dynamic allocation of network addresses

[snip]

As a consistency check, the allocating server SHOULD probe the reused 
address *before* allocating the address, e.g., with an ICMP echo 
request, and the client SHOULD probe the newly received address, e.g., 
with ARP.
-

My emphasis on the word *before*.  The Netgear is apparently probing 
*after* allocating the IP address and then *withdrawing* it's allocation 
when u-boot (improperly) responds to the ARP (the ARP is probably is a 
side effect of a ICMP probe).  This would explain why we have not been 
bitten by this bug before.

Of course u-boot needs to abide by Postel's Prescription: "Be liberal in 
what you accept, and conservative in what you send."
   <http://www.postel.org/postel.html>

IMHO, the Netgear WGR614v6 bug triggered a u-boot bug, for which we have 
a proposed/accepted (applied?) bug fix.

[snip]

Best regards,
gvb


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren]

Ben Warren wrote:
> Jerry Van Baren wrote:
>> Ben Warren wrote:
>>> Jerry Van Baren wrote:
>>>> Ben Warren wrote:
>>>>> Robin Getz wrote:
>>>>>> I was trying out U-Boot 1.1.3 with a new(er) router netgear 
>>>>>> WGR614v6 - firmware version V2.0.19_1.0.19NA, on a Blackfin 
>>>>>> BF537-STAMP.
>>>>>>
>>>>>> http://kbserver.netgear.com/products/wgr614v6.asp
>>>>>>
>>>>>> and found that dhcp fails :( 
>>>>
>>>> More correctly, the *second* DHCP request fails.
>>>>
>>>>>> bfin> dhcp
>>>>>> BOOTP broadcast 1
>>>>>> BOOTP broadcast 2
>>>>>> BOOTP broadcast 3
>>>>>> BOOTP broadcast 4
>>>>>> BOOTP broadcast 5
>>>>>>
>>>>>> Retry count exceeded; starting again
>>>>>>
>>>>>> When turning on some more verbose debug messages (in the net 
>>>>>> driver & in the network code, not all of which exists in U-Boot 
>>>>>> release or trunk), we can see exactly what is going on...
>>>>>>
>>>>>> =
>>>>
>>>> First DHCP request...
>>>>
>>>>>> bfin> dhcp
>>>>>> Eth_halt: ..
>>>>>> Eth_init: ..
>>>>>> BOOTP broadcast 1
>>>>>> setting transaction ID to 3268fe22
>>>>>> BFIN EMAC send: length = 343
>>>>>> BFIN EMAC rx: length = 552
>>>>>> packet received
>>>>>> packet received
>>>>>> Receive from protocol 0x800
>>>>>> Got IP
>>>>>> len=308, v=45
>>>>>> passing packet len= 280
>>>>>> DHCPHandler: got packet: (src=67, dst=68, len=280) state: 3
>>>>>> Filtering pkt = 0
>>>>>> DHCPHandler: got DHCP packet: (src=67, dst=68, len=280) state: 3
>>>>>> DHCP: state=SELECTING bp_file: ""
>>>>>> TRANSITIONING TO REQUESTING STATE
>>>>>> IP was: 0.0.0.0
>>>>>> IP now: 192.168.0.9
>>>>
>>>> ...worked.

Oops, wrong.

>>>>>> Bootfile:
>>>>>> DhcpSendRequestPkt: Sending DHCPREQUEST
>>>>
>>>> Why is the second DHCP request being sent?  What is the second DHCP 
>>>> request asking for (sniff the net with wireshark).  It should be 
>>>> asking for its current IP address (e.g. a renewal) if anything.
>>>>
>>> I think this is how it's supposed to work, but don't quote me...  
>>> Client starts in 'Discover' state, sending a broadcast looking for 
>>> servers.  One or more servers respond with proposals.  Client changes 
>>> to 'Request' state, and sends a request.  Server then has the option 
>>> of sending an ARP to see if the IP address is already taken and 
>>> eventually sends ACK or NAK.
>>
>> Yes, but that describes the *first* DHCP which *succeeded* (above).  
>> The target then initiates a second DHCP (presumably with the same MAC 
>> address and, I would presume/deduce with a lease renewal request 
>> rather than a "gimme a new IP" request) which the server(?) bungles.
>>
> No, what you show as the first one succeeding is the result of the 
> 'proposal' when the board enters the REQUESTING state (the call to 
> DhcpSendrequestPkt() is in the SELECTING state prior to entering the 
> REQUESTING state).  At least that's what the code tells me.

You are right, I should learn to read better.  Robin needs to use 
wireshark to see what the actual packet exchange is doing.  It looks 
like the DHCP server thinks that .9 is unallocated, the target is 
requesting that IP address since it had it before, and then a Bad 
Thing[tm] happens.  The question for Wireshark is: what exactly is the 
Bad Thing[tm] that happened?
* Why does the target (apparently) respond to an ARP with an IP address 
that it (presumably) *doesn't own yet*?
* Does the target think it still owns the lease to .9 but the DHCP 
server thinks it timed out?
* Did the target use a different MAC address than the first time, 
confusing the DHCP server?
* Is the DHCP server screwed up? (REBOOT the Netgear - does that fix it?)

[snip]

> I don't know, in this case he mentions it's a Linksys router.  I think 
> they either run Linux or VxWorks, but who knows now that Cisco owns them.

Oops, he clearly states "with a new(er) router netgear WGR614v6 - 
firmware version V2.0.19_1.0.19NA."  Googlebuzz seems to indicate it is 
running vxWorks.  REBOOT the Netgear - it might help.

gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren]

Ben Warren wrote:
> Jerry Van Baren wrote:
>> Ben Warren wrote:
>>> Robin Getz wrote:
>>>> I was trying out U-Boot 1.1.3 with a new(er) router netgear WGR614v6 
>>>> - firmware version V2.0.19_1.0.19NA, on a Blackfin BF537-STAMP.
>>>>
>>>> http://kbserver.netgear.com/products/wgr614v6.asp
>>>>
>>>> and found that dhcp fails :( 
>>
>> More correctly, the *second* DHCP request fails.
>>
>>>> bfin> dhcp
>>>> BOOTP broadcast 1
>>>> BOOTP broadcast 2
>>>> BOOTP broadcast 3
>>>> BOOTP broadcast 4
>>>> BOOTP broadcast 5
>>>>
>>>> Retry count exceeded; starting again
>>>>
>>>> When turning on some more verbose debug messages (in the net driver 
>>>> & in the network code, not all of which exists in U-Boot release or 
>>>> trunk), we can see exactly what is going on...
>>>>
>>>> =
>>
>> First DHCP request...
>>
>>>> bfin> dhcp
>>>> Eth_halt: ..
>>>> Eth_init: ..
>>>> BOOTP broadcast 1
>>>> setting transaction ID to 3268fe22
>>>> BFIN EMAC send: length = 343
>>>> BFIN EMAC rx: length = 552
>>>> packet received
>>>> packet received
>>>> Receive from protocol 0x800
>>>> Got IP
>>>> len=308, v=45
>>>> passing packet len= 280
>>>> DHCPHandler: got packet: (src=67, dst=68, len=280) state: 3
>>>> Filtering pkt = 0
>>>> DHCPHandler: got DHCP packet: (src=67, dst=68, len=280) state: 3
>>>> DHCP: state=SELECTING bp_file: ""
>>>> TRANSITIONING TO REQUESTING STATE
>>>> IP was: 0.0.0.0
>>>> IP now: 192.168.0.9
>>
>> ...worked.
>>
>>>> Bootfile:
>>>> DhcpSendRequestPkt: Sending DHCPREQUEST
>>
>> Why is the second DHCP request being sent?  What is the second DHCP 
>> request asking for (sniff the net with wireshark).  It should be 
>> asking for its current IP address (e.g. a renewal) if anything.
>>
> I think this is how it's supposed to work, but don't quote me...  Client 
> starts in 'Discover' state, sending a broadcast looking for servers.  
> One or more servers respond with proposals.  Client changes to 'Request' 
> state, and sends a request.  Server then has the option of sending an 
> ARP to see if the IP address is already taken and eventually sends ACK 
> or NAK.

Yes, but that describes the *first* DHCP which *succeeded* (above).  The 
target then initiates a second DHCP (presumably with the same MAC 
address and, I would presume/deduce with a lease renewal request rather 
than a "gimme a new IP" request) which the server(?) bungles.

> But why the NAK in this case?  The server should recognize that it 
> offered this IP address to the device with this MAC address.  Maybe it 
> is a timing thing like somebody saw a while ago with a Windows DHCP server.

Yes, Windows is my suspicion too, our emails probably crossed in the server.

> Fun stuff...
> 
> regards,
> Ben

Makes a slow day go faster.  :-)

gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren]

Jerry Van Baren wrote:
> Ben Warren wrote:
>> Robin Getz wrote:
>>> I was trying out U-Boot 1.1.3 with a new(er) router netgear WGR614v6 - 
>>> firmware version V2.0.19_1.0.19NA, on a Blackfin BF537-STAMP.
>>>
>>> http://kbserver.netgear.com/products/wgr614v6.asp
>>>
>>> and found that dhcp fails :( 

[snip]

Hi Robin,

Are you running Windows for your DHCP server?  Is this your problem 
"dhcp problems with Windows Server"?
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/24262/focus=24265>

gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6

[Jerry Van Baren]

Ben Warren wrote:
> Robin Getz wrote:
>> I was trying out U-Boot 1.1.3 with a new(er) router netgear WGR614v6 - 
>> firmware version V2.0.19_1.0.19NA, on a Blackfin BF537-STAMP.
>>
>> http://kbserver.netgear.com/products/wgr614v6.asp
>>
>> and found that dhcp fails :( 

More correctly, the *second* DHCP request fails.

>> bfin> dhcp
>> BOOTP broadcast 1
>> BOOTP broadcast 2
>> BOOTP broadcast 3
>> BOOTP broadcast 4
>> BOOTP broadcast 5
>>
>> Retry count exceeded; starting again
>>
>> When turning on some more verbose debug messages (in the net driver & in the 
>> network code, not all of which exists in U-Boot release or trunk), we can 
>> see 
>> exactly what is going on...
>>
>> =

First DHCP request...

>> bfin> dhcp
>> Eth_halt: ..
>> Eth_init: ..
>> BOOTP broadcast 1
>> setting transaction ID to 3268fe22
>> BFIN EMAC send: length = 343
>> BFIN EMAC rx: length = 552
>> packet received
>> packet received
>> Receive from protocol 0x800
>> Got IP
>> len=308, v=45
>> passing packet len= 280
>> DHCPHandler: got packet: (src=67, dst=68, len=280) state: 3
>> Filtering pkt = 0
>> DHCPHandler: got DHCP packet: (src=67, dst=68, len=280) state: 3
>> DHCP: state=SELECTING bp_file: ""
>> TRANSITIONING TO REQUESTING STATE
>> IP was: 0.0.0.0
>> IP now: 192.168.0.9

...worked.

>> Bootfile:
>> DhcpSendRequestPkt: Sending DHCPREQUEST

Why is the second DHCP request being sent?  What is the second DHCP 
request asking for (sniff the net with wireshark).  It should be asking 
for its current IP address (e.g. a renewal) if anything.

Hmmm, do you have more than one port connected to the same ethernet?  Is 
the second DHCP request using a different MAC address?  Did the DHCP 
server understand that the first DHCP operation succeeded?

What does your DHCP server have for client lease information?  I forgot 
where this is stashed, somewhere on /var for linux.  IIRC:
   find /var -name "*lease*"

>> Transmitting DHCPREQUEST packet: len = 343
>> BFIN EMAC send: length = 343
>> BFIN EMAC rx: length = 64
>> packet received
>> packet received
>> Receive from protocol 0x806
>> Got ARP
>> Got ARP REQUEST, for 192.168.0.9, return our MAC

This is standard protocol to check if anyone *else* is using the IP 
address that is about to be allocated.  The big question is why it is 
sending the .9 IP address to this target and then DHCPNAKing it when 
this target responds appropriately to the ARP.  What DHCP server are you 
using (linux/bind, Windows, ?other?).

>> BFIN EMAC send: length = 42
>> BFIN EMAC rx: length = 552
>> packet received
>> packet received
>> Receive from protocol 0x800
>> Got IP
>> len=272, v=45
>> passing packet len= 244
>> DHCPHandler: got packet: (src=67, dst=68, len=244) state: 4
>> Filtering pkt = 0
>> DHCPHandler: got DHCP packet: (src=67, dst=68, len=244) state: 4
>> DHCP State: REQUESTING
>> you just got DHCP NAKed
>>
>> ===
>>
>> What is happening, is that the server offers an IP number to U-Boot 
>> (192.168.0.9), U-Boot does a DHCPREQUEST, the server does a ARP asking 
>> for "who has 192.168.0.9", and U-Boot responds "I do" (This is the problem). 
>> The server then sends the requester (U-Boot) a DHCP NAK saying that someone 
>> else on the network is already using that address.
>>
>>   
> This seems goofy.  Have you tried your fix with other DHCP servers to 
> verify that it works?  If so, which ones?  I unfortunately can't try 
> anything right now but will play around a bit tonight.
> 
> regards,
> Ben


Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] Round the serial port clock divisor valuereturned by calc_divisor()

[Jerry Van Baren]

Hugo Villeneuve wrote:
> [EMAIL PROTECTED] wrote:
>> This formula is better at avoiding integer overflow.
> 
> This patch doesn´t round the value correctly.
> 
> Wolfgang, I will resubmit a new patch shortly today to fix the problem.
> 
> Hugo V.

Arrgh, you are right.  I know you solved it already, but for the record 
I oversimplified:
   (gd->baudrate / 2)
should have been:
   (gd->baudrate * (MODE_X_DIV / 2))

WRONG:
+   return (CFG_NS16550_CLK + (gd->baudrate / 2)) /
+   (MODE_X_DIV * gd->baudrate);

should have been
+   return (CFG_NS16550_CLK + (gd->baudrate * (MODE_X_DIV / 2))) /
+   (MODE_X_DIV * gd->baudrate);

Sorry,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] New Dummy I2C Driver

[Jerry Van Baren]

Ricardo Ribalda Delgado wrote:
> This driver provides access to a false i2c eeprom.
>  This false eeprom could be very useful in boards with
>  ddr2 memories and no i2c interfaces.
>  Using this driver the user can simulate the spd interface
>  of the ddr2 memory and use the ddr2 auto config

Hi Ricardo:

Nitpicking - "fake" would be a better word than "false" in this context. 
  I wouldn't reroll the patch for this, but if you reroll it for some 
other reason...

Thanks,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH] Round the serial port clock divisor value returned by calc_divisor()

[Jerry Van Baren]

This formula is better at avoiding integer overflow.

Signed-off-by: Gerald Van Baren <[EMAIL PROTECTED]>
---

(try 2)

The formula I proposed previously in this thread compiles OK.  I cannot
verify it is correct on real hardware, however.


Best regards,
gvb 

 drivers/serial/serial.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index 182ca2d..48579ae 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -150,7 +150,9 @@ static int calc_divisor (NS16550_t port)
 * but we need to round that value by adding 0.5 or 8/16.
 * Rounding is especially important at high baud rates.
 */
-   return (((16 * CFG_NS16550_CLK) / MODE_X_DIV / gd->baudrate) + 8) / 16;
+   return (CFG_NS16550_CLK + (gd->baudrate / 2)) /
+   (MODE_X_DIV * gd->baudrate);
+
 }
 
 #if !defined(CONFIG_SERIAL_MULTI)
-- 
1.5.6


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH V2] Round the serial port clock divisor value returned by calc_divisor()

[Jerry Van Baren]

Wolfgang Denk wrote:

In message <[EMAIL PROTECTED]> you wrote:

Round the serial port clock divisor value returned by
calc_divisor().

Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]>
Signed-off-by: John Roberts <[EMAIL PROTECTED]>

---

Rounding is important, especially when using high baud rates
values like 115200bps. When using the non-rounded value, some
boards will work and some won't.

 drivers/serial/serial.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index 76425d8..1192f07 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -144,8 +144,12 @@ static int calc_divisor (NS16550_t port)
 #else
 #define MODE_X_DIV 16
 #endif
-   return (CFG_NS16550_CLK / MODE_X_DIV / gd->baudrate);
 
+	/* Compute divisor value. Normally, we should simply return:

+*   CFG_NS16550_CLK) / MODE_X_DIV / gd->baudrate
+* but we need to round that value by adding 0.5 or 8/16.
+* Rounding is especially important at high baud rates. */
+   return (((16 * CFG_NS16550_CLK) / MODE_X_DIV / gd->baudrate) + 8) / 16;
 }


Your patch causes problems with some boards:

Configuring for SBC8540 board...
serial.c: In function 'calc_divisor':
serial.c:153: warning: integer overflow in expression
serial.c:153: warning: integer overflow in expression

Configuring for sbc8548 board...
serial.c: In function 'calc_divisor':
serial.c:153: warning: integer overflow in expression
serial.c:153: warning: integer overflow in expression


Do you have a quick fix, or shall I back out the patch?

Best regards,

Wolfgang Denk


The formula I proposed previously in this thread compiles OK.  I cannot 
verify it is correct on real hardware, however.



My apologies for providing the patch as an attachment.  I need to add 
the external editor plugin so I can use tbird for proper inline patches.


Best regards,
gvb

>From 97b1ea8273eec4e45df71e074e0790d39fd6536d Mon Sep 17 00:00:00 2001
From: Gerald Van Baren <[EMAIL PROTECTED]>
Date: Thu, 10 Jul 2008 19:44:28 -0400
Subject: [PATCH] Round the serial port clock divisor value returned by calc_divisor()

This algorithm is better at avoiding integer overflow.

Signed-off-by: Gerald Van Baren <[EMAIL PROTECTED]>
---
 drivers/serial/serial.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index 182ca2d..48579ae 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -150,7 +150,9 @@ static int calc_divisor (NS16550_t port)
 	 * but we need to round that value by adding 0.5 or 8/16.
 	 * Rounding is especially important at high baud rates.
 	 */
-	return (((16 * CFG_NS16550_CLK) / MODE_X_DIV / gd->baudrate) + 8) / 16;
+	return (CFG_NS16550_CLK + (gd->baudrate / 2)) /
+		(MODE_X_DIV * gd->baudrate);
+
 }
 
 #if !defined(CONFIG_SERIAL_MULTI)
-- 
1.5.6

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] I2C Dummy Driver

[Jerry Van Baren]

Ricardo Ribalda Delgado wrote:
> Signed-off-by: Ricardo Ribalda Delgado <[EMAIL PROTECTED]>
> ---
>  drivers/i2c/Makefile|1 +
>  drivers/i2c/dummy_i2c.c |   84 
> +++
>  2 files changed, 85 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/i2c/dummy_i2c.c
> 
> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
> index 534c015..322c822 100644
> --- a/drivers/i2c/Makefile
> +++ b/drivers/i2c/Makefile
> @@ -30,6 +30,7 @@ COBJS-y += omap1510_i2c.o
>  COBJS-y += omap24xx_i2c.o
>  COBJS-y += tsi108_i2c.o
>  COBJS-y += mxc_i2c.o
> +COBJS-y += dummy_i2c.o
>  
>  COBJS:= $(COBJS-y)
>  SRCS := $(COBJS:.o=.c)
> diff --git a/drivers/i2c/dummy_i2c.c b/drivers/i2c/dummy_i2c.c
> new file mode 100644
> index 000..04f6edb
> --- /dev/null
> +++ b/drivers/i2c/dummy_i2c.c
> @@ -0,0 +1,84 @@
> +/*   
> +(C) Copyright 2008
> +Ricado Ribalda, Universidad Autonoma de Madrid, 
> ricardo.ribaldauam.es , ricardo.ribaldagmail.com
> +This work has been supported by: Q-Technology  http://qtec.com/
> +
> +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 3 of the License, or

Ditto: GPLv3 is a problem because most of u-boot is licensed at GPLv2 
(possibly with an upgrade clause).  The problem is, GPLv3 is not 
backward compatible with GPLv2 because it adds restrictions.
   

If you wish to have this added to u-boot, you will need to change the 
licensing to GPLv2 (note that you can still keep the "any later" upgrade 
clause).

Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] -Support fot the ADT7640 Monitor chip

[Jerry Van Baren]

Ricardo Ribalda Delgado wrote:
> Signed-off-by: Ricardo Ribalda Delgado <[EMAIL PROTECTED]>
> ---
>  drivers/hwmon/Makefile  |1 +
>  drivers/hwmon/adt7460.c |   89 
> +++
>  drivers/hwmon/adt7460.h |   49 ++
>  include/dtt.h   |2 +-
>  4 files changed, 140 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/hwmon/adt7460.c
>  create mode 100644 drivers/hwmon/adt7460.h

[snip]

> +++ b/drivers/hwmon/adt7460.c
> @@ -0,0 +1,89 @@
> +/*   
> +(C) Copyright 2008
> +Ricado Ribalda, Universidad Autonoma de Madrid, 
> ricardo.ribaldauam.es , ricardo.ribaldagmail.com
> +This work has been supported by: Q-Technology  http://qtec.com/
> +
> +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 3 of the License, or

Hi Ricardo,

GPLv3 is a problem because most of u-boot is licensed at GPLv2 (possibly 
with an upgrade clause).  The problem is, GPLv3 is not backward 
compatible with GPLv2 because it adds restrictions.
   

If you wish to have this added to u-boot, you will need to change the 
licensing to GPLv2 (note that you can still keep the "any later" upgrade 
clause).

[snip]

> diff --git a/drivers/hwmon/adt7460.h b/drivers/hwmon/adt7460.h
> new file mode 100644
> index 000..48666f7
> --- /dev/null
> +++ b/drivers/hwmon/adt7460.h
> @@ -0,0 +1,49 @@
> +/*   
> +(C) Copyright 2008
> +Ricado Ribalda, Universidad Autonoma de Madrid, 
> ricardo.ribaldauam.es , ricardo.ribaldagmail.com
> +This work has been supported by: Q-Technology  http://qtec.com/
> +
> +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 3 of the License, or

Ditto.

Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Tftp command !!

[Jerry Van Baren]

Dear Amit,

Preliminary comment: Wolfgang is lashing out at stupid disclaimers, 
don't take it personally.  We all realize you didn't write the stupid 
disclaimer and cannot remove it.

Amit Kumar wrote:
> Dear Wolfgang,
> 
> Kindly read disclaimer properly or show to your lawyer.
> 
> "This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION
> intended solely for the use of the addressee(s)."

No it doesn't.  Your email was neither PRIVILEGED nor CONFIDENTIAL.

In the USofA, the term "privileged" as used in this context is a 
specific type of communications with a lawyer who is in a formal, legal 
way your (or your company's) representative.  This email clearly falls 
outside of that category.

Email is *never* CONFIDENTIAL if it is sent unencrypted on an 
unprotected network.  If it is encrypted and/or on a network internal to 
your company or over a secured VPN, you may have a reasonable 
expectation that the email is confidential within the bounds of your 
company and/or the limitations of the encryption.  This email clearly 
falls outside of that category.

Further, this email list is known to be archived by several servers 
(e.g. sourceforge, gmane, nabble) which are then indexed and cached by 
several search engines (e.g. google, yahoo, microsoft), not to mention 
snapshotted by archivers (e.g. the wayback engine).  Anyone now and in 
the future that has internet access can read it.  Obviously the list of 
addressees does not include everyone in the present and definitely not 
everyone in the future.

> You are not understanding the disclaimer at all. I am highly
> surprised. If your lawyer says that you are correct then as mentioned
> by you earlier you can report to management of my company.

If your company's legal disclaimer was actually written by a lawyer, and 
I strongly suspect it was not, that lawyer is either totally ignorant of 
the inherent characteristics of email or totally incompetent.  If the 
former, he should be educated on the inherent characteristics of email 
(see the analogy below).  If the latter, your company should replace him.

Rather than putting stupid useless disclaimers on non-PRIVILEGED, 
non-CONFIDENTIAL emails, a competent lawyer would/should give competent 
legal advice like DON'T EVER SEND PRIVILEGED OR CONFIDENTIAL INFORMATION 
over a service that has no expectations of privacy or confidentiality 
and "go medieval" on anybody that disregarded that advice.

As an analogy, sending PRIVILEGED AND CONFIDENTIAL information over 
email is *worse* than sending PRIVILEGED AND CONFIDENTIAL information 
written on a postcard and mailed out.  For a postcard, anybody between 
your outbox and the recipient's inbox can read the postcard, *most* of 
them *legally.*  This includes all of the mail handlers in your company, 
all of the mail handlers in the route from your company to the 
destination company (including any government security services, 
especially if it crosses a border) and potentially industrial spies (OK, 
*they* might be reading the postcard illegally, but legalities never 
stop a good spy).

> You are preventing people like us from sharing information on this
> esteemed mailing list for which I think you are the moderator.

Relax.  The information is still being shared.

> Regards,
> Amit

HTH,
gvb

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 10, 2008 4:37 PM
> To: Amit Kumar
> Cc: u-boot-users@lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Tftp command !!
> 
> In message <[EMAIL PROTECTED]> you wrote:
>>> If you had to make changes, this means that you are not running on the
>> very same hardware as trhe board configuration was made for.
> 
> I don't really believe that.
> 
>> [Amit]: If you look at my so called "changes" they don't make any 
>> difference. For example #defining one FLAG does not mean that there is 
>> change. README clearly mentions that if one wants particular piece of code 
>> to be enabled then #define it. Secondly,
>> there is increase in number of sectors.
> 
> But on the " hardware as trhe board configuration was made for", the
> number ofd sectors is OK. Which means you must have somewhat different
> hardware.
> 
> But if you don't believe me I can't help it. Feel free to find your
> own way.
> 
>> [Amit]: As per the disclaimer "If you are not the intended recipient and you 
>> copy, disclose, or distribute this e-mail or its contents to any other 
>> person" then such actions are unlawful. In this case, intended recipient is 
>> [EMAIL PROTECTED]
> 
>> e.net ... so I think there should not be any problem.
> 
> A mailing-list is not a person in the legal sense. Ask you lawyer. You
> are in trouble.
> 
> 
> 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: [EMAIL PROTECTED]
> 

Re: [U-Boot-Users] [PATCH v2] Remove [EMAIL PROTECTED] from MAINTAINERS

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> Would it be reasonable to add an optional tag "last known maintainer" 
>> for orphaned boards so someone can chase it without pawing through git 
>> history?  E.g.:
> 
> Excellent idea. I like it.
> 
>> +-
>> +
>> +Unknown / orphaned boards:
>> +
>> +Last known maintainer: Kyle Harris <[EMAIL PROTECTED]>
>> +cradle  xscale  
>> +ixdp425 xscale  
>> +lubbock xscale  
> 
> Let's rather have a third column:
> 
>   board   archLKM (if any)
>   cradle  xscale  Kyle Harris <[EMAIL PROTECTED]>
>   ...
> 
> etc.
> 
> 
> Best regards,
> 
> Wolfgang Denk

I'm OK with that too.  I actually did that first, but it linewrapped on 
me so I put the LKM on a separate line.  Ahh, I see you deleted a tab.

+1
gvb


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH v2] Remove [EMAIL PROTECTED] from MAINTAINERS

[Jerry Van Baren]

Haavard Skinnemoen wrote:
> Mail to [EMAIL PROTECTED] bounces because the user doesn't exist
> anymore. You can't be a maintainer without a valid e-mail address, so
> move all boards that used to be maintained by Kyle Harris to the
> "orphaned" list.
> 
> Currently, only PowerPC has a list of orphaned boards, so this patch
> creates one for ARM as well.
> 
> Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
> ---
> On Sun, 06 Jul 2008 00:32:01 +0200 Wolfgang Denk <[EMAIL PROTECTED]> wrote:
>> ... don't jusst delete the orphaned boards, but add them to the
>> "Unknown / orphaned" list.
> 
> I created a new Unknown/orphaned list for ARM since the existing one
> was located in the PowerPC section and only had PowerPC boards on it.
> Is that ok?
> 
>  MAINTAINERS |   14 --
>  1 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a3d70b1..6065e42 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -492,12 +492,6 @@ Kshitij Gupta <[EMAIL PROTECTED]>
>   omap1510inn ARM925T
>   omap1610inn ARM926EJS
>  
> -Kyle Harris <[EMAIL PROTECTED]>
> -
> - lubbock xscale
> - cradle  xscale
> - ixdp425 xscale
> -
>  Gary Jennejohn <[EMAIL PROTECTED]>
>  
>   smdk2400ARM920T
> @@ -591,6 +585,14 @@ Michael Schwingen <[EMAIL PROTECTED]>
>   actux3  xscale
>   actux4  xscale
>  
> +-
> +
> +Unknown / orphaned boards:
> +
> + cradle  xscale
> + ixdp425 xscale
> + lubbock xscale
> +
>  #
>  # x86 Systems:   
> #
>  ##

Would it be reasonable to add an optional tag "last known maintainer" 
for orphaned boards so someone can chase it without pawing through git 
history?  E.g.:

+-
+
+Unknown / orphaned boards:
+
+Last known maintainer: Kyle Harris <[EMAIL PROTECTED]>
+   cradle  xscale  
+   ixdp425 xscale  
+   lubbock xscale  
+

Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] add 'license' command to u-boot?commandline

[Jerry Van Baren]

Harald Welte wrote:
> On Thu, Jul 10, 2008 at 12:51:03PM +0200, Detlev Zundel wrote:
> 
>> Even though I'm an enthusiastic Emacs user, I have different reasons for
>> my vote.  As far as build dependencies go, I'd like to restrict this to
>> the LSB standard[1].  Xdd is not in there, so thats why I vote for the
>> small C program (unless we can adapt the script and use 'od').
> 
> I think sticking to LSB for build dependencies is a very reasonable choice.
> 
> I still don't think the small C program is that much of a problem:
> 
> 1) dependency tracking should ensure it is only built when the license
>feature is enabled by the board-level config.  I think this will be
>a minority case.
> 
> 2) compilation of native programs has already to be possible since there
>are other native tools such as mkimage built during the compilation
> 
> Cheers,

FWIIW, I agree with Detlev & Harald and withdraw my "bleah" objection.

Best regards,
gvb


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] add 'license' command to u-boot?commandline

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> Bleah on the small C program (nothing personal, just hate to add Yet 
>> Another Program to the build process).  How about using echo for prelim 
>> text (if necessary) and xxd to create the struct instead?  I like making 
>> maintenance Somebody Else's Problem (SEP[1])
>>
>> $ man xxd
> 
> How standard is xxd across distributions and operating systems?
> 
> Best regards,
> 
> Wolfgang Denk

In debian, it is (also) provided by the vim-common package.  It looks 
like vim (the project) is the origin of the command.  That was Harald's 
objection to using xxd.  Unfortunately, it appears to be a reasonable 
objection.

$ dpkg -S /usr/bin/xxd
vim-common: /usr/bin/xxd

IMHO, vim and xxd are essential programs so I'm OK with using xxd. 
OTOH, I understand some people actually prefer emacs and may have a 
problem with requiring vim to be installed.  ;-/

Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] u-boot, powerpc with device tree, initrd problem

[Jerry Van Baren]

Please don't top post.

John Linn wrote:
> One problem fixed, I had both CONFIG_OF_FLAT_TREE and CONFIG_OF_LIBFDT
> defined and that was causing the load of the device tree twice.

FWIIW, CONFIG_OF_FLAT_TREE has been removed as of this window.

> That didn't fix my initrd issue, but one less problem now.  The kernel
> is still not seeing the initrd image.
> 
> -- John

You might try loading your dtb and then use the "fdt chosen" command to 
create the /chosen node and the "fdt bd" command to run the 
board-specific fixups.  Do these as two separate steps and run "fdt 
print" in between to see what changes occur.

> => bootm 0x1c0 0x180 0x100
> ## Booting image at 01c0 ...
>Image Name:   Linux-2.6.26-rc8
>Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>Data Size:1536962 Bytes =  1.5 MB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
>Uncompressing Kernel Image ... OK
> ## Current stack ends at 0x0FEA5990 => set upper limit to 0x0080
> ## cmdline at 0x007FFF00 ... 0x007FFF3A
> bd address  = 0x0FEA5E80
> memstart= 0x
> memsize = 0x1000
> flashstart  = 0x
> flashsize   = 0x
> flashoffset = 0x
> sramstart   = 0x
> sramsize= 0x
> bootflags   = 0x0FEA4C88
> procfreq=400 MHz
> plb_busfreq = 20 MHz
> ethaddr = 00:0A:35:01:02:03
> IP addr = 172.16.40.227
> baudrate=   9600 bps
> Not skipping initrd
> ## Loading RAMDisk Image at 0180 ...
>Image Name:
>Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
>Data Size:1507104 Bytes =  1.4 MB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
>Booting using the fdt at 0x100
> ## initrd at 0x01800040 ... 0x0196FF5F (len=1507104=0x16FF20)
>Loading Ramdisk to 0fd35000, end 0fea4f20 ... OK
> ## device tree at 0x0100 ... 0x01002FFF (len=12288=0x3000)
>Loading Device Tree to 007fc000, end 007fefff ... OK
> ## Transferring control to Linux (at address ) ...
> Using Xilinx Virtex machine description
> Linux version 2.6.26-rc8 ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX
> ELDK 4.1 4.0.0)) #6 PREEMPT Wed Jul 9 12
> :36:41 PDT 2008

[snip]

> i2c /dev entries driver
> Device Tree Probing 'i2c'
> d002.i2c #0 at 0xD002 mapped to 0xE101, irq=20
> TCP cubic registered
> NET: Registered protocol family 17
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> eth0: XLlTemac: Options: 0x3fa
> eth0: XLlTemac: allocating interrupt 19 for dma mode tx.
> eth0: XLlTemac: allocating interrupt 18 for dma mode rx.
> eth0: XLlTemac: speed set to 100Mb/s
> eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4
> eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
> Sending DHCP requests ., OK
> IP-Config: Got DHCP answer from 149.199.109.235, my address is
> 172.16.40.12
> IP-Config: Complete:
>  device=eth0, addr=172.16.40.12, mask=255.255.255.0,
> gw=172.16.40.254,
>  host=172.16.40.12, domain=xilinx.com public.xilinx.com
> xlnx.xilinx.com public.xsj.xilinx., nis-domain=xil
> inx.com,
>  bootserver=149.199.109.235, rootserver=149.199.109.235,
> rootpath=/tmp

I don't *think* this causes problems, but your DHCP server is providing 
NFS configuration information.  Does that override the ramdisk 
configuration?

> List of all partitions:
> No filesystem could mount root, tried:  ext2 cramfs msdos vfat romfs
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(1,0)
> Rebooting in 180 seconds..

[snip]

HTH,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] u-boot, powerpc with device tree, initrd problem

[Jerry Van Baren]

John Linn wrote:
> I realize this could be posted to the linuxppc-dev also, but my kernel
> is running fine so I think it's a u-boot to kernel interface problem. I
> am able to pass a device tree to the kernel and get it to boot fine, and
> using NFS root also.
> 
> I can't get it to find my initrd ramdisk is my problem.  A kernel image,
> zImage.initrd, works with the ramdisk image, so I think everything is
> setup ok with the kernel.  I'm using a uImage and using mkimage on my
> ramdisk also for u-boot.

The messages look to me like linux is finding, decompressing, etc. the 
RAM disk.  It jumps the tracks sometime later.

> I realize it could be that I'm just loading the images in the RAM such
> that when the kernel gets uncompressed it stomps on the ram disk. I have
> tried moving to other addresses without any luck. When I look in memory
> where the ram disk was loaded by uboot, I can see the image fine after
> the kernel has paniced because it didn't find the root file system.
> 
> Is there something basic that I'm missing?
> 
> Thanks, appreciate any help,
> John
> 
> 
> => bootm 0x1c0 0x180 0x100
> ## Booting image at 01c0 ...
>Image Name:   Linux-2.6.26-rc8
>Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>Data Size:1536987 Bytes =  1.5 MB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
>Uncompressing Kernel Image ... OK

kernel check

> ## Loading RAMDisk Image at 0180 ...
>Image Name:
>Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
>Data Size:1507104 Bytes =  1.4 MB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
>Booting using the fdt at 0x100
>Loading Ramdisk to 0fd35000, end 0fea4f20 ... OK

ramdisk check

>Loading Device Tree to 007fc000, end 007fefff ... OK
>Loading Device Tree to 007fa000, end 007fcfff ... OK

fdt check, but why are there two of them???  I don't have access to a 
successful system boot at the moment, so I don't know if this is normal 
or not.  I'm thinking not.  Does your kernel have a device tree blob 
built in?

> Using Xilinx Virtex machine description
> Linux version 2.6.26-rc8 ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX
> ELDK 4.1 4.0.0)) #4 PREEMPT Tue Jul 8 14
> :45:07 PDT 2008
> Zone PFN ranges:
>   DMA 0 ->   131072
>   Normal 131072 ->   131072
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0:0 ->   131072
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
> 130048
> Kernel command line: console=ttyS0 ip=on root=/dev/ram
> Xilinx intc at 0xD0020200 mapped to 0xfdfff200
> PID hash table entries: 2048 (order: 11, 8192 bytes)
> clocksource: timebase mult[c80] shift[22] registered
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 514432k/524288k available (3024k kernel code, 9332k reserved,
> 128k data, 149k bss, 156k init)
> Mount-cache hash table entries: 512
> device-tree: Duplicate name in /, renamed to "chosen#1"

This is interesting.  Looks like you have two /chosen nodes???  Is this 
related to having two "Loading Device Tree" messages?  I don't know 
if/how this would be the problem, but my theory of making things work is 
to fix the known problems before debugging the unknown problems.

[snip]

Best regards,
gvb


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] cpu/mpc85xx/fdt.c forcing incorrect UART clock into fdt.

[Jerry Van Baren]

Paul Gortmaker wrote:
> In message: Re: [U-Boot-Users] cpu/mpc85xx/fdt.c forcing incorrect UART clock 
> into fdt.
> on 09/07/2008 Kumar Gala wrote:
> 
>> On Jul 8, 2008, at 4:42 PM, Paul Gortmaker wrote:
>>
>>> I fixed it with this simple patch, but I was wondering whether it  
>>> would
>>> be better to alternatively just check if the dtb value is zero, and
>>> then only insert a value; otherwise leave it alone...
>> I think that should be left up to a board to decide, but in general it  
>> seems like doing the setting unconditionally is ok, we just didn't  
>> handle the case you had and the patch address it.
> 
> OK, so that we only end up changing just one thing at a time, I'll
> spin a proper patch which just makes the NS16550_CLK change, and
> we can change the create flag as per Jerry's comment at a later date
> if required.
> 
> In the interest of consistency, I've make the same change for 83xx and
> 86xx as well, since the code is pretty much identical, and a MAKEALL
> shows no boards failing due to a non-defined NS16550_CLK.  Patch to
> follow shortly...
> 
> Thanks,
> Paul.

FWIIW, this works for me (with my disclaimer of not being a domain expert).

gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command

[Jerry Van Baren]

Kumar Gala wrote:
> 
> On Jul 9, 2008, at 10:17 AM, Jerry Van Baren wrote:
> 
>> Kumar Gala wrote:
>>> If the path we are trying to print doesn't exist see if it matches an
>>> aliases.  We don't do anything fancy at this point, but just strip the
>>> leading '/' if it exists and see if we have an exact match to an alias.
>>> In the future we could try and prefix matching so the alias could be 
>>> used
>>> as a shorter path reference.
>>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>>
>> Cool and useful too.  Out of curiousity, does "real" Open Firmware do 
>> this sort of thing with aliases?
> 
> I'm pretty sure it the Apple OF implementation does.  However I dont 
> remember to what extent it does from my playing around with OF on Apple HW.

Sounds like I'm going to have to preempt my kids on the olpc and see 
what OF does on it.  :-)

>> One reservation I have (which may disappear if the answer to the 
>> previous question is "yes"), it automatically and silently 
>> dereferences the /aliases/X node when asked to display /X or X (but 
>> only if /X doesn't exist in the dtb).  This is not an obvious behavior 
>> since X isn't real.
> 
> we could print out something about using an alias so the user knows that 
> its happening.
> 
>> Should we have a different display syntax to force the dereference of 
>> an alias X?  Assuming "*" is a good choice, this would change the 
>> behavior
>>  fdt print *ethernet0
>> to dereference /aliases/ethernet0 and print out
>>  /[EMAIL PROTECTED]/.../enet0 (or whatever).
> 
> Lets says I have an alias for 'soc' to '[EMAIL PROTECTED]'.  I want to be 
> able to in the future do print /soc/enet0 and have that work.  
> Introducing some new syntax would make that difficult and more ugly.
> 
> - k

Thinking out loud... we could define the syntax that a leading "*" 
indicates the first part of the path is a dereference of /aliases.

Assuming
   /aliases/soc = /[EMAIL PROTECTED]
   /aliases/ethernet0 = /[EMAIL PROTECTED]/.../enet0
then
   print *soc/enet0
and
   print *ethernet0
would both work and print the right thing.  You *would* have to know 
that the first element of the path is an /aliases dereference.  Your 
original patch did not require that piece of knowledge (but silently and 
automagically, which makes me nervous).

gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] No ethernet link on Lubbock board.

[Jerry Van Baren]

Victor wrote:
> Something more I have found out:
> 
> I've looking at drivers/net/lan91c96.c:
> 
> I have enabled Debug, and hardcoded my Mac address on get_rom_mac().
> 
> I loaded u-boot on my board, and when I run a tftp command I get this:
> 
> $ tftp
> LAN91C96:smc_close
> LAN91C96:smc_shutdown
> LAN91C96:smc_open
> LAN91C96:smc_reset
> LAN91C96:smc_enable
> Using MAC Address 00:02:B3:00:8F:3B
> *** Warning: no boot file name; using 'C0A80102.img'
> TFTP from server 192.168.1.1; our IP address is 192.168.1.2
> Filename 'C0A80102.img'.
> Load address: 0xa0008000
> Loading: LAN91C96: memory allocation, try 1 failed ...

Ahhh, that and grep ought to narrow down the error domain hugely.  Bingo:


Now you just have to figure out why the chip doesn't want to allocate 
memory or perhaps you have a problem with the MEMORY_WAIT_TIME 
definition?  Maybe your CPU is too fast, maybe you need a delay in the 
loop or need to make the loop (MEMORY_WAIT_TIME) longer?

Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command

[Jerry Van Baren]

Kumar Gala wrote:
> If the path we are trying to print doesn't exist see if it matches an
> aliases.  We don't do anything fancy at this point, but just strip the
> leading '/' if it exists and see if we have an exact match to an alias.
> 
> In the future we could try and prefix matching so the alias could be used
> as a shorter path reference.
> 
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

Cool and useful too.  Out of curiousity, does "real" Open Firmware do 
this sort of thing with aliases?

One reservation I have (which may disappear if the answer to the 
previous question is "yes"), it automatically and silently dereferences 
the /aliases/X node when asked to display /X or X (but only if /X 
doesn't exist in the dtb).  This is not an obvious behavior since X 
isn't real.

Should we have a different display syntax to force the dereference of an 
alias X?  Assuming "*" is a good choice, this would change the behavior
   fdt print *ethernet0
to dereference /aliases/ethernet0 and print out
   /[EMAIL PROTECTED]/.../enet0 (or whatever).

Thanks,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] add 'license' command to u-boot?commandline

[Jerry Van Baren]

Harald Welte wrote:
> Hi!
> 
> Since there has been support by Detlev and Stefan, I have modified the
> patch in a way to dynamically create the include/license.h file from the
> COPYING file by the use of a small C program and gzip combined with a
> Makefile rule.
> 
> What do you think now?

Bleah on the small C program (nothing personal, just hate to add Yet 
Another Program to the build process).  How about using echo for prelim 
text (if necessary) and xxd to create the struct instead?  I like making 
maintenance Somebody Else's Problem (SEP[1])

$ man xxd
XXD(1)

NAME
xxd - make a hexdump or do the reverse.

[snip other possibly useful flags like column]

-i | -include
   output in C include file style. A complete static array 
definition is written  (named  after  the  input  file),
   unless xxd reads from stdin.

-l len | -len len
   stop after writing  octets.

Best regards,
gvb

[1] 

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH 04/10 v2] [ARM] TQMA31: add new board with i.MX31 processor

[Jerry Van Baren]

Guennadi Liakhovetski wrote:
> On Tue, 8 Jul 2008, Jens Gehrlein wrote:
> 
>> diff --git a/board/tqc/tqma31/Makefile b/board/tqc/tqma31/Makefile
>> new file mode 100644
>> index 000..f7e17c8
>> --- /dev/null
>> +++ b/board/tqc/tqma31/Makefile
>> @@ -0,0 +1,48 @@
>> +#
>> +# Copyright (C) 2008, Guennadi Liakhovetski <[EMAIL PROTECTED]>
>> +# Copyright (C) 2008, Jens Gehrlein <[EMAIL PROTECTED]>
> 
> Thanks for the credit, but, although IANAL, I think, one does not _have_ 
> to preserve the copyright of the original file when it gets copied to a 
> new one. Otherwise most open-source files would have a vry long list 
> of Copyrights:-) Am I right?
> 
> Thanks
> Guennadi

IANAL, but I play one on Groklaw sometimes, much to PJ's chagrin. ;-)

This is a squishy area.  It is dependent on what of the original work 
survives the modification and whether the surviving pieces are 
copyrightable.  It also depends on what country you are contemplating 
suing in.



Things that must be done in certain ways are not copyrightable, so 
Makefiles are pretty marginal to start with IMHO.



My opinion is to leave the original copyright notice in there and err on 
the side of preserving reasonable copyright notices.  The lawyers will 
be happy to tell us that we did it wrong if it ever came to a lawsuit, 
and I would prefer that they tell us that we had a useless copyright 
notice in the file rather than tell us that we should have had a notice 
but didn't...

Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] cpu/mpc85xx/fdt.c forcing incorrect UART clock into fdt.

[Jerry Van Baren]

Paul Gortmaker wrote:
> I was updating a sbc8560 from u-boot v1.2.0 to git-current, and found
> that I'd loose the kernel serial console when the 8250 driver took over
> from udbg0 when using u-boot 1.3.x  (booting via tftp'ing the dtb and
> the uImage separately)
> 
> I eventually tracked it down to mpc85xx/fdt.c stomping on the contents
> of the UART clockrate in the dtb.  Since the sbc8560 is sort of
> different -- in that it has external UARTs (instead of SOC/CPM), I'm
> guessing few other boards see this problem, because bi_busfreq is
> really their correct UART clk.
> 
> I fixed it with this simple patch, but I was wondering whether it would
> be better to alternatively just check if the dtb value is zero, and 

Not defined: I would have serious heartburn if the .dts/dtb value were 
defined to be zero.  Define or define not, there should be no zero (with 
apologies to Yoda).

> then only insert a value; otherwise leave it alone...
> 
> Paul.

Changing the fixup last parameter (create) from "1" to "0" will prevent 
overriding an existing value.  Note that this will *not* override a 
silly value (e.g. 0), so, if you do this, the dtb must either not have 
the clock-frequency defined or have a correct value in that property. 
This would have the good effect of allowing the board specific clock to 
be defined in the dtb where it belongs, but still support the older 
style approach of compiling it in.

This seems like a good improvement (your patch, but changing the "1" to 
"0") to me, but I'm not a 85xx expert.

> diff --git a/cpu/mpc85xx/fdt.c b/cpu/mpc85xx/fdt.c
> index 92952e6..bd43073 100644
> --- a/cpu/mpc85xx/fdt.c
> +++ b/cpu/mpc85xx/fdt.c
> @@ -224,7 +224,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
>  
>  #ifdef CFG_NS16550
>   do_fixup_by_compat_u32(blob, "ns16550",
> - "clock-frequency", bd->bi_busfreq, 1);
> + "clock-frequency", CFG_NS16550_CLK, 1);
>  #endif
>  
>  #ifdef CONFIG_CPM2

Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH 1/2] fdt_support: fdt_fixup_dr_usb: add support for phy_type fixups

[Jerry Van Baren]

Anton Vorontsov wrote:
> Currently U-Boot can only fixup the usb dr_mode, but some boards (namely
> MPC8315E-RDB) can use two PHY types: ULPI (stand-alone OTG port) or UTMI
> (connected to the four-ports hub, usb host only).
> 
> This patch implements support for passing Dual-Role USB controller's
> device tree property phy_type through the usb_phy_type environment
> variable.
> 
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
>  common/fdt_support.c |   30 +++---
>  1 files changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 3828228..24bbed0 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c

Hi Anton, Kim,

This looks good to me.

Anton, I presume this is additional functionality for the next window,
not a bug fix for the current (closed) window?

Kim, would you like to apply this as well as [PATCH 2/2] through the
83xx repository so the two halves go in at the same time?

Acked-by: Gerald Van Baren <[EMAIL PROTECTED]>

Thanks,
gvb


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] Round the serial port clock divisor value returned by calc_divisor()

[Jerry Van Baren]

Hugo Villeneuve wrote:
> Jerry Van Baren wrote:
>> Hugo Villeneuve wrote:
>>> Round the serial port clock divisor value returned by calc_divisor().
>>>
>>> Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]>
>>>
>>> ---
>>>
>>> Rounding is important, especially when using high baud rates
>>> values like 115200bps. When using the non-rounded value, some
>>> boards will work and some won't.
>>>
>>>  drivers/serial/serial.c |7 ++-
>>>  1 files changed, 6 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c index
>>> 76425d8..7e315ad 100644 --- a/drivers/serial/serial.c
>>> +++ b/drivers/serial/serial.c
>>> @@ -124,6 +124,8 @@ static NS16550_t serial_ports[4] = {
>>>
>>>  static int calc_divisor (NS16550_t port)
>>>  {
>>> +   u32 divisor_x10;
>>> +
>>>  #ifdef CONFIG_OMAP1510
>>> /* If can't cleanly clock 115200 set div to 1 */
>>> if ((CFG_NS16550_CLK == 1200) && (gd->baudrate == 115200)) {
>>> @@ -144,8 +146,11 @@ static int calc_divisor (NS16550_t port)  #else
>>>  #define MODE_X_DIV 16
>>>  #endif
>>> -   return (CFG_NS16550_CLK / MODE_X_DIV / gd->baudrate);
>>>
>>> +   /* Compute divisor value with rounding by adding 0.5 */
>>> +   divisor_x10 = (10 * CFG_NS16550_CLK) / MODE_X_DIV / gd->baudrate; +
>>> +   return (divisor_x10 + 5) / 10;
>>>  }
>>>
>>>  #if !defined(CONFIG_SERIAL_MULTI)
>> Hi Hugo,
>>
>> Will a real rounding work?  Work better?  If I got my mental math and
>> parenthesis right and the resulting math doesn't overflow your
>> registers, the following will add 1/2 the baud rate scaled by the
>> MODE_X_DIV and then perform the divide which will do full rounding.
>>
>>  return (((CFG_NS16550_CLK + ((gd->baudrate / 2)* MODE_X_DIV))
 oops, I missed a space ^
>>  / MODE_X_DIV) / gd->baudrate);
> I tested it and it works for me.
> But maybe the code is less obvious that way?

Obviousness is relative.  :-)
This will be more accurate, but accuracy is relative too.  :-/  It only 
has to be close.

Since CFG_NS16550_CLK is very likely a multiple of MODE_X_DIV or it 
doesn't matter if it isn't because it is much, much larger than 
MODE_X_DIV,  the formula could be simplified slightly without 
substantially hurting the accuracy...

return (((CFG_NS16550_CLK + (gd->baudrate / 2))
/ MODE_X_DIV) / gd->baudrate);

A slight bit of added perceived complexity may be coming from my 
addition of parenthesis to emphasize the evaluation order.  The 
following (should be) equivalent and reads better to my brain.

return (CFG_NS16550_CLK + (gd->baudrate / 2)) /
(MODE_X_DIV * gd->baudrate);


>> Alternately, I prefer to scale up by 16 and then divide by 8 since
>> processors can do that very efficiently ( << 4 followed by >> 3).
> Right.
> 
> I prefer the second solution for its simplicity, but the first one also works.

Bottom line: it's your call IMHO.

Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] Round the serial port clock divisor value returned by calc_divisor()

[Jerry Van Baren]

Hugo Villeneuve wrote:
> Round the serial port clock divisor value returned by
> calc_divisor().
> 
> Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]>
> 
> ---
> 
> Rounding is important, especially when using high baud rates
> values like 115200bps. When using the non-rounded value, some
> boards will work and some won't.
> 
>  drivers/serial/serial.c |7 ++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
> index 76425d8..7e315ad 100644
> --- a/drivers/serial/serial.c
> +++ b/drivers/serial/serial.c
> @@ -124,6 +124,8 @@ static NS16550_t serial_ports[4] = {
>  
>  static int calc_divisor (NS16550_t port)
>  {
> + u32 divisor_x10;
> +
>  #ifdef CONFIG_OMAP1510
>   /* If can't cleanly clock 115200 set div to 1 */
>   if ((CFG_NS16550_CLK == 1200) && (gd->baudrate == 115200)) {
> @@ -144,8 +146,11 @@ static int calc_divisor (NS16550_t port)
>  #else
>  #define MODE_X_DIV 16
>  #endif
> - return (CFG_NS16550_CLK / MODE_X_DIV / gd->baudrate);
>  
> + /* Compute divisor value with rounding by adding 0.5 */
> + divisor_x10 = (10 * CFG_NS16550_CLK) / MODE_X_DIV / gd->baudrate;
> +
> + return (divisor_x10 + 5) / 10;
>  }
>  
>  #if !defined(CONFIG_SERIAL_MULTI)

Hi Hugo,

Will a real rounding work?  Work better?  If I got my mental math and 
parenthesis right and the resulting math doesn't overflow your 
registers, the following will add 1/2 the baud rate scaled by the 
MODE_X_DIV and then perform the divide which will do full rounding.

return (((CFG_NS16550_CLK + ((gd->baudrate / 2)* MODE_X_DIV))
/ MODE_X_DIV) / gd->baudrate);

Alternately, I prefer to scale up by 16 and then divide by 8 since 
processors can do that very efficiently ( << 4 followed by >> 3).

Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] No ethernet link on Lubbock board.

[Jerry Van Baren]

Victor wrote:
> This is a problem I've been fighting to for a long time. I'm sure it
> would be something stupid I haven't noticed, but I don't know what
> else to try. My Linux OS is working flawlessly with a correct eth0
> device, so at least I know it's not (or should not) a hardware
> problem.
> 
> Everything else works as expected, but the LAN91C96 driver does not
> enable the board network interface.
> 
> Environment:
> Hardware: Lubbock Board from Intel, wired to an IBM Laptop.
> U-boot version: 1.3.3 (tried with 1.3.1, 1.20, same results)
> mac address: tried with the one generated by the eth_gen_tool, and the
> original hardware one.
> Default 'lubbock.h' file, heavy edited one, etc... No luck.
> 
> $ printenv:
> U-Boot 1.3.3 (Jul  8 2008 - 19:07:01)
> 
> DRAM:  64 MB
> Flash: 64 MB
> Hit any key to stop autoboot:  0
> $ printenv
> baudrate=115200
> netmask=255.255.0.0
> bootdelay=5
> serverip=192.168.1.1
> ipaddr=192.168.1.2
> bootcmd=bootm 20
> bootargs=ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:pxa:eth0:off
> mem=64M root=/dev/nfs nfsroot=192.168.1.1:/rootfs/nfs init=/sbin/init
> console=ttyS0,115200
> ethaddr=00:02:b3:00:8f:xx
  ^^
  Hmmm, what base are we using here?  Base 26?
  :-D
> stdin=serial
> stdout=serial
> stderr=serial
> 
> Something odd I noticed:
> 
> $ tftpboot
> 
> Warning: MAC addresses don't match:
> HW MAC address:  01:00:01:00:01:00
> "ethaddr" value: 00:02:B3:00:8F:xx
> Using MAC Address 00:02:B3:00:8F:xx

I'm assuming you didn't hand edit in the "xx" out of paranoia.

> Linux detects the correct Mac Address without any configuration, why
> u-boot reads 01:00:01:00:01:00?

Beats me.

> Any idea?

Try a valid MAC address?

Good luck,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Custodianship updates

[Jerry Van Baren]

Wolfgang Denk wrote:
> Hello everybody,
> 
> as many of you will have seen, there have been a few areas in  U-Boot
> where  processing of patches and new code submissions did not work as
> quickly and smoothly as we all would have liked.
> 
> I'm all the more happy to be able to announce updates for two (IMHO
> both important) areas:
> 
> * ARM: Peter Pearse has been trying his best to  do  a  good  job  to
>   maintain the (huge!) ARM part of the U-Boot project, but he did not
>   find enough free resources to do this on a regular base. I know all
>   too  well  how  that  feels,  as I'm in the very same situation too
>   often myself.
> 
>   But now we have the chance  that  Jean-Christophe  Plagniol-Villard
>   volunteers  to  help out, and given from the previous activities he
>   has shown on the mailing list I think that he is  very  capable  of
>   doing that job.
> 
>   Peter has agreed that Jean-Christophe takes over the  custodianship
>   for ARM. If there are no objections (or better suggestions) I would
>   install this change more or less immediately.
> 
>   Comments?

ACK.  I have to sympathize with Peter.  Doing a full time job on a spare 
time budget sucks.

> * MPC512x: as it turns out, Grant Likely, the custodian  for  MPC5xxx
>   systems,  finds  neither  time  nor  resources to work with MPC512x
>   processors. Fortunately John Rigby volunteered, in addition to  all
>   his  previous  work  he  has  optimal access to recent hardware and
>   documentation :)
> 
>   If there are no objections, I would like to split custodionship for
>   these processors into "MPC5xxx" (meaning actually MPC5200), handled
>   by Grant Likely as before, and into MPC512x, handled by John Rigby.
>   
>   Comments?

Ditto.  Sounds like John is well positioned and provisioned.

> Best regards,
> 
> Wolfgang Denk

Best regards,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] u-boot and OneNAND

[Jerry Van Baren]

Kyungmin Park wrote:
> On Thu, Jul 3, 2008 at 1:58 PM, Kyungmin Park <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> On Wed, Jul 2, 2008 at 8:55 PM, Mile Davidovic <[EMAIL PROTECTED]> wrote:
>>> Hello
>>> If I read code correctly u-boot have OneNAND driver. But when I check JFFS2
>>> in u-boot it seems that JFFS2 can not work on OneNAND.
>> Yes, it's not yet implemented.
>>
> 
> Feel free to use this patch.
> the mtdparts and fsload is working, but I'm not suer it's working correctly.
> 
> Thank you,
> Kyungmin Park
> ---
> diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c
> index 1b67e73..51c742c 100644
> --- a/common/cmd_jffs2.c
> +++ b/common/cmd_jffs2.c

I don't know what the rest of the list thinks, but I would like to see a 
"Signed-off-by" line (and/or a note on where the code came from - e.g. 
linux) on all patches whether they are preliminary or not.  I would hate 
to get into a "where did this code come from" quandary over a code that 
came from, was influenced by, or simply looked like a patch that was 
posted without proper traceability.

Thanks,
gvb


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] Fix printf errors.

[Jerry Van Baren]

Andrew Klossner wrote:
> The compiler will help find mismatches between printf formats and
> arguments if you let it.  This patch adds the necessary attributes to
> declarations in include/common.h, then corrects the resulting compiler
> warnings in several files.  Some of these were bugs, e.g., "$d"
> instead of "%d" and incorrect arguments in common/cmd_fdt.c.  Others
> were just annoying, like int-long mismatches on a system where both
> are 32 bits.  It's worth fixing the annoying errors to catch the real
> ones.
> 
> I can only compile for ppc architecture so have not tested much of the
> source code for further warnings.
> 
> common/cmd_fdt.c

cmd_fdt.c portion...
Acked-by: Gerald Van Baren <[EMAIL PROTECTED]>

I'm embarrassed by the number of bugs I wrote into that function and 
apologize for being so sloppy.  My thanks to Andrew and others for 
finding and fixing my screwups.  :-(

Best regards,
gvb


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] TSEC/PHY @ MPC834x stopped working

[Jerry Van Baren]

Andre Schwarz wrote:
> Jerry,
> 
> I don't understand this.
> 
> The code is far from using the device tree - the dtb is fetched by tftp
> right after bootp.
> 
>  It's the initial bootp/dhcp that doesn't work
> 
> regards,
> Andre

Ah, right, my bad.

Sorry for the noise,
gvb

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] TSEC/PHY @ MPC834x stopped working

[Jerry Van Baren]

Kim Phillips wrote:
> On Wed, 02 Jul 2008 16:36:11 +0200
> Andre Schwarz <[EMAIL PROTECTED]> wrote:
> 
>> Ben,
>>
>> thanks for your quick reply.
>> Looks like you're right - nothing changed regarding network yet.
>>
>> Maybe it's a cpu specific problem.
>> Kim ? Can you help here ?
>>
> 
> I know of nothing (barring this being the ETHADDR not specified
> problem) that could have caused this. Can you try using git-bisect?
> 
> Kim

Some people were caught by the somewhat recent requirement for an 
/aliases node and properties pointing to the "real" ethernet node (which 
is a Good Thing[tm] because it makes the code board agnostic, pushes the 
board configuration into the .dts where it belongs).

I don't associate Andre's assertion:
> Obviously the MII interface stopped working, i.e. all reads give 0xFF.
with the symptoms caused by a missing /aliases node.  Maybe, maybe not, 
could be my lack of experience.

Best regards,
gvb


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Relocating code problem

[Jerry Van Baren]

Aruna Kumari wrote:
> I have a problem durinf relocating of code from sdram. The uboot hangs.
> My sdram initialization is correct as it has passed ddr test.
> Kindly help me in solving this.
> I am using Jtag to download uboot to flash.
>  
> Regards,
>  
> Aruna,

Hi Aruna,

This is a FAQ.
   

Just because your SDRAM configuration passes the ddr test doesn't 
necessarily mean it is working 100% correctly.  Misconfigured SDRAM will 
"work" if it isn't driven hard (i.e. pipelining effectively not being used).
   

If your SDRAM *is* working as you claim, you found a new problem and 
will have to update the FAQ.  :-/

HTH,
gvb

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] fdt: Fix typo in variable name.

[Jerry Van Baren]

Detlev Zundel wrote:
> Hi Jerry,
> 
>> Detlev Zundel wrote:
>>> Signed-off-by: Detlev Zundel <[EMAIL PROTECTED]>
>>> ---
>>>  common/fdt_support.c |4 ++--
>>>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> [...]
> 
>> Dear Wolfgang,
>>
>> Could you apply this directly?  I'm on vacation this week and I would
>> appreciate the help.
> 
> I really didn't want to push this, as I do not deem it in any way
> important.  So my original plan was to wait for Wolfgang to pull it in
> in his usual cycle.
> 
> Because of a high-priority bug-fix for 4xx, it now found its way into
> master anyway, so no need for you to pick it up.
> 
> Cheers
>   Detlev

Thanks,
gvb


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Non-static global variables cause relocation to fail

[Jerry Van Baren]

Timur Tabi wrote:
> Jerry Van Baren wrote:

[snip]

>> I'm guessing from the name "eeprom" that you have a non-zero initializer 
>> on it???  
> 
> No, no initializer.
> 
>> Does it make a difference if it is uninitialized, initialized 
>> to {0}, or initialized to non-zero values?
> 
> I don't know, I haven't considered it.
> 
> I did notice this code in fsl_i2c.c:
> 
> #ifdef CFG_SPD_BUS_NUM
> static unsigned int i2c_bus_num __attribute__ ((section ("data"))) =
> CFG_SPD_BUS_NUM;
> #else
> static unsigned int i2c_bus_num __attribute__ ((section ("data"))) = 0;
> #endif
> 
> I wrote this code, but I don't remember why I added the "__attribute__ 
> ((section
> ("data")))".  I guess I should have commented it, but I wonder if it applies 
> to
> my current problem.

It doesn't apply in the original complaint and may be flat out wrong, 
but I recall having a problem forcing a zero initializer into the data 
section.  Gcc insisted on putting it in bss and, after playing language 
lawyer with the gcc manual/descriptions/etc, I concluded it was expected 
behavior of gcc.

[snip]

> When I post the full patch, I'll revisit this problem.  Sorry for all the 
> noise.

Interesting quirk.  We may give you a hard time, but that just betrays 
our curiosity.  ;-)

Best regards,
gvb


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] fdt: Fix typo in variable name.

[Jerry Van Baren]

Detlev Zundel wrote:
> Signed-off-by: Detlev Zundel <[EMAIL PROTECTED]>
> ---
>  common/fdt_support.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index e58b294..3828228 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -63,7 +63,7 @@ int fdt_find_and_setprop(void *fdt, const char *node, const 
> char *prop,
>  }
>  
>  #ifdef CONFIG_OF_STDOUT_VIA_ALIAS
> -static int fdt_fixup_stdout(void *fdt, int choosenoff)
> +static int fdt_fixup_stdout(void *fdt, int chosenoff)
>  {
>   int err = 0;
>  #ifdef CONFIG_CONS_INDEX
> @@ -82,7 +82,7 @@ static int fdt_fixup_stdout(void *fdt, int choosenoff)
>   err = -FDT_ERR_NOSPACE;
>   if (p) {
>   memcpy(p, path, len);
> - err = fdt_setprop(fdt, choosenoff,
> + err = fdt_setprop(fdt, chosenoff,
>   "linux,stdout-path", p, len);
>   free(p);
>   }

Dear Wolfgang,

Could you apply this directly?  I'm on vacation this week and I would 
appreciate the help.

Thanks,
gvb

Currently at Tower Marine, Douglas, MI, USofA :-)


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Non-static global variables cause relocation to fail

[Jerry Van Baren]

Timur Tabi wrote:
> Wolfgang Denk wrote:
> 
>> You  don't  seriously  expect  any  real  help  given  such  a  vague
>> description?  It  would be somewhat helpful if you said exactly which
>> changes cause the code to work or fail...
> 
> I did say that.  Simply making the global variable not static caused it to 
> fail.
> 
> Works:
> 
> static struct __attribute__ ((__packed__)) eeprom {
> 
> Doesn't work:
> 
> struct __attribute__ ((__packed__)) eeprom {
> 
> Everything else is the same.

Hi Timur,

That isn't a variable, that is the first line of a struct declaration. 
You cut some pretty important information: what the struct is, the 
actual variable in question, and whether it is initialized.

I'm guessing from the name "eeprom" that you have a non-zero initializer 
on it???  Does it make a difference if it is uninitialized, initialized 
to {0}, or initialized to non-zero values?

Does it make a difference if it is packed or not (my guess: much less 
likely than initialization to cause works/broken).

Best regards,
gvb


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] u-boot on N810

[Jerry Van Baren]

Ashish Bijlani wrote:
> hey jerry...thanks for the replyi don't wanna replace nolo with
> u-boot...i just wanna nolo to load u-boot instead of loading the
> kernel directlythe reason is that i wanna load l4 based hypervisor
> image first and then linux on top of itcurrent loader (nolo) is
> linux specific and wouldn't allow me to load the hypervisor at any
> random place in memory
> 
> can nokia flasher load and boot the kernel image without actually
> flashing it? if yes, could you please mention the details...thanks

Hi Ashish,

Please bottom post.

You are way beyond my experience base with the n8x0.  You might be able 
to get better answers on a Nokia (maemo) email list(s).
   

WRT u-boot, I don't see how using nolo to boot u-boot to boot L4 is 
going to be any easier than booting L4 directly from nolo.

You might look into using kexec to chainload your L4 hypervisor.  Kexec 
is the linux program to load a new kernel, theoretically you could do 
that with L4 too.  Google is your friend.  The following looks useful:
   

Good luck,
gvb

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] u-boot on N810

[Jerry Van Baren]

Ashish Bijlani wrote:
> Thanks for the response. Does u-boot support n810? Can I flash u-boot
> on n810? Thanks.

No, you would need to port u-boot to the hardware.  The OMAP and the 
necessary built in peripherals shouldn't be a major problem, but you 
would have to get the rest of the hardware like the SDRAM and other bits 
& pieces initialized/configured before u-boot will run on the hardware.

Be aware that you need to be very good and extremely lucky to load a new 
u-boot without bricking your n810.  If you try flashing u-boot, you 
better have an alternate means of reloading the firmware (i.e. a JTAG 
debugger).

I'm curious: why do you wish to replace the n810 firmware?  The current 
firmware initializes the hardware and boots linux... those are the usual 
primary reasons for porting u-boot to new hardware.

gvb
P.S. I have a n800.  It would be cool to have u-boot running on it, but 
I don't see the pain vs. gain paying off.

> On Wed, Jun 18, 2008 at 11:34 AM, Menon, Nishanth <[EMAIL PROTECTED]> wrote:
>> Ashish,
>>> -Original Message-
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>> On Behalf Of Ashish Bijlani
>>> Sent: Wednesday, June 18, 2008 11:01 AM
>>> To: u-boot-users@lists.sourceforge.net
>>> Subject: [U-Boot-Users] u-boot on N810
>>>
>>> - took u-boot (ELF) from TI's website for OMAP2420
>>> (http://linux.omap.com/pub/bootloader/h4/)
>> Wrong here. This is for 2420 development platform that you see here: 
>> http://www.ti.com/omap2420_devplatform
>>
>> You may be interested in this: 
>> http://maemo.org/community/wiki/HOWTO_FlashLatestNokiaImageWithLinux/#a4f6eb951c9d89a4a9027f479f3935c8
>> Regards,
>> Nishanth Menon
>>
> 
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> U-Boot-Users mailing list
> U-Boot-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] trouble to build u-boot.bin with objcopy

[Jerry Van Baren]

valerian NA wrote:
> Hi all,
> 
> I work with a linux cross-compiler (codesourcery with gcc 4.2.3) for 
> embedded powerpc targets (mpc8248).
> So I tried to compile u-boot (version 1.1.6). It works fine with another 
> and older version of gcc (3.3.2) but with the new cross-compiler (4.2.3) 
> I have trouble to do this part :
> powerpc-linux-gnu-objcopy --gap-fill 0xff -O binary u-boot u-boot.bin
> 
> This command freezes and uses a lot of memory without sucess (maybe I 
> have not enough disk space).

Symptom of an inadvertent *large* gap in your "LOAD" sections.

> I decided to launch without "--gap-fill" to see the reaction :
> powerpc-linux-gnu-objcopy -O binary u-boot u-boot.bin
> It creates u-boot.bin file, and the system (host ls -al) tells that this 
> file has a size nearest to 4GiB
> 
> So I think it's a problem in the mapping of u-boot :
> powerpc-linux-gnu-objdump -h u-boot
> 
> u-boot: file format elf32-powerpc
> 
> Sections:
> Idx Name  Size  VMA   LMA   File off  Algn
>   0 .text 00017e18  fc00  fc00  2138  2**2
>   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .reloc0804  fc018000  fc018000  0001a138  2**0
>   CONTENTS, ALLOC, LOAD, DATA
>   2 .data 1060  fc018804  fc018804  0001a93c  2**2
>   CONTENTS, ALLOC, LOAD, DATA
>   3 .data.rel.ro.local 003c  fc019864  fc019864  0001b99c  2**2
>   CONTENTS, ALLOC, LOAD, DATA
>   4 .data.rel 003c  fc0198a0  fc0198a0  0001b9d8  2**2
>   CONTENTS, ALLOC, LOAD, DATA
>   5 .data.rel.local 0634  fc0198dc  fc0198dc  0001ba14  2**2
>   CONTENTS, ALLOC, LOAD, DATA
>   6 .ppcenv   0200  fc019f10  fc019f10  0001c048  2**2
>   CONTENTS, ALLOC, LOAD, DATA
>   7 .u_boot_cmd   00dc  fc01a110  fc01a110  0001c248  2**2
>   CONTENTS, ALLOC, LOAD, DATA
>   8 .bss  1bf8  fc01b000  fc01b000  0001d138  2**3
>   ALLOC

[snip]

>  13 .rodata.str1.1 209e  0660  0660  0094  2**0
>   CONTENTS, ALLOC, LOAD, READONLY, DATA

What is .rodata.str1.1?  Is it new to gcc 4.2.3?  It is being located at 
the start of memory where all the rest of your "LOAD" sections are at 
the end of memory.  The result: 4GB binary images.  You need to locate 
this is a better location (close to the rest of the "LOAD" sections).

[snip]

> Thanks a lot for your attention and your futurs ideas...
> 
> Val.

HTH,
gvb

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH 1/1] FAT Bare Partition Support

[Jerry Van Baren]

Michal Simek wrote:
> Hi Antonio
> 
> I am not responsible for this part of U-BOOT but your patch contain coding 
> style
> violation.
> 
> Regards,
> Michal Simek
> 
>> Logic unit:
>> Purpose:Add support for bare partitions (no partition table)
>> Author: Antnoio R. Costa  atmel.com>
>> Date  : 11 Jun 2008
>>
>> Status:
>> ~~
>> Some SD cards are not formatted with a partition table but with
>> just a bare partition at the beginnig of the memory.
>>
>> I modified get_partition_info_extended to call test_block_type
>> as done by print_partition_extended. In this way bare FAT partitions
>> are recognised. Now we need a test for Ext2.
>>
>> Signed-off-by: Antonio R. Costa <[EMAIL PROTECTED]>
>>
>> diff --git a/disk/part_dos.c b/disk/part_dos.c
>> index 4d778ec..e5cc8aa 100644
>> --- a/disk/part_dos.c
>> +++ b/disk/part_dos.c

[snip]

>> +static inline int le16_to_int(unsigned char *le16)
>> +{
>> +return ((le16[1] << 8) + le16[0]);
>> +}
>> +
> 
> this should be in header file

Please use  rather than making Yet Another Define. 
Note that the subdirectory asm gets symlinked to the appropriate 
arch-specific subdirectory and then the right endian munching is 
selected and it Just Works[tm].

PowerPC example:


[snip]

> Regards,
> Michal Simek

Thanks,
gvb

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] new to U-Boot, how do I get started for Atmel at91sam9261ek

[Jerry Van Baren]

> Jerry Van Baren wrote:
>> Vyas Ashish wrote:
>>>
>>> Hi Group,
>>>
>>> I have a at91sam9261ek evaluation Kit from Atmel and I want to bring 
>>> up the UBoot on that. When I got the board, I also got UBoot binary 
>>> which can be flashed and verified. However, I did not get the source 
>>> code. The code has to be purchased seperately, which I do not want to 
>>> do. I want to take up the UBoot porting on this board as a task.
>> 
>> If you received a u-boot binary for that board, you have the right to 
>> ask for a copy of the source that generated that u-boot binary and the 
>> company that distributed that u-boot binary (apparently Atmel) has the 
>> legal obligation to provide that at a reasonable cost to cover their 
>> distribution costs.  That is all part of the GNU General Public License.
>>   <http://en.wikipedia.org/wiki/Gpl>
>> 
>> There are Atmel employees on this list, perhaps they can speak to the 
>> issue more directly.
>> 
>>> Any quick pointer to start with? Do we have some other similar board 
>>> already supported by UBoot code that I can "clone" to make things faster?
>>>
>>> Best regards,
>>> Ashish Vyas
>> 
>> Best regards,
>> gvb

I received the following email from Ulf - it appears he is struggling 
with his phone/email and sent it directly to me only, not to the list. 
The one that really needed it was Vyas.  As expected, Vyas just needed 
to know where to look to get the source.

> Atmel does not sell GPL 
> source.
> 
> Check out www.Iinux4sam.org
> for U-boot source.
> 
> A later version will be 
> downloaded when
> You run buildroot,
> bul  that is not shipped
> with any systems.
> 
> Has there not been SAM9261
> patches sent in to the git
> lately?
> 
> (Symbian mail client sucks as well)
> 
> Best Regards
> Ulf Samuelsson

HTH,
gvb

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users