Re: [U-Boot] [PATCH v2] wandboard: Add board revision detection support
Am 25.05.2015 um 11:41 schrieb Wolfgang Denk: Dear Fabio, In message you wrote: "If the gpio command would be enabled, it would even be possible to reset the BRCM- WLAN and Bluetooth modules by just adding some stuff to uEnv.txt." This sounds like a real hack for me, sorry. Consider it as an example for being able to do many different things that have not even been thought of at the time of implementations. to try out things. Maybe we decide later to implement the features a C code, but for testing or working aound problems is is always nice to have scripting capabilities. Exactly. It's just another example besides the possibility to choose the correct dtb based on the board revision without modifying u-boot at all (if gpio would be enabled). And also the example is a hack, that's the stuff which is necessary very often, until someone fixes something in a driver (and managed it to get the fix upstream), or even to circumvent problems with some HW. Btw., in regard to the above specific hack, the same problem (failure to upload firmware because it's already uploaded) exists for Bluetooth too. Personally I've modified (hacked) the wandboard-rfkill-driver a year ago to disable the regulator of the brcm-module completely for some milliseconds at startup (and when the module is unloaded, to save power). But that involves having to manage own patches for the kernel, so I might even prefer to use just a hack in uEnv.txt to fix the reset problem with the brcm-module. Besides that I don't really care what a maintainer said to some previous similiar problem. Maintainers are humans too, maybe he just had forgotten about the gpio-command. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] wandboard: Add board revision detection support
Am 24.05.2015 um 20:47 schrieb Fabio Estevam: > On Sun, May 24, 2015 at 3:03 PM, Alexander Holler > wrote: > >> Hmm, just one comment more. >> >> If the gpio command would be enabled, it would even be possible to reset the >> BRCM- WLAN and Bluetooth modules by just adding some stuff to uEnv.txt. So >> at least WLAN would reliable work even after a reboot or reset, without the >> need for the rfkill-driver. Also the wandboard-rfkill-driver has more >> advantages, e.g. the rfkill. ;) >> >> For those which don't know it, currently, without the >> wandboard-rfkill-driver, WLAN works only once after power up, but not after >> the reboot. Thats because the HW doesn't reset the brcm on reset, so after a >> reboot or reset uploading the firmware fails (because it is already uploaded >> due to the missing reset of the module). > > Mainline kernel has proper way of handling the reset of the Wifi chip > via pwrseq mechanism. > > Please see this patch I did for cuboxi: > https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt&id=ec5757d85c0fd32274a6052b8a4482d626c01ae5 > > So we should really not add such hack in U-boot as mainline kernel has > the proper solution. I've not said that I want such a hack in u-boot. In fact I said that I don't want your hack in u-boot. My suggestion is to enable the gpio-command in order to make it possible to do stuff like checking for board revisions without having to modify u-boot at all (the binary as well as the source). As long as u-boot doesn't (have to) care about the board-revision, I don't see the need to add such stuff to a board-file. But as said, I don't care. But, please, don't suggest that I want to add a hack. Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] wandboard: Add board revision detection support
Am 24.05.2015 um 19:29 schrieb Alexander Holler: Am 24.05.2015 um 16:27 schrieb Fabio Estevam: Hi Stefano and Alexander, On Sun, May 24, 2015 at 4:43 AM, Stefano Babic wrote: Wouldn't it be better to just enable CONFIG_CMD_GPIO and then change the boot-script in the config to something like "if gpio ..." instead of adding something special? Assuming the gpio command works on imx, which I haven't tested or looked up. gpio works - this is really a good idea, moving the check into the script. Fabio, what do you mind ? I think the idea is good, thanks. I wanted to keep consistency with the mx6cuboxi implementation (which was based on TI's implementation suggested by Tom during the review of the mx6cuboxi patches). Also, the gpio script idea would work fine for selecting the dtb file, but not inside checkboard() function, where I print the board revision name. Printing the board revision in the script is as easy as selecting the dtb. Other aspect I thought is the fact that in case we have another revision of the board in the future, I think that C code is more flexible for handling it. Not really. Then it it would need again a patch for the C source. Using the gpio command one could just change the check even by just changing uEnv.txt. Look at how long it now needed until someone did this patch (your patch) for u-boot. So I like the idea of gpio script, but I would prefer to keep the current implementation if possible due to the reasons stated above. I would suggest to change the stuff for mx6cuboxi to use the gpio command too instead of taking the same (imho wrong) approach. But enough said from me, I don't really care. ;) Hmm, just one comment more. If the gpio command would be enabled, it would even be possible to reset the BRCM- WLAN and Bluetooth modules by just adding some stuff to uEnv.txt. So at least WLAN would reliable work even after a reboot or reset, without the need for the rfkill-driver. Also the wandboard-rfkill-driver has more advantages, e.g. the rfkill. ;) For those which don't know it, currently, without the wandboard-rfkill-driver, WLAN works only once after power up, but not after the reboot. Thats because the HW doesn't reset the brcm on reset, so after a reboot or reset uploading the firmware fails (because it is already uploaded due to the missing reset of the module). Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] wandboard: Add board revision detection support
Am 24.05.2015 um 16:27 schrieb Fabio Estevam: Hi Stefano and Alexander, On Sun, May 24, 2015 at 4:43 AM, Stefano Babic wrote: Wouldn't it be better to just enable CONFIG_CMD_GPIO and then change the boot-script in the config to something like "if gpio ..." instead of adding something special? Assuming the gpio command works on imx, which I haven't tested or looked up. gpio works - this is really a good idea, moving the check into the script. Fabio, what do you mind ? I think the idea is good, thanks. I wanted to keep consistency with the mx6cuboxi implementation (which was based on TI's implementation suggested by Tom during the review of the mx6cuboxi patches). Also, the gpio script idea would work fine for selecting the dtb file, but not inside checkboard() function, where I print the board revision name. Printing the board revision in the script is as easy as selecting the dtb. Other aspect I thought is the fact that in case we have another revision of the board in the future, I think that C code is more flexible for handling it. Not really. Then it it would need again a patch for the C source. Using the gpio command one could just change the check even by just changing uEnv.txt. Look at how long it now needed until someone did this patch (your patch) for u-boot. So I like the idea of gpio script, but I would prefer to keep the current implementation if possible due to the reasons stated above. I would suggest to change the stuff for mx6cuboxi to use the gpio command too instead of taking the same (imho wrong) approach. But enough said from me, I don't really care. ;) Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] wandboard: Add board revision detection support
Am 23.05.2015 um 02:38 schrieb Vagrant Cascadian: On 2015-05-21, Fabio Estevam wrote: From: Fabio Estevam There are two revisions of wandboard: version B1 and C1. Add the revision detection support, so that the correct dtb file can be automatically loaded. Based on the patch from Richard Hu . Signed-off-by: Fabio Estevam Tested on a Wandboard dual (rev c1) and wandboard quad (rev b1). Tested-By: Vagrant Cascadian --- Changes since v1: - Fixed commit log to 'automatically loaded'. board/wandboard/wandboard.c | 26 +- include/configs/wandboard.h | 8 ++-- Wouldn't it be better to just enable CONFIG_CMD_GPIO and then change the boot-script in the config to something like "if gpio ..." instead of adding something special? Assuming the gpio command works on imx, which I haven't tested or looked up. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 14.08.2014 23:35, schrieb Stephen Warren: On 08/14/2014 02:53 PM, Tom Rini wrote: On Thu, Aug 14, 2014 at 01:50:31PM -0600, Stephen Warren wrote: [snip] uenv.txt is the opposite; it's very U-Boot specific, and more about internal implementation details of U-Boot. In particular, I only see a use-case for uenv.txt on systems that have nowhere to store the U-Boot environment other than in some filesystem. That's the reason the RPi port loads uenv.txt, so the environment can be modified somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead on the Pi? For example, none of the Tegra boards use uEnv.txt since "saveenv" to flash works there. Even with ENV_IS_IN_FAT you need to be in U-Boot to modify the environment (fw_setenv/printenv should be adaptable easily enough I would hope, but aren't today). uEnv.txt is the way for a user to pop the SD card into their PC, tweak the env as needed (or fiddle some bits), eject the card and boot their target. What, you don't link binary-editing the file to fix the CRC? :-P That reminds me that I thought about adding uEnv.sha1 (and CMD_SHA1) to have the same protection (or even better through sha1) as boot.cmd for environments where it makes sense. So in regard to "untrustworthy" sd-cards most boards. ;) Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 14.08.2014 22:53, schrieb Tom Rini: On Thu, Aug 14, 2014 at 01:50:31PM -0600, Stephen Warren wrote: [snip] uenv.txt is the opposite; it's very U-Boot specific, and more about internal implementation details of U-Boot. In particular, I only see a use-case for uenv.txt on systems that have nowhere to store the U-Boot environment other than in some filesystem. That's the reason the RPi port loads uenv.txt, so the environment can be modified somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead on the Pi? For example, none of the Tegra boards use uEnv.txt since "saveenv" to flash works there. Even with ENV_IS_IN_FAT you need to be in U-Boot to modify the environment (fw_setenv/printenv should be adaptable easily enough I would hope, but aren't today). uEnv.txt is the way for a user to pop the SD card into their PC, tweak the env as needed (or fiddle some bits), eject the card and boot their target. Yes, many "developers" today (those which do buy development boards) are having problems to use a serial which most of the time is needed to access the u-boot command line. The reasons are various, most devices people do use don't have a serial anymore, the voltage of the serial changes every few years (12, 5, 3.3 and now 1.8 Volt), sometimes a nullmodem (just 3 wires) is needed, ... Whatever the reason is, sometimes it can be very hard to access the u-boot command line. But most are able to modifying or create a file on disk. ;) Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 14.08.2014 22:08, schrieb Stephen Warren: On 08/14/2014 01:59 PM, Alexander Holler wrote: Am 14.08.2014 21:51, schrieb Stephen Warren: On 08/14/2014 01:38 PM, Alexander Holler wrote: Am 14.08.2014 17:49, schrieb Stephen Warren: On 08/14/2014 02:25 AM, Alexander Holler wrote: As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: "env import -t -r $loadaddr $filesize;" \ "if test -n \"$uenvcmd\"; then " \ "echo \"Running uenvcmd ...\";" \ "run uenvcmd;" \ "fi;" \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. Sure. In most cases changing the predefined available variables is enough. But it's a very hand option if someone wants or needs to do stuff which can't be done by just changing some environment variables (one never knows what ideas people will have). For such presumably non-standard things, why can't the user simply edit $bootcmd, and pre-pend whatever they want? Depends on when the bootcmd will be constructed. Usually that is done after having read uEnv.txt to include variables defined in uEnv.txt in bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be overwritten. What would over-write bootcmd? None of the boards I've looked at auto-generates bootcmd. bootargs perhaps (which is a string passed to the kernel) but not bootargs (which is a U-Boot command sequence that U-Boot executes automatically at boot). If some board does auto-generate bootcmd, I'd suggest that it not. The static bootcmd could execute some kind of user-(or uenv-)set variable and/or the auto-generation of bootcmd could happen before uenv.txt was pulled in, so that whatever was in uenv.txt would have ultimate "power". Ah, yes. Sorry, I confused bootcmd with bootargs (I don't live in u-boot and just fiddle once a year or such with it). But overwriting bootcmd needs to read uEnv.txt in PREBOOT (or how it is named). I originally have read uEnv.txt in the bootcmd itself, so overwriting it didn't work. But I don't want to dive too deep into that discussion, as I think it's up to the board-maintainers to write the config however they want and seem to fit for there users. I've just mentioned the uenvcmd, because it was the first, I've added to my u-boot for the rpi (to have the same interface I use with my other boards). ;) Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Magically determining the correct root
Hello,
Over the years I've seen many error message from beginners because root=
wasn't set or was set wrong. Often they call the cryptic message from
the Linux kernel memory error or something similiar (because they just
look at the stuff after the "init not found").
One of the reason they run into that is because they use a different
partition layout than which is enforced by the board-config.
So here are my 2¢ to give people some more freedom in regard to the
partition layout:
-
...
"find_root=" \
"setenv stdout nulldev;" \
"for i in 0 1 2; do " \
"setexpr rootpart $part + $i;" \
"if ls $hw $dev:$rootpart dev; then " \
"setenv stderr serial;" \
"setenv stdout serial;" \
"exit;" \
"fi;" \
"done;" \
"setenv stdout serial;" \
"setenv rootpart\0" \
"linuxmmc=mmcblk0p\0" \
"set_root=" \
"run find_root;" \
"if test -z \"$rootpart\"; then " \
"echo \"NO ROOT FOUND! (no partition with
directory /dev)\";" \
"setexpr rootpart $part + 1;" \
"fi;" \
"if test $hw = mmc; then " \
"setenv root /dev/${linuxmmc}${rootpart};" \
"else " \
"setenv root /dev/sda${rootpart};" \
"fi;" \
"echo \"root is $root\"\0" \
...
-
What it does is the following:
It uses the variable $hw, $dev, $part and $linuxmmc as input and
$root as output.
- $hw might be mmc, usb or sata (or whatever "ls" does understand
- $dev is the device number (usually 0)
- $part is the partition number where the kernel is loaded from (most of
the time 1 for the first partition)
- $linuxmmc is the linux-name of the mmc-device (e.g. mmcblk0p).
It then searches the partition from which the kernel was loaded from and
the following two partitions for a "/dev" and assumes that will be the
correct root partition.
So, assuming /dev does only exist on the root partition that little
magic supports parition layouts like the following:
- boot (with kernel), root, something else
- root (with kernel), something else
- swap, boot (with kernel), root, something else
- boot (with kernel), swap, root, something else
...
Maybe someone does find usefull.
Regards,
Alexander Holler
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 14.08.2014 21:51, schrieb Stephen Warren: On 08/14/2014 01:38 PM, Alexander Holler wrote: Am 14.08.2014 17:49, schrieb Stephen Warren: On 08/14/2014 02:25 AM, Alexander Holler wrote: As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: "env import -t -r $loadaddr $filesize;" \ "if test -n \"$uenvcmd\"; then " \ "echo \"Running uenvcmd ...\";" \ "run uenvcmd;" \ "fi;" \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. Sure. In most cases changing the predefined available variables is enough. But it's a very hand option if someone wants or needs to do stuff which can't be done by just changing some environment variables (one never knows what ideas people will have). For such presumably non-standard things, why can't the user simply edit $bootcmd, and pre-pend whatever they want? Depends on when the bootcmd will be constructed. Usually that is done after having read uEnv.txt to include variables defined in uEnv.txt in bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be overwritten. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 14.08.2014 17:49, schrieb Stephen Warren: On 08/14/2014 02:25 AM, Alexander Holler wrote: As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: "env import -t -r $loadaddr $filesize;" \ "if test -n \"$uenvcmd\"; then " \ "echo \"Running uenvcmd ...\";" \ "run uenvcmd;" \ "fi;" \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. Sure. In most cases changing the predefined available variables is enough. But it's a very hand option if someone wants or needs to do stuff which can't be done by just changing some environment variables (one never knows what ideas people will have). And as it now seems to be possible to write the environment back to disk too, one should be make sure that uenvcmd will be cleared before writing the environment back to disk. Personally I prefer to not let the bootloader write to any (real) filesystem, but just in case someone does so ... Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 31.07.2014 21:57, schrieb Stephen Warren: Huh, I do see that now. I must have been looking at the content of common/cmd_nvedit.c from the wrong branch, which didn't include that patch. I could have sworn I checked git history too, but evidently not. It is indeed clearly there right before the patches which use it. Sorry for the noise. As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: "env import -t -r $loadaddr $filesize;" \ "if test -n \"$uenvcmd\"; then " \ "echo \"Running uenvcmd ...\";" \ "run uenvcmd;" \ "fi;" \ Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Confusion when starting storage subsystems
Hello, It would make me wonder if nobody else noticed it, but having to use sata init usb start mmc rescan to initialize storage subsystems isn't very convenient (or orthogonal in a more knowledgable looking speak). ;) I don't know the reasons, but I remember that the mmc command to init the subsystem already changed at least once. So there must have been already some thoughts or discussions about that topic. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 06.08.2014 13:18, schrieb Alexander Holler: Am 06.08.2014 12:44, schrieb Måns Rullgård: Alexander Holler writes: Am 06.08.2014 08:43, schrieb Wolfgang Denk: Dear Alexander, In message <53dfdc99.2020...@ahsoftware.de> you wrote: At least I've understood it such that nobody still has an objection=20 against the new feature for "env import -t" (-r). I object if it would be added without maintaining symmetry with "env export". As explained I don't know how to add symmetry. It's impossible to export text concurrently in both formats. What is the problem with ignoring \r on input and not writing it on output? None. Please read the mails before. And just in case it has become difficult to follow this thread because the subject should have changed to something else, I think what Wolfgang Denk wants is an option to extent "env export" to export the environment to text files with CRLF. I've made a suggestion here: http://lists.denx.de/pipermail/u-boot/2014-August/185272.html But as there was no response until now (I'm not impatient, I'm just mentioning it again because I think you've missed about what Wolfgang Denk started to discuss). it's just an assumption from me, I don't have any clue what he means with symmetry in regard to that "-r". And without any consensus I will not spend the time to write the few lines of source to implement that (I don't need it). As written before, I don't even care much if -r for "env export -t" ends up in mainline U-Boot. So there is no problem, Wolfgang Denk and I are just discussing if and how to extend "env export". That is at least how I do now understand this thread about the simple patch I've posted some years ago. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 06.08.2014 12:44, schrieb Måns Rullgård: Alexander Holler writes: Am 06.08.2014 08:43, schrieb Wolfgang Denk: Dear Alexander, In message <53dfdc99.2020...@ahsoftware.de> you wrote: At least I've understood it such that nobody still has an objection=20 against the new feature for "env import -t" (-r). I object if it would be added without maintaining symmetry with "env export". As explained I don't know how to add symmetry. It's impossible to export text concurrently in both formats. What is the problem with ignoring \r on input and not writing it on output? None. Please read the mails before. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 06.08.2014 12:02, schrieb Alexander Holler: Am 06.08.2014 08:43, schrieb Wolfgang Denk: Dear Alexander, In message <53dfdc99.2020...@ahsoftware.de> you wrote: At least I've understood it such that nobody still has an objection=20 against the new feature for "env import -t" (-r). I object if it would be added without maintaining symmetry with "env export". As explained I don't know how to add symmetry. It's impossible to export text concurrently in both formats. And I will not write a patch (I don't need), if I have to assume I'm wasting my time because it will never reach any possible user. So without consensus about what such a symmetry feature for "env export" should be and how it will look like I will not spend the (little) time to write a patch, nor the much large time to discuss the patch afterwards. Maybe it helps to explain my motivation to write the patch in the subject: I've run into the problem once, when I had to use a Windows box to write an uEnv.txt, and it happens extremly seldom that I'm using Windows. But then I've seen several other people running into the same problem (which is extremly hard to identify as is usually invisible). So I though I'm nice and write a patch to help other people (because I can write such a patch and I don't need to spend much time to do so) and everyone will be happy about. So to conclude I don't need the -r for "env import" myself and it just ended up with around a dozen mails where I had to defend and explain the patch. That isn't what motivates to spend time writing "maintainer friendly" patches and to submit them. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 06.08.2014 08:43, schrieb Wolfgang Denk: Dear Alexander, In message <53dfdc99.2020...@ahsoftware.de> you wrote: At least I've understood it such that nobody still has an objection=20 against the new feature for "env import -t" (-r). I object if it would be added without maintaining symmetry with "env export". As explained I don't know how to add symmetry. It's impossible to export text concurrently in both formats. And I will not write a patch (I don't need), if I have to assume I'm wasting my time because it will never reach any possible user. So without consensus about what such a symmetry feature for "env export" should be and how it will look like I will not spend the (little) time to write a patch, nor the much large time to discuss the patch afterwards. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 04.08.2014 12:00, schrieb Måns Rullgård: Alexander Holler writes: Why not just make "env import" treat \r like any other whitespace? It would be a slight change from current behaviour, but the chance that someone actually relies on a trailing \r being part of the value is vanishingly small. There was an objection about such wheh I've first posted the patch whichg already has had the same strong check as the current patch. But I think nobody still has a problem with that, and whatever was said long time ago was based on some misunderstandings about what the patch is for, and how it really works and how the new feature is used. And currently we are only talking if and how enhancing "env export". At least I've understood it such that nobody still has an objection against the new feature for "env import -t" (-r). Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 04.08.2014 08:47, schrieb Alexander Holler: But it would not be really symmetric. The -r for "env import" makes "env import" eat both formats, which means it can be used almost always, but using -r with "env export" would be a decision which always would be wrong for many people. Of course, adding the possibility to export the environment in a system-foreign format (Assuming nobody boots windows using u-boot) doesn't really make a harm, it just adds the danger that people will use -r for "env export" because it is used for "env import" too, which most likely would be wrong for most usage scenarios. Anyway, I don't have any other objections agains a -r for "env export", maybe it could be added to the TODO-list which contains documentation for "env *" too. ;) My slow brain (therefor this second message) now suggests to add e.g. a -w to "env export", where the -w would be mutually exclusive to -t. This would make it clear that it doesn't mean the same as '-t -r' for env import and that using -w means a decision which might be wrong. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 03.08.2014 19:51, schrieb Wolfgang Denk: Dear Alexander, In message <53de658f.5010...@ahsoftware.de> you wrote: Just to clarify: I see uEnv.txt (which only was possible through your env import implementation) as a read-only configuration file for u-boot, This is just one of the many possible usages. And I don't think all the necessary stuff to save a file in all the possible filesystems should end up in u-boot. Modifying filesystems is dangerous. Thius has nothing to do with exporting an environment. The export operation and the writing to the file system are two separate steps. If a file system driver contains write support or not depends on the file system code. For the environment it does not matter. If we have write support, we just use it. So from a u-boot point of view uEnv.txt is a read-only mechanism and I'm happy with it as such. As mentioned, this is but one usage. I think that "env import" / "env export" should be kept symmetric. Using a \r\n instead of \n when -r is used for env export should be something like 4 liner or such. But it would not be really symmetric. The -r for "env import" makes "env import" eat both formats, which means it can be used almost always, but using -r with "env export" would be a decision which always would be wrong for many people. Of course, adding the possibility to export the environment in a system-foreign format (Assuming nobody boots windows using u-boot) doesn't really make a harm, it just adds the danger that people will use -r for "env export" because it is used for "env import" too, which most likely would be wrong for most usage scenarios. Anyway, I don't have any other objections agains a -r for "env export", maybe it could be added to the TODO-list which contains documentation for "env *" too. ;) Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 02.08.2014 23:09, schrieb Alexander Holler: Am 01.08.2014 14:08, schrieb Wolfgang Denk: Should we not, for reasons of symmetry, then also extend "env export" by such a "-r" option? Sorry, but I don't follow the new features of u-boot that closely. Is it already possible to save an exported environment as (text-)file to some storage? Such wasn't possible when I've implemented that -r for "env import" and it doesn't make much sense if an exported environment never reaches users. Just to clarify: I see uEnv.txt (which only was possible through your env import implementation) as a read-only configuration file for u-boot, mainly used to easily configure the kernel-command-line from userspace. Something like grub.cfg or any config for other bootloaders. The (simple) trick with uenvcmd to execute commands is just a handy addition. And I don't think all the necessary stuff to save a file in all the possible filesystems should end up in u-boot. Modifying filesystems is dangerous. So from a u-boot point of view uEnv.txt is a read-only mechanism and I'm happy with it as such. I just did the patch in the subject because it ended up with extremly hard to diagnose problems when someone created an uEnv.txt with CRLF using Windows. E.g. foo=bar in such an uEnv.txt was in fact foo=bar which was feeded to the kernel command line as foo=bar too, and the Linux kernel usually treads carriage returns as a normal character. So it treats bar as something different than bar, leading to various failures. And that underlying problem is almost impossible to see because everything (what a user pastes, kernel output, ...) looks good. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 01.08.2014 14:08, schrieb Wolfgang Denk:
Dear Alexander Holler,
In message <1405352998-7707-2-git-send-email-hol...@ahsoftware.de> you wrote:
When this option is enabled, CRLF is treated like LF when importing environments
from text files, which means CRs ('\r') in front of LFs ('\n') are just ignored.
Drawback of enabling this option is that (maybe exported) variables which have
a trailing CR in their content will get imported without that CR. But this
drawback is very unlikely and the big advantage of letting Windows user create
a *working* uEnv.txt too is likely more welcome.
Should we not, for reasons of symmetry, then also extend "env export"
by such a "-r" option?
Sorry, but I don't follow the new features of u-boot that closely.
Is it already possible to save an exported environment as (text-)file to
some storage? Such wasn't possible when I've implemented that -r for
"env import" and it doesn't make much sense if an exported environment
never reaches users.
Another problem would be to decide in which format to save the
environment. Same magic (e.g. an env var set by "env import") would be
necessary to decided in which format to save the environment.
Regards,
Alexander Holler
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
When this option is enabled, CRLF is treated like LF when importing environments
from text files, which means CRs ('\r') in front of LFs ('\n') are just ignored.
Drawback of enabling this option is that (maybe exported) variables which have
a trailing CR in their content will get imported without that CR. But this
drawback is very unlikely and the big advantage of letting Windows user create
a *working* uEnv.txt too is likely more welcome.
Signed-off-by: Alexander Holler
---
common/cmd_nvedit.c | 19 +++
common/env_common.c | 6 +++---
include/search.h| 3 ++-
lib/hashtable.c | 17 -
4 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index e6c3395..855808c 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -950,11 +950,15 @@ sep_err:
#ifdef CONFIG_CMD_IMPORTENV
/*
- * env import [-d] [-t | -b | -c] addr [size]
+ * env import [-d] [-t [-r] | -b | -c] addr [size]
* -d: delete existing environment before importing;
* otherwise overwrite / append to existion definitions
* -t: assume text format; either "size" must be given or the
* text data must be '\0' terminated
+ * -r: handle CRLF like LF, that means exported variables with
+ * a content which ends with \r won't get imported. Used
+ * to import text files created with editors which are using CRLF
+ * for line endings. Only effective in addition to -t.
* -b: assume binary format ('\0' separated, "\0\0" terminated)
* -c: assume checksum protected environment format
* addr: memory address to read from
@@ -970,6 +974,7 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
int chk = 0;
int fmt = 0;
int del = 0;
+ int crlf_is_lf = 0;
size_t size;
cmd = *argv;
@@ -994,6 +999,9 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
goto sep_err;
sep = '\n';
break;
+ case 'r': /* handle CRLF like LF */
+ crlf_is_lf = 1;
+ break;
case 'd':
del = 1;
break;
@@ -1009,6 +1017,9 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
if (!fmt)
printf("## Warning: defaulting to text format\n");
+ if (sep != '\n' && crlf_is_lf )
+ crlf_is_lf = 0;
+
addr = simple_strtoul(argv[0], NULL, 16);
ptr = map_sysmem(addr, 0);
@@ -1050,8 +1061,8 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
ptr = (char *)ep->data;
}
- if (himport_r(&env_htab, ptr, size, sep, del ? 0 : H_NOCLEAR, 0,
- NULL) == 0) {
+ if (himport_r(&env_htab, ptr, size, sep, del ? 0 : H_NOCLEAR,
+ crlf_is_lf, 0, NULL) == 0) {
error("Environment import failed: errno = %d\n", errno);
return 1;
}
@@ -1180,7 +1191,7 @@ static char env_help_text[] =
#endif
#endif
#if defined(CONFIG_CMD_IMPORTENV)
- "env import [-d] [-t | -b | -c] addr [size] - import environment\n"
+ "env import [-d] [-t [-r] | -b | -c] addr [size] - import environment\n"
#endif
"env print [-a | name ...] - print environment\n"
#if defined(CONFIG_CMD_RUN)
diff --git a/common/env_common.c b/common/env_common.c
index cd7b4cd..af372a6 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -120,7 +120,7 @@ void set_default_env(const char *s)
}
if (himport_r(&env_htab, (char *)default_environment,
- sizeof(default_environment), '\0', flags,
+ sizeof(default_environment), '\0', flags, 0,
0, NULL) == 0)
error("Environment import failed: errno = %d\n", errno);
@@ -137,7 +137,7 @@ int set_default_vars(int nvars, char * const vars[])
*/
return himport_r(&env_htab, (const char *)default_environment,
sizeof(default_environment), '\0',
- H_NOCLEAR | H_INTERACTIVE, nvars, vars);
+ H_NOCLEAR | H_INTERACTIVE, 0, nvars, vars);
}
#ifdef CONFIG_ENV_AES
@@ -214,7 +214,7 @@ int env_import(const char *buf, int check)
return ret;
}
- if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0,
+ if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0, 0,
[U-Boot] [PATCH 3/4] am335x_evm: handle import of environments in files with CRLF as line endings
Use the new option -r for env import.
Signed-off-by: Alexander Holler
---
include/configs/am335x_evm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index a48b386..34d27c6 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -117,7 +117,7 @@
"bootenv=uEnv.txt\0" \
"loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
"importbootenv=echo Importing environment from mmc ...; " \
- "env import -t $loadaddr $filesize\0" \
+ "env import -t -r $loadaddr $filesize\0" \
"ramargs=setenv bootargs console=${console} " \
"${optargs} " \
"root=${ramroot} " \
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Add option -r to env import to allow import of text files with CRLF as line endings
Hello, time passed by, the usage of uEnv.txt is now more widespread and some maintainers might be more experienced. So now maybe they understand why it might be a good idea to let Windows users create a *working* uEnv.txt too. So here is my second and last attempt. I've added patches for some board configs too. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] omap3_beagle: handle import of environments in files with CRLF as line endings
Use the new option -r for env import.
Signed-off-by: Alexander Holler
---
include/configs/omap3_beagle.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 3782049..9ba031d 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -195,7 +195,7 @@
"bootenv=uEnv.txt\0" \
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
"importbootenv=echo Importing environment from mmc ...; " \
- "env import -t $loadaddr $filesize\0" \
+ "env import -t -r $loadaddr $filesize\0" \
"ramargs=setenv bootargs console=${console} " \
"${optargs} " \
"mpurate=${mpurate} " \
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] rpi_b: handle import of environments in files with CRLF as line endings
Use the new option -r for env import.
Signed-off-by: Alexander Holler
---
include/configs/rpi_b.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h
index ff48598..60f2489 100644
--- a/include/configs/rpi_b.h
+++ b/include/configs/rpi_b.h
@@ -98,7 +98,7 @@
#define CONFIG_SYS_CONSOLE_IS_IN_ENV
#define CONFIG_PREBOOT \
"if load mmc 0:1 ${loadaddr} /uEnv.txt; then " \
- "env import -t ${loadaddr} ${filesize}; " \
+ "env import -t -r ${loadaddr} ${filesize}; " \
"fi"
#define ENV_DEVICE_SETTINGS \
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Graphics Library?
Am 21.01.2013 02:29, schrieb Alexander Holler: Am 18.01.2013 21:57, schrieb Simon Glass: Hi, On Fri, Jan 18, 2013 at 7:47 AM, Steve Strobel wrote: Maybe the USB flash drive used for recovery could contain not only the image to be written to flash, but also a bootable OS image used to provide on-screen messages during the recovery process. You would still need the read-only code to provide enough of a UI to boot from the USB flash drive, but the rest of the messages could be generated by that OS. Yes that's exactly what we do...and yes we still need the read-only code to provide a minimal GUI to get things started. That was the subject of this thread. The recovery mode GUI is provided by a Linux user space tool, but we need to get there first... Hmm, maybe the kernel people are more open to such an idea. It would just be an additional module/driver and would offer other possible use case too, much more than if such a library would be added to U-Boot. A minimal kernel is doable with less than 2MB and that Graphics Library could be implemented as module (statically linked) which uses the framebuffer, so no userspace would be necessary at all. Combined e.g. with lua to use some syscalls for loading files, that could be imho useful for many other task. E.g. to get rid of bootloaders on UEFI systems or to replace initrd's at all (lua in kernel instead of a shell in userspace). Ok, thats stuff which likely would provoke heated discussions, but at least I would like such. ;) But something like lua isn't really needed for the above problem. Hardcoding the few steps (e.g. font and picture loading) necessary to lead users to insert an usb-stick is imho a pragmatic solution too. The kernel devs most likely wouldn't want that (because it's not a generic solution), but thats live. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cc-list modified?
Am 21.01.2013 19:19, schrieb Scott Wood: On 01/20/2013 08:53:05 PM, Alexander Holler wrote: Am 18.01.2013 17:32, schrieb Alexander Holler: Am 18.01.2013 04:17, schrieb Scott Wood: On 01/17/2013 07:22:57 PM, Alexander Holler wrote: Am 18.01.2013 01:50, schrieb Alexander Holler: (...) Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;) (...) I've just wondered what happened to the cc-list of that mail I sent. I've send it with CC: Simon Glass , U-Boot Mailing List , Jeroen Hofstee and received it just with Cc: U-Boot Mailing List , Jeroen Hofstee Looks like mailman is confused. Yes, this is a very old known bug in mailman: https://bugs.launchpad.net/mailman/+bug/266161 Thanks for the pointer. I've now disabled that "avoid duplicates" option as the bug suggests. Good to know that such seems to be needed for mailman lists. I've just checked my last post, and it happened again. What do you mean by "it"? Your address got dropped from CC, or Simon's? This time it was Steve Strobel. Simon was in to. So disabling that knob (avoid duplicates) in the (my) preferences doesn't help. It's the preferences of the person who's being dropped from the CC list that matter (supposedly). Ah, thats the (broken) logic. Mailman drops such people from every CC, not just from mails it sends directly to them. Not what I would have expected as it breaks cc-lists in threads totally. Looking at those two mails, I think mailman just deletes every CC in the list which is before the address of the mailing list itself. I'm pretty sure I've seen droppage that wasn't consistent with that rule (e.g. the list was in To:). Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cc-list modified?
Am 18.01.2013 17:32, schrieb Alexander Holler: Am 18.01.2013 04:17, schrieb Scott Wood: On 01/17/2013 07:22:57 PM, Alexander Holler wrote: Am 18.01.2013 01:50, schrieb Alexander Holler: (...) Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;) (...) I've just wondered what happened to the cc-list of that mail I sent. I've send it with CC: Simon Glass , U-Boot Mailing List , Jeroen Hofstee and received it just with Cc: U-Boot Mailing List , Jeroen Hofstee Looks like mailman is confused. Yes, this is a very old known bug in mailman: https://bugs.launchpad.net/mailman/+bug/266161 Thanks for the pointer. I've now disabled that "avoid duplicates" option as the bug suggests. Good to know that such seems to be needed for mailman lists. I've just checked my last post, and it happened again. So disabling that knob (avoid duplicates) in the (my) preferences doesn't help. Looking at those two mails, I think mailman just deletes every CC in the list which is before the address of the mailing list itself. so CC: a, u-boot@lists.denx.de, b becomes CC: u-boot@lists.denx.de, b Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Graphics Library?
Am 18.01.2013 21:57, schrieb Simon Glass: > Hi, > > On Fri, Jan 18, 2013 at 7:47 AM, Steve Strobel > wrote: >> Maybe the USB flash drive used for recovery could contain not only the image >> to be written to flash, but also a bootable OS image used to provide >> on-screen messages during the recovery process. You would still need the >> read-only code to provide enough of a UI to boot from the USB flash drive, >> but the rest of the messages could be generated by that OS. > > Yes that's exactly what we do...and yes we still need the read-only > code to provide a minimal GUI to get things started. That was the > subject of this thread. The recovery mode GUI is provided by a Linux > user space tool, but we need to get there first... Hmm, maybe the kernel people are more open to such an idea. It would just be an additional module/driver and would offer other possible use case too, much more than if such a library would be added to U-Boot. A minimal kernel is doable with less than 2MB and that Graphics Library could be implemented as module (statically linked) which uses the framebuffer, so no userspace would be necessary at all. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cc-list modified?
Am 18.01.2013 04:17, schrieb Scott Wood: On 01/17/2013 07:22:57 PM, Alexander Holler wrote: Am 18.01.2013 01:50, schrieb Alexander Holler: (...) Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;) (...) I've just wondered what happened to the cc-list of that mail I sent. I've send it with CC: Simon Glass , U-Boot Mailing List , Jeroen Hofstee and received it just with Cc: U-Boot Mailing List , Jeroen Hofstee Looks like mailman is confused. Yes, this is a very old known bug in mailman: https://bugs.launchpad.net/mailman/+bug/266161 Thanks for the pointer. I've now disabled that "avoid duplicates" option as the bug suggests. Good to know that such seems to be needed for mailman lists. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Slow tftp boot with Ubuntu 12.04 tftp server
Am 18.01.2013 11:16, schrieb David Aldrich: > >> Try setting the max. blocksize explicit, e.g. I'm using -B 1460 here. It >> depends >> on the used tftp-server. > > Hi Alexander > > Thanks for your reply. Please will you confirm the exact syntax? I tried: > > # tftp -B 1460 0x8200 tci6614-evm.dtb > tftpboot - boot image via network using TFTP protocol > > Usage: > tftpboot [loadAddress] [[hostIPaddr:]bootfilename] > > I also tried: > > setenv tftpblocksize 1460 > > but that made no difference. > > What is the correct way of specifying the block size please? That -B n is an option for the server, which is in my case (not Ubuntu) called in.tftpd and comes from the package tftpd-hpa (a Linux port of the OpenBSD TFTP server). So you have to change that on your Ubuntu box. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Slow tftp boot with Ubuntu 12.04 tftp server
Am 17.01.2013 12:19, schrieb David Aldrich: Hi I am using an Advantech TMX320TCI6614 EVM to develop code for an ARM core on a TI C66x device. The ARM core runs: U-Boot 2011.06-2-gc4611c1-dirty (May 30 2012 - 15:38:01) I have booted this target card for several months from a tftp server running under Ubuntu 10.04, with no problems. But, this week, I have tried to move to a tftp server that runs on a different machine running Ubuntu 12.04 LTS. Since moving to Ubuntu 12.04 the tftp download is very slow, although it does succeed eventually. I have tried getting the boot files using a tftp client running on another Ubuntu host and the download is fast. Please can anyone suggest a reason for the slow download when using the EVM with the 12.04 server? Try setting the max. blocksize explicit, e.g. I'm using -B 1460 here. It depends on the used tftp-server. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] cc-list modified?
Am 18.01.2013 01:50, schrieb Alexander Holler: (...) Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;) (...) I've just wondered what happened to the cc-list of that mail I sent. I've send it with CC: Simon Glass , U-Boot Mailing List , Jeroen Hofstee and received it just with Cc: U-Boot Mailing List , Jeroen Hofstee Looks like mailman is confused. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Graphics Library?
Am 16.01.2013 20:46, schrieb Wolfgang Denk: Dear Simon Glass, In message you wrote: We are currently using a very rudimentary graphics features attached to U-Boot. It can only display bitmap images. We use this in Chromium to composite a display for the various screens we need to display in U-Boot. Unfortunately the graphics screens get quite large when using multiple languages since they are pre-rendered. Is there any interest in a simply graphics library in U-Boot, that can display things on the screen? We already have bitmap support, but could perhaps add outline font support (e.g. freetype) as well. This might allow display of simple boot menus or booting information. A board could create a structure containing a list of things to display (text, bitmaps) and pass it to the graphics library for rendering using existing functions and the new font support. This sounds like a nice feature. Initially. Then I start wondering if this really belongs into a boot loader. Instead of doing fancy graphics stuff, we should IMO rather focus on booting the OS of your choice really fast, and let this do the fancy GUIs. Or? Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;) And I think too that all this can be handled by adding a kernel (e.g. with integrated minimal initramfs) to u-boot. At least that is how I have handled such in the past. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] The way the list manages patch submission
Am 04.08.2012 18:55, schrieb Karl O. Pinc: So perhaps the u-boot list default that has duplicate elimination turned on, where other lists do not, is factor contributing to the confusion. I've never had Some mail-servers have that feature enabled by default too. E.g. cyrus-imapd (called duplicate delivery suppression there). So if you get a mail by cc and from a list, usually the one from list doesn't show up because it is delivered after the cc'ed one. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] beagle: handle import of environments in files with CRLF as line endings
On 14.05.2012 20:45, Marek Vasut wrote: Dear Alexander Holler, Am 14.05.2012 18:02, schrieb Tom Rini: On Sun, May 13, 2012 at 02:50:07PM +0200, Alexander Holler wrote: Use the new option -r for env import. Signed-off-by: Alexander Holler While I am sympathetic, the right answer is to tell users to use a text editor that can save with UNIX-style newlines. NAK. As long as you don't commit another wrong patch with me as author What happened? Someone, which I never met in realitiy before, greeted me at the FOSDEM as the one who got famous (in some circles, don't know) for tty02 (0 as in zeroMAP, the well known processor from TI). Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] beagle: handle import of environments in files with CRLF as line endings
Am 14.05.2012 18:02, schrieb Tom Rini: On Sun, May 13, 2012 at 02:50:07PM +0200, Alexander Holler wrote: Use the new option -r for env import. Signed-off-by: Alexander Holler While I am sympathetic, the right answer is to tell users to use a text editor that can save with UNIX-style newlines. NAK. As long as you don't commit another wrong patch with me as author, I accept it and stop, as already promised, with patches. Regards Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] beagle: handle import of environments in files with CRLF as line endings
Am 14.05.2012 11:07, schrieb Alexander Holler:
Am 13.05.2012 23:38, schrieb Wolfgang Denk:
Dear Alexander,
In message<4fb01720.90...@ahsoftware.de> you wrote:
What exactly are such error modes, by the way? I would expect that
trailing white space is pretty much harmless for most variable
settings?
The problem already starts in u-boot itself:
a="b\r"
I'm not sure if \r on the u-boot-cmdline does work, but you know what I
mean.
$a=="b"
is false
fatload $a
fails (if the file is named 'b').
...
And
a="1\r"
isn't a number. So anything which expects a number will fail. E.g.
fatls usb 0:${a}
and every arithmetic which uses ${a}
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] beagle: handle import of environments in files with CRLF as line endings
Am 13.05.2012 23:38, schrieb Wolfgang Denk: Dear Alexander, In message<4fb01720.90...@ahsoftware.de> you wrote: What exactly are such error modes, by the way? I would expect that trailing white space is pretty much harmless for most variable settings? The problem already starts in u-boot itself: a="b\r" I'm not sure if \r on the u-boot-cmdline does work, but you know what I mean. $a=="b" is false fatload $a fails (if the file is named 'b'). ... Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] beagle: handle import of environments in files with CRLF as line endings
Am 13.05.2012 23:38, schrieb Wolfgang Denk: Dear Alexander, In message<4fb01720.90...@ahsoftware.de> you wrote: Sorry, it seems you just are unable or yiu don't want to understand the problem. So here is my last message on this topic, trying to explain it for you. I'm sorry you are giving up so early, just one resubmit before getting this into an acceptable state. So one just tells the user(s) that if they want to change some option they just have to create a text file on a specific place which contains a line like e.g. I guess this is the point where the problem starts. You should not write anywhere "they just have to create a text file", because "a text file" is not a precise enough definition of the required input format. The only problem is that such a description currently only works for Linux users. ... The problem is not Windows users versus Linux users here. The problem is unsufficient information. ... I don't know with what devices and users you are dealing, but there are some people out in the wild which don't know (much) about Linux, or even about the difference in line endings between text files creates using Windows or Linux. Some of them even just want to use their device. In either case, people are usually pretty good in following pre-canned recipies for doing things. Instead of "create a text file" one could for example document that "a UNIX style text file, i. e. with only "\n" line endings (and not the DOS-derived "\r\n" line endings) is needed". One could add some description that "on Windows systems, the command ... can be used to convert a DOS file into this format" (and provide a URL where to get this tool), "while on UNIX systems like Linux the dos2unix tool can be used". If you then add an example suitable for copy& paste you can solve a very large percentage of the propblems you see now. Sorry, but you are just describing one of the oldest dreams (not only) in IT. You can write whatever you wish, users are able to not read it, to misread it, to ignore it, not to understand it or it will get missing in an one-line copy of the original multine description. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] beagle: handle import of environments in files with CRLF as line endings
On 13.05.2012 20:57, Marek Vasut wrote: Dear Wolfgang Denk, Dear Marek Vasut, In message<201205131909.49488.marek.va...@gmail.com> you wrote: - "env import -t $loadaddr $filesize\0" \ + "env import -t -r $loadaddr $filesize\0" \ Not everyone importing env on beagle use broken tools ;-) It's not a problem of using broken tools - the problem is of ignorant people _not_ using decade old, working tools like dos2unix if they need them. tr -d '\r' won't work? :-) As I mentionewd a coule of times before, I am seriously tempted to ignore this "problem". Can't the wincrap people be taught to use cygwin? Or possibly some Windows (R) (C)(TM)(???) rebuilt version of tr -d '\r' ? Sorry, it seems you just are unable or yiu don't want to understand the problem. So here is my last message on this topic, trying to explain it for you. env import -t is a handy solution to give users (not only devs) a possibility to modify variables (options) used to boot some OS. They don't have to deal with the u-boot command-line and, depending how it's used, env import -t is an alternative to persistent modify the env without the need for NAND. So one just tells the user(s) that if they want to change some option they just have to create a text file on a specific place which contains a line like e.g. foo=bar The only problem is that such a description currently only works for Linux users. I don't know with what devices and users you are dealing, but there are some people out in the wild which don't know (much) about Linux, or even about the difference in line endings between text files creates using Windows or Linux. Some of them even just want to use their device. And in addition, the resulting problems hare very hard to diagnose, because there will be no obvious error message when something contains a trailing CR. It would be interesting how long you would need to diagnose such a problem without knowing about that problem, but we now will never know. Now I needed about 10 mails to describe a problem from which I thought it's totally obvious. Sorry, but I accept that I'm totally unable to deal with this list in any, for me reasonable, time frame. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] beagle: handle import of environments in files with CRLF as line endings
On 13.05.2012 20:52, Marek Vasut wrote:
Dear Alexander Holler,
On 13.05.2012 19:09, Marek Vasut wrote:
Dear Alexander Holler,
Use the new option -r for env import.
Signed-off-by: Alexander Holler
---
include/configs/omap3_beagle.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h index ddeb414..d8b10c2 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -258,7 +258,7 @@
"bootenv=uEnv.txt\0" \
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
"importbootenv=echo Importing environment from mmc ...; " \
- "env import -t $loadaddr $filesize\0" \
+ "env import -t -r $loadaddr $filesize\0" \
Not everyone importing env on beagle use broken tools ;-)
Who said that?
You impose your -r option on all beagle users. That means everyone (even those
with not-broken) tools will now use it (unless they replaced their env).
Yes, and now they all will get doomed by ignored CRs before LFs.
Anyway, just ignore those patches, it was lost time from the beginning
and I should have known it better.
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] beagle: handle import of environments in files with CRLF as line endings
On 13.05.2012 19:09, Marek Vasut wrote:
Dear Alexander Holler,
Use the new option -r for env import.
Signed-off-by: Alexander Holler
---
include/configs/omap3_beagle.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h index ddeb414..d8b10c2 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -258,7 +258,7 @@
"bootenv=uEnv.txt\0" \
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
"importbootenv=echo Importing environment from mmc ...; " \
- "env import -t $loadaddr $filesize\0" \
+ "env import -t -r $loadaddr $filesize\0" \
Not everyone importing env on beagle use broken tools ;-)
Who said that?
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v2] Add option -r to env import to allow import of text files with CRLF as line endings
When this option is enabled, CRLF is treated like LF when importing environments
from text files, which means CRs ('\r') in front of LFs ('\n') are just ignored.
Drawback of enabling this option is that (maybe exported) variables which have
a trailing CR in their content will get imported without that CR.
Signed-off-by: Alexander Holler
---
common/cmd_nvedit.c | 17 ++---
common/env_common.c |4 ++--
include/search.h|2 +-
lib/hashtable.c | 17 -
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index e1ccdd8..f136953 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -793,11 +793,15 @@ sep_err:
#ifdef CONFIG_CMD_IMPORTENV
/*
- * env import [-d] [-t | -b | -c] addr [size]
+ * env import [-d] [-t [-r] | -b | -c] addr [size]
* -d: delete existing environment before importing;
* otherwise overwrite / append to existion definitions
* -t: assume text format; either "size" must be given or the
* text data must be '\0' terminated
+ * -r: handle CRLF like LF, that means exported variables with
+ * a content which ends with \r won't get imported. Used
+ * to import text files created with editors which are using CRLF
+ * for line endings. Only effective in addition to -t.
* -b: assume binary format ('\0' separated, "\0\0" terminated)
* -c: assume checksum protected environment format
* addr: memory address to read from
@@ -812,6 +816,7 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
int chk = 0;
int fmt = 0;
int del = 0;
+ int crlf_is_lf = 0;
size_t size;
cmd = *argv;
@@ -836,6 +841,9 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
goto sep_err;
sep = '\n';
break;
+ case 'r': /* handle CRLF like LF */
+ crlf_is_lf = 1;
+ break;
case 'd':
del = 1;
break;
@@ -851,6 +859,9 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
if (!fmt)
printf("## Warning: defaulting to text format\n");
+ if (sep != '\n' && crlf_is_lf )
+ crlf_is_lf = 0;
+
addr = (char *)simple_strtoul(argv[0], NULL, 16);
if (argc == 2) {
@@ -888,7 +899,7 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
addr = (char *)ep->data;
}
- if (himport_r(&env_htab, addr, size, sep, del ? 0 : H_NOCLEAR) == 0) {
+ if (himport_r(&env_htab, addr, size, sep, del ? 0 : H_NOCLEAR,
crlf_is_lf) == 0) {
error("Environment import failed: errno = %d\n", errno);
return 1;
}
@@ -974,7 +985,7 @@ U_BOOT_CMD(
#if defined(CONFIG_CMD_GREPENV)
"env grep string [...] - search environment\n"
#endif
- "env import [-d] [-t | -b | -c] addr [size] - import environment\n"
+ "env import [-d] [-t [-r] | | -b | -c] addr [size] - import
environment\n"
"env print [name ...] - print environment\n"
#if defined(CONFIG_CMD_RUN)
"env run var [...] - run commands in an environment variable\n"
diff --git a/common/env_common.c b/common/env_common.c
index c33d22d..9b50ffe 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -182,7 +182,7 @@ void set_default_env(const char *s)
}
if (himport_r(&env_htab, (char *)default_environment,
- sizeof(default_environment), '\0', 0) == 0)
+ sizeof(default_environment), '\0', 0, 0) == 0)
error("Environment import failed: errno = %d\n", errno);
gd->flags |= GD_FLG_ENV_READY;
@@ -207,7 +207,7 @@ int env_import(const char *buf, int check)
}
}
- if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0)) {
+ if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0, 0)) {
gd->flags |= GD_FLG_ENV_READY;
return 1;
}
diff --git a/include/search.h b/include/search.h
index ef53edb..053cf07 100644
--- a/include/search.h
+++ b/include/search.h
@@ -96,7 +96,7 @@ extern ssize_t hexport_r(struct hsearch_data *__htab,
extern int himport_r(struct hsearch_data *__htab,
const char *__env, size_t __size, const char __sep,
-int __flag);
+int __flag, int __crlf_is_lf);
/* Flags for
[U-Boot] [PATCH 2/2] beagle: handle import of environments in files with CRLF as line endings
Use the new option -r for env import.
Signed-off-by: Alexander Holler
---
include/configs/omap3_beagle.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index ddeb414..d8b10c2 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -258,7 +258,7 @@
"bootenv=uEnv.txt\0" \
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
"importbootenv=echo Importing environment from mmc ...; " \
- "env import -t $loadaddr $filesize\0" \
+ "env import -t -r $loadaddr $filesize\0" \
"ramargs=setenv bootargs console=${console} " \
"${optargs} " \
"mpurate=${mpurate} " \
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Add option -r to env import to allow import of text files with CRLF as line endings
When this option is enabled, CRLF is treated like LF when importing environments
from text files, which means CRs ('\r') in front of LFs ('\n') are just ignored.
Drawback of enabling this option is that (maybe exported) variables which have
a trailing CR in their content will get imported without that CR.
Signed-off-by: Alexander Holler
---
common/cmd_nvedit.c | 17 ++---
common/env_common.c |4 ++--
include/search.h|2 +-
lib/hashtable.c | 23 +++
4 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index e1ccdd8..f136953 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -793,11 +793,15 @@ sep_err:
#ifdef CONFIG_CMD_IMPORTENV
/*
- * env import [-d] [-t | -b | -c] addr [size]
+ * env import [-d] [-t [-r] | -b | -c] addr [size]
* -d: delete existing environment before importing;
* otherwise overwrite / append to existion definitions
* -t: assume text format; either "size" must be given or the
* text data must be '\0' terminated
+ * -r: handle CRLF like LF, that means exported variables with
+ * a content which ends with \r won't get imported. Used
+ * to import text files created with editors which are using CRLF
+ * for line endings. Only effective in addition to -t.
* -b: assume binary format ('\0' separated, "\0\0" terminated)
* -c: assume checksum protected environment format
* addr: memory address to read from
@@ -812,6 +816,7 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
int chk = 0;
int fmt = 0;
int del = 0;
+ int crlf_is_lf = 0;
size_t size;
cmd = *argv;
@@ -836,6 +841,9 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
goto sep_err;
sep = '\n';
break;
+ case 'r': /* handle CRLF like LF */
+ crlf_is_lf = 1;
+ break;
case 'd':
del = 1;
break;
@@ -851,6 +859,9 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
if (!fmt)
printf("## Warning: defaulting to text format\n");
+ if (sep != '\n' && crlf_is_lf )
+ crlf_is_lf = 0;
+
addr = (char *)simple_strtoul(argv[0], NULL, 16);
if (argc == 2) {
@@ -888,7 +899,7 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
addr = (char *)ep->data;
}
- if (himport_r(&env_htab, addr, size, sep, del ? 0 : H_NOCLEAR) == 0) {
+ if (himport_r(&env_htab, addr, size, sep, del ? 0 : H_NOCLEAR,
crlf_is_lf) == 0) {
error("Environment import failed: errno = %d\n", errno);
return 1;
}
@@ -974,7 +985,7 @@ U_BOOT_CMD(
#if defined(CONFIG_CMD_GREPENV)
"env grep string [...] - search environment\n"
#endif
- "env import [-d] [-t | -b | -c] addr [size] - import environment\n"
+ "env import [-d] [-t [-r] | | -b | -c] addr [size] - import
environment\n"
"env print [name ...] - print environment\n"
#if defined(CONFIG_CMD_RUN)
"env run var [...] - run commands in an environment variable\n"
diff --git a/common/env_common.c b/common/env_common.c
index c33d22d..9b50ffe 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -182,7 +182,7 @@ void set_default_env(const char *s)
}
if (himport_r(&env_htab, (char *)default_environment,
- sizeof(default_environment), '\0', 0) == 0)
+ sizeof(default_environment), '\0', 0, 0) == 0)
error("Environment import failed: errno = %d\n", errno);
gd->flags |= GD_FLG_ENV_READY;
@@ -207,7 +207,7 @@ int env_import(const char *buf, int check)
}
}
- if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0)) {
+ if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0, 0)) {
gd->flags |= GD_FLG_ENV_READY;
return 1;
}
diff --git a/include/search.h b/include/search.h
index ef53edb..053cf07 100644
--- a/include/search.h
+++ b/include/search.h
@@ -96,7 +96,7 @@ extern ssize_t hexport_r(struct hsearch_data *__htab,
extern int himport_r(struct hsearch_data *__htab,
const char *__env, size_t __size, const char __sep,
-int __flag);
+int __flag, int __crlf_is_lf);
/* Flags for
Re: [U-Boot] [PATCH] Ignore all Carriage Returns when importing an environment.
Hello, Am 12.05.2012 23:18, schrieb Wolfgang Denk: Thanks - but it adds restrictions to doing perfectly valid things. I see the disadvantages significantly bigger than what we can win - keep in mind, that dealing wqith DOS line endings is a topic that is decades old. Not dealing with them too. ;) Two other solutions come to mind: Expanding the if( '\r' ) so that it only removes CRs if they are before LF or make \r possible in import and use \r in export. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Ignore all Carriage Returns when importing an environment.
Am 12.05.2012 23:21, schrieb Wolfgang Denk: Dear Alexander Holler, In message<4faeb5c2.40...@ahsoftware.de> you wrote: In the good old days (tm) with line printers and almost endless paper from dead trees, CRLF instead only LF as line endings in text files did made sense. It still makes a lot of sense in tty output. Guess how all the one-line status status lines are being printed? That's why I hinted the line printers in response to "crappy software". Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Ignore all Carriage Returns when importing an environment.
Am 12.05.2012 20:37, schrieb Marek Vasut: Dear Alexander Holler, Am 12.05.2012 18:08, schrieb Marek Vasut: Dear Alexander Holler, Am 12.05.2012 16:46, schrieb Marek Vasut: Dear Alexander Holler, Am 12.05.2012 08:17, schrieb Marek Vasut: Dear Alexander Holler, This is used for compatibility with text files which are using CRLF instead of LF as the end of a line. Signed-off-by: Alexander Holler Why don't you run the file trough dos2unix or tr -d '\r' ? Because my files don't contain CRs. ;) s/you/someone else/ :) Try to explain a windows user that a text file should not contain carriage returns and how he can achieve that. You'll do it once, maybe twice, than you will surrender. ;) But you're fixing the problem at a wrong place, aren't you? Besides, removing \r might harm some environments, don't you think? No, there is no other layer between the user and that function. Anyway, as already said, I don't care, just had this patch lying around a year and I finally surrendered to post it here (in favor of those users). But it seems I was right in not posting it. ;) Don't get me wrong, I'm not opposed to this patch, nor I want to demotivate you in further submissions. I'm just trying to figure out if actually surrending to crappy software on one side is a good move on our side. I'd prefer to get more oppinions from other people actually, I don't want the guilt to fall on me :-) In the good old days (tm) with line printers and almost endless paper from dead trees, CRLF instead only LF as line endings in text files did made sense. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Ignore all Carriage Returns when importing an environment.
Am 12.05.2012 18:08, schrieb Marek Vasut: > Dear Alexander Holler, > >> Am 12.05.2012 16:46, schrieb Marek Vasut: >>> Dear Alexander Holler, >>> >>>> Am 12.05.2012 08:17, schrieb Marek Vasut: >>>>> Dear Alexander Holler, >>>>> >>>>>> This is used for compatibility with text files which are >>>>>> using CRLF instead of LF as the end of a line. >>>>>> >>>>>> Signed-off-by: Alexander Holler >>>>> >>>>> Why don't you run the file trough dos2unix or tr -d '\r' ? >>>> >>>> Because my files don't contain CRs. ;) >>> >>> s/you/someone else/ :) >> >> Try to explain a windows user that a text file should not contain >> carriage returns and how he can achieve that. >> >> You'll do it once, maybe twice, than you will surrender. ;) > > But you're fixing the problem at a wrong place, aren't you? Besides, removing > \r > might harm some environments, don't you think? No, there is no other layer between the user and that function. Anyway, as already said, I don't care, just had this patch lying around a year and I finally surrendered to post it here (in favor of those users). But it seems I was right in not posting it. ;) Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Ignore all Carriage Returns when importing an environment.
Am 12.05.2012 16:46, schrieb Marek Vasut: Dear Alexander Holler, Am 12.05.2012 08:17, schrieb Marek Vasut: Dear Alexander Holler, This is used for compatibility with text files which are using CRLF instead of LF as the end of a line. Signed-off-by: Alexander Holler Why don't you run the file trough dos2unix or tr -d '\r' ? Because my files don't contain CRs. ;) s/you/someone else/ :) Try to explain a windows user that a text file should not contain carriage returns and how he can achieve that. You'll do it once, maybe twice, than you will surrender. ;) Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Ignore all Carriage Returns when importing an environment.
Am 12.05.2012 08:17, schrieb Marek Vasut:
Dear Alexander Holler,
This is used for compatibility with text files which are
using CRLF instead of LF as the end of a line.
Signed-off-by: Alexander Holler
Why don't you run the file trough dos2unix or tr -d '\r' ?
Because my files don't contain CRs. ;)
Regards,
Alexander
---
lib/hashtable.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/lib/hashtable.c b/lib/hashtable.c
index abd61c8..6e146ce 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -623,9 +623,9 @@ ssize_t hexport_r(struct hsearch_data *htab, const char
sep, * (entries separated by newline characters).
*
* To allow for nicely formatted text input, leading white space
- * (sequences of SPACE and TAB chars) is ignored, and entries starting
- * (after removal of any leading white space) with a '#' character are
- * considered comments and ignored.
+ * (sequences of SPACE and TAB chars) is ignored, all Carriage Returns
+ * are ignored and entries starting (after removal of any leading white
+ * space) with a '#' character are considered comments and ignored.
*
* [NOTE: this means that a variable name cannot start with a '#'
* character.]
@@ -642,6 +642,7 @@ int himport_r(struct hsearch_data *htab,
const char *env, size_t size, const char sep, int flag)
{
char *data, *sp, *dp, *name, *value;
+ unsigned ignored_crs;
/* Test for correct arguments. */
if (htab == NULL) {
@@ -698,6 +699,17 @@ int himport_r(struct hsearch_data *htab,
}
}
+ /* Remove all Carriage Returns */
+ ignored_crs = 0;
+ for(;dp< data + size&& *dp; ++dp) {
+ if( *dp == '\r' )
+ ++ignored_crs;
+ else if(ignored_crs)
+ *(dp-ignored_crs) = *dp;
+ }
+ size -= ignored_crs;
+ dp = data;
+
/* Parse environment; allow for '\0' and 'sep' as separators */
do {
ENTRY e, *rv;
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Ignore all Carriage Returns when importing an environment.
Am 11.05.2012 21:09, schrieb Wolfgang Denk: Dear Alexander Holler, In message<1336720486-7424-1-git-send-email-hol...@ahsoftware.de> you wrote: This is used for compatibility with text files which are using CRLF instead of LF as the end of a line. I don't think we should do this. If you have text files with CR-LF line endings, then please use external tools (like dos2unix) to filter these and bring them into the appropriate format. I would like to put as little restrictions on the content of an environment variable as possible. I can see valid use for strings that contain a CR character. I don't see any reasonable usage for carriage returns in imported environment variables, but I've seen many people from the windows camp struggling in writing small text files to set some environment variables (which mostly end up in the kernel cmdline). Especially because those CR's often will lead to obscure errors because almost nothing (in u-boot or linux) is able to handle them. Anyway I don't really care, I just found it very user friendly to strip the carriage returns, especially for those embedded newbies which are in need to use some unnamed windows IDE. So I've decided (after having that patch lying around for about a year) to finally post it. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Ignore all Carriage Returns when importing an environment.
This is used for compatibility with text files which are
using CRLF instead of LF as the end of a line.
Signed-off-by: Alexander Holler
---
lib/hashtable.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/lib/hashtable.c b/lib/hashtable.c
index abd61c8..6e146ce 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -623,9 +623,9 @@ ssize_t hexport_r(struct hsearch_data *htab, const char sep,
* (entries separated by newline characters).
*
* To allow for nicely formatted text input, leading white space
- * (sequences of SPACE and TAB chars) is ignored, and entries starting
- * (after removal of any leading white space) with a '#' character are
- * considered comments and ignored.
+ * (sequences of SPACE and TAB chars) is ignored, all Carriage Returns
+ * are ignored and entries starting (after removal of any leading white
+ * space) with a '#' character are considered comments and ignored.
*
* [NOTE: this means that a variable name cannot start with a '#'
* character.]
@@ -642,6 +642,7 @@ int himport_r(struct hsearch_data *htab,
const char *env, size_t size, const char sep, int flag)
{
char *data, *sp, *dp, *name, *value;
+ unsigned ignored_crs;
/* Test for correct arguments. */
if (htab == NULL) {
@@ -698,6 +699,17 @@ int himport_r(struct hsearch_data *htab,
}
}
+ /* Remove all Carriage Returns */
+ ignored_crs = 0;
+ for(;dp < data + size && *dp; ++dp) {
+ if( *dp == '\r' )
+ ++ignored_crs;
+ else if(ignored_crs)
+ *(dp-ignored_crs) = *dp;
+ }
+ size -= ignored_crs;
+ dp = data;
+
/* Parse environment; allow for '\0' and 'sep' as separators */
do {
ENTRY e, *rv;
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] omap3_beagle: enable EHCI and USB storage.
Am 27.05.2011 11:40, schrieb Christian Spielberger: > On 05/27/2011 09:34 AM, Alexander Holler wrote: >> Am 26.05.2011 17:41, schrieb Alexander Holler: >>> Am 26.05.2011 13:30, schrieb Christian Spielberger: >> ... >>> But even than USB doesn't seem to work on a BeagleBoard XM (at least >>> some people told me so). I don't have a XM, so I can't help more there. >>> It might be a problem with (a needed reset of) the HUB which is included >>> on the XM, I don't know. >> >> I forgot to mention that the PHY reset on the XM works inverse than for >> the BeagleBoard w/o XM. Haven't known this, when I've written that patch. >> >> Regards, >> >> Alexander >> >> > > We checked what you mentioned but found that the PHY reset is identical > between XM and C4. The reset signal is ok. That is what we saw on an > oscilloscope. > > We also found that the USB2HS_CLK initialization does not work, also > with the oscilloscope. I am going to check the CLK initialization > sequence in beagle.c/ehci_hcd_init. It seems the PHY reset was only inverted for XM-A and XM-B and got again the same as in the C4 with XM-C. I've looked up in my mailbox and found a quick and dirty hack from Koen Kooi with which he comes at least through the initialization on the XM: http://dominion.thruhere.net/koen/angstrom/beagleboard/uboot/hacks.diff But I think he stopped working on that topic, waiting for feedback from other people. You might ask on the mailing list for the BeagleBoard about the status. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] omap3_beagle: enable EHCI and USB storage.
Am 26.05.2011 17:41, schrieb Alexander Holler: > Am 26.05.2011 13:30, schrieb Christian Spielberger: ... > But even than USB doesn't seem to work on a BeagleBoard XM (at least > some people told me so). I don't have a XM, so I can't help more there. > It might be a problem with (a needed reset of) the HUB which is included > on the XM, I don't know. I forgot to mention that the PHY reset on the XM works inverse than for the BeagleBoard w/o XM. Haven't known this, when I've written that patch. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] omap3_beagle: enable EHCI and USB storage.
Am 26.05.2011 13:30, schrieb Christian Spielberger: > Hi Alexander Holler, > > is EHCI on omap3 already working? > > On my beagleboard xM > > usb start > > hangs at this position in method ehci_hcd_init: > > + /* perform TLL soft reset, and wait until reset is complete */ > + writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, > + OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); It works on a normal BeagleBoard (720 MHz). On the XM it seems you have either move the initialization of the usb-clocks a bit upwards (e.g. before the reset of the phy) or you have to add a check if the clock runs after it was initialized (before that writel). The XM seems to be too fast and the peripheral-clock isn't ready when that writel wants to write to the peripheral-register, therefor it hangs there on a XM. But even than USB doesn't seem to work on a BeagleBoard XM (at least some people told me so). I don't have a XM, so I can't help more there. It might be a problem with (a needed reset of) the HUB which is included on the XM, I don't know. And a side note: don't try a kernel compiled with gcc 4.6 on the BeagleBoard. EHCI on the OMAP3 doesn't come up here when the kernel is compiled with gcc 4.6. That seems to be specific to OMAP, I don't have those problems on other ARM hw (I use successfull e.g. EHCI on some armv5 devices with kernels which are compiled with gcc 4.6).When I compile the same kernel using gcc 4.5.2 I have no problems with EHCI on the BeagleBoard. Haven't investigated that further. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address
Am 24.05.2011 05:47, schrieb Mike Frysinger: >> I've never seen a valid use of strcpy() with a null-pointer in real >> world programs, which we are talking about, except in bugs. > > i'm lazy and type "0" all the time for loading files, copying memory, > displaying things, etc... in u-boot. i dont feel like retraining my finger > muscle memory if i dont have to ;). > -mike Using a 4 should be better for your finger. Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address
Am 24.05.2011 00:22, schrieb Wolfgang Denk:
> Dear Alexander Holler,
>
> In message<4ddadbb6.30...@ahsoftware.de> you wrote:
>>
>> So you I will look forward to checks for NULL pointers and similiar in
>> all C standard functions implemented in u-boot to circumvent tons of
>> possible real world bugs in all callers of strcpy, strlen, mem* and
>> whatever.
>
> If you think a bit about this, you may find it more difficult than you
> expect. Keep in mind that on most systems supported by U-Boot code
> like
>
> int *p = (int *)0;
>
> print("*p = %d\n", *p);
>
> is perfectly legal and supposed to work without any problems -
> because 0 is a legal address, and it makes perfect senze that commands
> like "md" or "cp" can be used to access it. In the result, strcpy(),
> strlen(), mem*() and whatever must beable to work on address 0 likeon
> any other address, too.
>
> :-P
I've never seen a valid use of strcpy() with a null-pointer in real
world programs, which we are talking about, except in bugs.
BTW, you missed to quote my suggestion to get rid of the implementation
of memcpy() and use always memmove(). That would be really defensive
programming and if the unnecessary identity-check in memcpy isn't of
interest, the additional other check done by memmove() shouldn't be a
problem too.
But I will stop complaining as requested and getting silent again.
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address
Am 23.05.2011 23:55, schrieb Wolfgang Denk: > Dear Alexander Holler, > > In message<4ddacc8b.6090...@ahsoftware.de> you wrote: >> >>> --- a/lib/string.c >>> +++ b/lib/string.c >>> @@ -467,6 +467,9 @@ void * memcpy(void *dest, const void *src, size_t count) >>> unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src; >>> char *d8, *s8; >>> >>> + if (src == dest) >>> + return dest; >>> + >> >> here is the same, as in the patch I've commented before. There exist no >> reason to add a check for identity to memcpy() because memcpy doesn't >> support overlapping regions (and identity is just a special case of >> overlapping regions). If something might call memcpy() with overlapping >> or identical regions, it should use memmove(). > > In an ideal world, nobody will ever use any interfces in a > non-compliant or incorrect way. > > In reality, all kind of errors happen. A little defensive programming > like the one above helps a lot, so please stop complaining even if you > think you don't need this. So you I will look forward to checks for NULL pointers and similiar in all C standard functions implemented in u-boot to circumvent tons of possible real world bugs in all callers of strcpy, strlen, mem* and whatever. Reads promising, regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address
Hello,
Am 23.05.2011 11:03, schrieb Matthias Weisser:
> In some cases (e.g. bootm with a elf payload which is already at the right
> position) there is a in place copy of data to the same address. Catching this
> saves some ms while booting.
>
> Signed-off-by: Matthias Weisser
> ---
> Changes since V1:
>- Made subject more informative
>- Removed the optimization from bcopy as bcopy is not used anywhere
>
> lib/string.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/lib/string.c b/lib/string.c
> index b375b81..2c4f0ec 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -467,6 +467,9 @@ void * memcpy(void *dest, const void *src, size_t count)
> unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
> char *d8, *s8;
>
> + if (src == dest)
> + return dest;
> +
here is the same, as in the patch I've commented before. There exist no
reason to add a check for identity to memcpy() because memcpy doesn't
support overlapping regions (and identity is just a special case of
overlapping regions). If something might call memcpy() with overlapping
or identical regions, it should use memmove().
> /* while all data is aligned (common case), copy a word at a time */
> if ( (((ulong)dest | (ulong)src)& (sizeof(*dl) - 1)) == 0) {
> while (count>= sizeof(*dl)) {
> @@ -497,6 +500,9 @@ void * memmove(void * dest,const void *src,size_t count)
> {
> char *tmp, *s;
>
> + if (src == dest)
> + return dest;
> +
> if (dest<= src) {
Here it is ok, but the check <= could be modified to < too.
Just to clarify my reasoning: the only reason why memcpy() exists, is
because it should have been a faster version of memmove() without the
necessary checks.
So if a bug proof of version of memcpy() is wanted, there is no need to
have a different implementation for memcpy() and memcpy() could just be
an alias for memmove().
But adding a check for identity to memcpy() is unnecessary.
Sorry, but I had to comment this after having read to many comments in a
bug about something similiar in
https://bugzilla.redhat.com/show_bug.cgi?id=638477
(Be aware, reading that bug might hurt your brain)
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address
Hello, Am 23.05.2011 11:49, schrieb Albert ARIBAUD: >> The standard clearly say to both memory regions should not overlap when >> memcpy() is used, so I would say this is the wrong place to fix that. > > I think the intent here is not to enforce the standard but to handle an > actual, and degenerate, copy request in the most efficient manner, and > in that respect, the patch does its job. > > Besides, if the patch was about enforcing the standard, then I would > consider it highly more efficient to check the areas once in the memcpy > function than duplicating this check before each call to the function, > considering that the place where the copy happens is not necessarily the > one where the source and destination were computed. A fool proof solution would be to always use memmove() and get rid of memcpy(). But checking for overlapped regions in memcpy() is imho the wrong way. This just leads to more possible wrong code which uses memcpy() when it should use memmove(). Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address
Am 23.05.2011 11:46, schrieb Matthias Weißer: >> The standard clearly say to both memory regions should not overlap when >> memcpy() is used, so I would say this is the wrong place to fix that. > > Well, real world applications do this. And these two instructions > shouldn't hurt a lot. Real bugs to this. Just see e.g the long discussion about some changes fo memcpy done in the glibc lately and what that did for flash-users because flash seemed to the same stupid stuff. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address
Am 23.05.2011 11:06, schrieb Matthias Weisser: > In some cases (e.g. bootm with a elf payload which is already at the right > position) there is a in place copy of data to the same address. Catching this > saves some ms while booting. > > Signed-off-by: Matthias Weisser > --- > arch/arm/lib/memcpy.S |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S > index 3b5aeec..f655256 100644 > --- a/arch/arm/lib/memcpy.S > +++ b/arch/arm/lib/memcpy.S > @@ -60,6 +60,9 @@ > .globl memcpy > memcpy: > > + cmp r0, r1 > + moveq pc, lr > + > enter r4, lr > > subsr2, r2, #4 The standard clearly say to both memory regions should not overlap when memcpy() is used, so I would say this is the wrong place to fix that. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: Remove __attribute__ ((packed)) for struct ehci_hccr and ehci_hcor.
Hello,
Am 02.04.2011 00:35, schrieb Alexander Holler:
> Remove __attribute__ ((packed)) to prevent byte access to soc
> registers in some gcc versions.
>
> Having patches to enable ehci for the BeagleBoard lying around for
> several month, this one was the show-stopper.
>
> Credits have to go to Laine Walker-Avina for
> finding the problem.
>
> Signed-off-by: Alexander Holler
> ---
> drivers/usb/host/ehci.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
> index 945ab64..df9f055 100644
> --- a/drivers/usb/host/ehci.h
> +++ b/drivers/usb/host/ehci.h
> @@ -55,7 +55,7 @@ struct ehci_hccr {
> #define HCS_N_PORTS(p) (((p)>> 0)& 0xf)
> uint32_t cr_hccparams;
> uint8_t cr_hcsp_portrt[8];
> -} __attribute__ ((packed));
> +};
>
> struct ehci_hcor {
> uint32_t or_usbcmd;
> @@ -85,7 +85,7 @@ struct ehci_hcor {
> #define FLAG_CF (1<< 0)/* true: we'll support "high
> speed" */
> uint32_t or_portsc[CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS];
> uint32_t or_systune;
> -} __attribute__ ((packed));
> +};
>
> #define USBMODE 0x68/* USB Device mode */
> #define USBMODE_SDIS(1<< 3)/* Stream disable */
Before I'm killing someones 64bit+ machine with that patch:
The hint I've received was to use
+} __attribute__ ((packed, aligned(4)));
That works too. I haven't seen the original commit (I've only got told
that credits have to go to Laine Walker-Avina), I don't know if the
standard says something to that, I don't know if some 64bit+ SoC might
choose to align that stuff otherwise and I will not send a v2 of that patch.
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: Remove __attribute__ ((packed)) for struct ehci_hccr and ehci_hcor.
Am 02.04.2011 01:35, schrieb Wolfgang Denk: > Dear Alexander Holler, > > In message<4d965c71.3010...@ahsoftware.de> you wrote: >> Hello, >> >> Am 02.04.2011 00:53, schrieb Wolfgang Denk: >> >>> Why do you repost this stuff without any comments, versioning or >>> changelog? >> >> Because someone broke the TWL4030-RTC in 2.6.38 and those 4 message got >> send with a date from 2000. >> That means those will never seen in the archives (for 2009), and not by >> people which are sorting their mailboxes by date. >> >> So I thought it is good idea to resend that. > > Please reread: "... without any comments, versioning or changelog?" I promise to not send any patches anymore. Thanks, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: Remove __attribute__ ((packed)) for struct ehci_hccr and ehci_hcor.
Hello, Am 02.04.2011 00:53, schrieb Wolfgang Denk: > Why do you repost this stuff without any comments, versioning or > changelog? Because someone broke the TWL4030-RTC in 2.6.38 and those 4 message got send with a date from 2000. That means those will never seen in the archives (for 2009), and not by people which are sorting their mailboxes by date. So I thought it is good idea to resend that. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] OMAP3: Add support for DPLL5 (usbhost)
Signed-off-by: Alexander Holler
---
arch/arm/cpu/armv7/omap3/clock.c | 20 ++
arch/arm/cpu/armv7/omap3/lowlevel_init.S | 22
arch/arm/include/asm/arch-omap3/clocks.h |1 +
arch/arm/include/asm/arch-omap3/clocks_omap3.h | 26
arch/arm/include/asm/arch-omap3/cpu.h | 21 ++
5 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/clock.c b/arch/arm/cpu/armv7/omap3/clock.c
index 2238c52..3d38d08 100644
--- a/arch/arm/cpu/armv7/omap3/clock.c
+++ b/arch/arm/cpu/armv7/omap3/clock.c
@@ -278,6 +278,25 @@ static void dpll4_init_34xx(u32 sil_index, u32 clk_index)
wait_on_value(ST_PERIPH_CLK, 2, &prcm_base->idlest_ckgen, LDELAY);
}
+static void dpll5_init_34xx(u32 sil_index, u32 clk_index)
+{
+ struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
+ dpll_param *ptr = (dpll_param *) get_per2_dpll_param();
+
+ /* Moving it to the right sysclk base */
+ ptr = ptr + clk_index;
+
+ /* PER2 DPLL (DPLL5) */
+ sr32(&prcm_base->clken2_pll, 0, 3, PLL_STOP);
+ wait_on_value(1, 0, &prcm_base->idlest2_ckgen, LDELAY);
+ sr32(&prcm_base->clksel5_pll, 0, 5, ptr->m2); /* set M2 (usbtll_fck) */
+ sr32(&prcm_base->clksel4_pll, 8, 11, ptr->m); /* set m (11-bit
multiplier) */
+ sr32(&prcm_base->clksel4_pll, 0, 7, ptr->n); /* set n (7-bit divider)*/
+ sr32(&prcm_base->clken_pll, 4, 4, ptr->fsel); /* FREQSEL */
+ sr32(&prcm_base->clken2_pll, 0, 3, PLL_LOCK); /* lock mode */
+ wait_on_value(1, 1, &prcm_base->idlest2_ckgen, LDELAY);
+}
+
static void mpu_init_34xx(u32 sil_index, u32 clk_index)
{
struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
@@ -587,6 +606,7 @@ void prcm_init(void)
dpll3_init_34xx(sil_index, clk_index);
dpll4_init_34xx(sil_index, clk_index);
+ dpll5_init_34xx(sil_index, clk_index);
iva_init_34xx(sil_index, clk_index);
mpu_init_34xx(sil_index, clk_index);
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index 109481e..1458072 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -360,6 +360,28 @@ get_per_dpll_param:
adr r0, per_dpll_param
mov pc, lr
+/* PER2 DPLL values */
+per2_dpll_param:
+/* 12MHz */
+.word PER2_M_12, PER2_N_12, PER2_FSEL_12, PER2_M2_12
+
+/* 13MHz */
+.word PER2_M_13, PER2_N_13, PER2_FSEL_13, PER2_M2_13
+
+/* 19.2MHz */
+.word PER2_M_19P2, PER2_N_19P2, PER2_FSEL_19P2, PER2_M2_19P2
+
+/* 26MHz */
+.word PER2_M_26, PER2_N_26, PER2_FSEL_26, PER2_M2_26
+
+/* 38.4MHz */
+.word PER2_M_38P4, PER2_N_38P4, PER2_FSEL_38P4, PER2_M2_38P4
+
+.globl get_per2_dpll_param
+get_per2_dpll_param:
+ adr r0, per2_dpll_param
+ mov pc, lr
+
/*
* Tables for 36XX/37XX devices
*
diff --git a/arch/arm/include/asm/arch-omap3/clocks.h
b/arch/arm/include/asm/arch-omap3/clocks.h
index 40f80ba..bed0002 100644
--- a/arch/arm/include/asm/arch-omap3/clocks.h
+++ b/arch/arm/include/asm/arch-omap3/clocks.h
@@ -68,6 +68,7 @@ extern dpll_param *get_mpu_dpll_param(void);
extern dpll_param *get_iva_dpll_param(void);
extern dpll_param *get_core_dpll_param(void);
extern dpll_param *get_per_dpll_param(void);
+extern dpll_param *get_per2_dpll_param(void);
extern dpll_param *get_36x_mpu_dpll_param(void);
extern dpll_param *get_36x_iva_dpll_param(void);
diff --git a/arch/arm/include/asm/arch-omap3/clocks_omap3.h
b/arch/arm/include/asm/arch-omap3/clocks_omap3.h
index 30ef690..ef600dd 100644
--- a/arch/arm/include/asm/arch-omap3/clocks_omap3.h
+++ b/arch/arm/include/asm/arch-omap3/clocks_omap3.h
@@ -282,6 +282,32 @@
#define PER_FSEL_38P4 0x07
#define PER_M2_38P40x09
+/* PER2 DPLL */
+#define PER2_M_12 0x78
+#define PER2_N_12 0x0B
+#define PER2_FSEL_12 0x03
+#define PER2_M2_12 0x01
+
+#define PER2_M_13 0x78
+#define PER2_N_13 0x0C
+#define PER2_FSEL_13 0x03
+#define PER2_M2_13 0x01
+
+#define PER2_M_19P20x2EE
+#define PER2_N_19P20x0B
+#define PER2_FSEL_19P2 0x06
+#define PER2_M2_19P2 0x0A
+
+#define PER2_M_26 0x78
+#define PER2_N_26 0x0C
+#define PER2_FSEL_26 0x03
+#define PER2_M2_26 0x01
+
+#define PER2_M_38P40x2EE
+#define PER2_N_38P40x0B
+#define PER2_FSEL_38P4 0x06
+#define PER2_M2_38P4 0x0A
+
/* 36XX PER DPLL */
#define PER_36XX_M_12 0x1B0
diff --git a/arch/arm/include/asm/arch-omap3/cpu.h
b/arch/arm/include/asm/arch-omap3/cpu.h
index 962d6d4..e944de7 100644
--- a/arch/arm/include/asm/arch-omap3/cpu.h
+++ b/arch/arm/i
[U-Boot] [PATCH 3/3] omap3_beagle: enable EHCI and USB storage.
The reset sequence/configuration for ehci is highly board specific,
so this will be done in the source for the board, instead of
introducing several CONFIG_* which would be needed to make those
few lines in beagle.c usable across different OMAP boards.
Signed-off-by: Alexander Holler
---
arch/arm/include/asm/arch-omap3/ehci_omap3.h | 58 ++
board/ti/beagle/beagle.c | 106 ++
include/configs/omap3_beagle.h |6 ++
3 files changed, 170 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-omap3/ehci_omap3.h
diff --git a/arch/arm/include/asm/arch-omap3/ehci_omap3.h
b/arch/arm/include/asm/arch-omap3/ehci_omap3.h
new file mode 100644
index 000..cd01f50
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap3/ehci_omap3.h
@@ -0,0 +1,58 @@
+/*
+ * (C) Copyright 2011
+ * Alexander Holler
+ *
+ * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37
+ *
+ * See there for additional Copyrights.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+#ifndef _EHCI_OMAP3_H_
+#define _EHCI_OMAP3_H_
+
+/* USB/EHCI registers */
+#define OMAP3_USBTLL_BASE 0x48062000UL
+#define OMAP3_UHH_BASE 0x48064000UL
+#define OMAP3_EHCI_BASE0x48064800UL
+
+/* TLL Register Set */
+#defineOMAP_USBTLL_SYSCONFIG (0x10)
+#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1)
+#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2)
+#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3)
+#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8)
+
+#defineOMAP_USBTLL_SYSSTATUS (0x14)
+#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 << 0)
+
+/* UHH Register Set */
+#defineOMAP_UHH_SYSCONFIG (0x10)
+#defineOMAP_UHH_SYSCONFIG_SOFTRESET(1 << 1)
+#defineOMAP_UHH_SYSCONFIG_CACTIVITY(1 << 8)
+#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1 << 3)
+#defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1 << 2)
+#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1 << 12)
+
+#defineOMAP_UHH_HOSTCONFIG (0x40)
+#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2)
+#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 << 3)
+#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN(1 << 4)
+
+#endif /* _EHCI_OMAP3_H_ */
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c066d6e..03242c1 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -37,8 +37,19 @@
#include
#include
#include
+#ifdef CONFIG_USB_EHCI
+#include
+#include
+#include
+#include
+/* from drivers/usb/host/ehci-core.h */
+extern struct ehci_hccr *hccr;
+extern volatile struct ehci_hcor *hcor;
+#endif
#include "beagle.h"
+#define pr_debug(fmt, args...) debug(fmt, ##args)
+
#define TWL4030_I2C_BUS0
#define EXPANSION_EEPROM_I2C_BUS 1
#define EXPANSION_EEPROM_I2C_ADDRESS 0x50
@@ -273,3 +284,98 @@ int board_mmc_init(bd_t *bis)
return 0;
}
#endif
+
+#ifdef CONFIG_USB_EHCI
+
+#define GPIO_PHY_RESET 147
+
+/* Reset is needed otherwise the kernel-driver will throw an error. */
+int ehci_hcd_stop(void)
+{
+ pr_debug("Resetting OMAP3 EHCI\n");
+ omap_set_gpio_dataout(GPIO_PHY_RESET, 0);
+ writel(OMAP_UHH_SYSCONFIG_SOFTRESET, OMAP3_UHH_BASE +
OMAP_UHH_SYSCONFIG);
+ return 0;
+}
+
+/* Call usb_stop() before starting the kernel */
+void show_boot_progress(int val)
+{
+ if(val == 15)
+ usb_stop();
+}
+
+/*
+ * Initialize the OMAP3 EHCI controller and PHY on the BeagleBoard.
+ * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37.
+ * See there for additional Copyrights.
+ */
+int ehci_hcd_init(void)
+{
+ pr_debug("Initializing OMAP3 ECHI\n");
+
[U-Boot] [PATCH 1/3] OMAP3: Change some USB related MUX settings to values used by the kernel.
Signed-off-by: Alexander Holler
---
board/ti/beagle/beagle.h | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index b22b653..abb69e7 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -273,18 +273,18 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(MCSPI1_CS1), (IDIS | PTD | EN | M0)) /*McSPI1_CS1*/\
MUX_VAL(CP(MCSPI1_CS2), (IDIS | PTD | DIS | M4)) /*GPIO_176*/\
/* USB EHCI (port 2) */\
- MUX_VAL(CP(MCSPI1_CS3), (IEN | PTU | DIS | M3))
/*HSUSB2_DATA2*/\
- MUX_VAL(CP(MCSPI2_CLK), (IEN | PTU | DIS | M3))
/*HSUSB2_DATA7*/\
- MUX_VAL(CP(MCSPI2_SIMO),(IEN | PTU | DIS | M3))
/*HSUSB2_DATA4*/\
- MUX_VAL(CP(MCSPI2_SOMI),(IEN | PTU | DIS | M3))
/*HSUSB2_DATA5*/\
- MUX_VAL(CP(MCSPI2_CS0), (IEN | PTU | DIS | M3))
/*HSUSB2_DATA6*/\
- MUX_VAL(CP(MCSPI2_CS1), (IEN | PTU | DIS | M3))
/*HSUSB2_DATA3*/\
- MUX_VAL(CP(ETK_D10_ES2),(IDIS | PTU | DIS | M3)) /*HSUSB2_CLK*/\
- MUX_VAL(CP(ETK_D11_ES2),(IDIS | PTU | DIS | M3)) /*HSUSB2_STP*/\
- MUX_VAL(CP(ETK_D12_ES2),(IEN | PTU | DIS | M3)) /*HSUSB2_DIR*/\
- MUX_VAL(CP(ETK_D13_ES2),(IEN | PTU | DIS | M3)) /*HSUSB2_NXT*/\
- MUX_VAL(CP(ETK_D14_ES2),(IEN | PTU | DIS | M3))
/*HSUSB2_DATA0*/\
- MUX_VAL(CP(ETK_D15_ES2),(IEN | PTU | DIS | M3))
/*HSUSB2_DATA1*/\
+ MUX_VAL(CP(MCSPI1_CS3), (IEN | PTD | EN | M3))
/*HSUSB2_DATA2*/\
+ MUX_VAL(CP(MCSPI2_CLK), (IEN | PTD | EN | M3))
/*HSUSB2_DATA7*/\
+ MUX_VAL(CP(MCSPI2_SIMO),(IEN | PTD | EN | M3))
/*HSUSB2_DATA4*/\
+ MUX_VAL(CP(MCSPI2_SOMI),(IEN | PTD | EN | M3))
/*HSUSB2_DATA5*/\
+ MUX_VAL(CP(MCSPI2_CS0), (IEN | PTD | EN | M3))
/*HSUSB2_DATA6*/\
+ MUX_VAL(CP(MCSPI2_CS1), (IEN | PTD | EN | M3))
/*HSUSB2_DATA3*/\
+ MUX_VAL(CP(ETK_D10_ES2),(IDIS | PTD | DIS | M3)) /*HSUSB2_CLK*/\
+ MUX_VAL(CP(ETK_D11_ES2),(IDIS | PTD | DIS | M3)) /*HSUSB2_STP*/\
+ MUX_VAL(CP(ETK_D12_ES2),(IEN | PTD | EN | M3)) /*HSUSB2_DIR*/\
+ MUX_VAL(CP(ETK_D13_ES2),(IEN | PTD | EN | M3)) /*HSUSB2_NXT*/\
+ MUX_VAL(CP(ETK_D14_ES2),(IEN | PTD | EN | M3))
/*HSUSB2_DATA0*/\
+ MUX_VAL(CP(ETK_D15_ES2),(IEN | PTD | EN | M3))
/*HSUSB2_DATA1*/\
/*Control and debug */\
MUX_VAL(CP(SYS_32K),(IEN | PTD | DIS | M0)) /*SYS_32K*/\
MUX_VAL(CP(SYS_CLKREQ), (IEN | PTD | DIS | M0)) /*SYS_CLKREQ*/\
@@ -383,7 +383,8 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(MCBSP3_CLKX),(IEN | PTD | DIS | M4)) /*GPIO_141*/\
MUX_VAL(CP(UART2_CTS), (IEN | PTU | EN | M0)) /*UART2_CTS*/\
MUX_VAL(CP(UART2_RTS), (IDIS | PTD | DIS | M0)) /*UART2_RTS*/\
- MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M0)) /*UART2_TX*/
+ MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M0)) /*UART2_TX*/\
+ MUX_VAL(CP(UART2_RX), (IDIS | PTU | EN | M4)) /*GPIO_147*/
#define MUX_BEAGLE_XM() \
MUX_VAL(CP(GPMC_NCS5), (IDIS | PTD | EN | M4)) /*GPIO_56*/\
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] USB: Remove __attribute__ ((packed)) for struct ehci_hccr and ehci_hcor.
Remove __attribute__ ((packed)) to prevent byte access to soc
registers in some gcc versions.
Having patches to enable ehci for the BeagleBoard lying around for
several month, this one was the show-stopper.
Credits have to go to Laine Walker-Avina for
finding the problem.
Signed-off-by: Alexander Holler
---
drivers/usb/host/ehci.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 945ab64..df9f055 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -55,7 +55,7 @@ struct ehci_hccr {
#define HCS_N_PORTS(p) (((p) >> 0) & 0xf)
uint32_t cr_hccparams;
uint8_t cr_hcsp_portrt[8];
-} __attribute__ ((packed));
+};
struct ehci_hcor {
uint32_t or_usbcmd;
@@ -85,7 +85,7 @@ struct ehci_hcor {
#define FLAG_CF(1 << 0)/* true: we'll support "high
speed" */
uint32_t or_portsc[CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS];
uint32_t or_systune;
-} __attribute__ ((packed));
+};
#define USBMODE0x68/* USB Device mode */
#define USBMODE_SDIS (1 << 3)/* Stream disable */
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] omap3_beagle: enable EHCI and USB storage.
The reset sequence/configuration for ehci is highly board specific,
so this will be done in the source for the board, instead of
introducing several CONFIG_* which would be needed to make those
few lines in beagle.c usable across different OMAP boards.
Signed-off-by: Alexander Holler
---
arch/arm/include/asm/arch-omap3/ehci_omap3.h | 58 ++
board/ti/beagle/beagle.c | 106 ++
include/configs/omap3_beagle.h |6 ++
3 files changed, 170 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-omap3/ehci_omap3.h
diff --git a/arch/arm/include/asm/arch-omap3/ehci_omap3.h
b/arch/arm/include/asm/arch-omap3/ehci_omap3.h
new file mode 100644
index 000..cd01f50
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap3/ehci_omap3.h
@@ -0,0 +1,58 @@
+/*
+ * (C) Copyright 2011
+ * Alexander Holler
+ *
+ * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37
+ *
+ * See there for additional Copyrights.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+#ifndef _EHCI_OMAP3_H_
+#define _EHCI_OMAP3_H_
+
+/* USB/EHCI registers */
+#define OMAP3_USBTLL_BASE 0x48062000UL
+#define OMAP3_UHH_BASE 0x48064000UL
+#define OMAP3_EHCI_BASE0x48064800UL
+
+/* TLL Register Set */
+#defineOMAP_USBTLL_SYSCONFIG (0x10)
+#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1)
+#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2)
+#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3)
+#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8)
+
+#defineOMAP_USBTLL_SYSSTATUS (0x14)
+#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 << 0)
+
+/* UHH Register Set */
+#defineOMAP_UHH_SYSCONFIG (0x10)
+#defineOMAP_UHH_SYSCONFIG_SOFTRESET(1 << 1)
+#defineOMAP_UHH_SYSCONFIG_CACTIVITY(1 << 8)
+#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1 << 3)
+#defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1 << 2)
+#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1 << 12)
+
+#defineOMAP_UHH_HOSTCONFIG (0x40)
+#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2)
+#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 << 3)
+#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN(1 << 4)
+
+#endif /* _EHCI_OMAP3_H_ */
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c066d6e..03242c1 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -37,8 +37,19 @@
#include
#include
#include
+#ifdef CONFIG_USB_EHCI
+#include
+#include
+#include
+#include
+/* from drivers/usb/host/ehci-core.h */
+extern struct ehci_hccr *hccr;
+extern volatile struct ehci_hcor *hcor;
+#endif
#include "beagle.h"
+#define pr_debug(fmt, args...) debug(fmt, ##args)
+
#define TWL4030_I2C_BUS0
#define EXPANSION_EEPROM_I2C_BUS 1
#define EXPANSION_EEPROM_I2C_ADDRESS 0x50
@@ -273,3 +284,98 @@ int board_mmc_init(bd_t *bis)
return 0;
}
#endif
+
+#ifdef CONFIG_USB_EHCI
+
+#define GPIO_PHY_RESET 147
+
+/* Reset is needed otherwise the kernel-driver will throw an error. */
+int ehci_hcd_stop(void)
+{
+ pr_debug("Resetting OMAP3 EHCI\n");
+ omap_set_gpio_dataout(GPIO_PHY_RESET, 0);
+ writel(OMAP_UHH_SYSCONFIG_SOFTRESET, OMAP3_UHH_BASE +
OMAP_UHH_SYSCONFIG);
+ return 0;
+}
+
+/* Call usb_stop() before starting the kernel */
+void show_boot_progress(int val)
+{
+ if(val == 15)
+ usb_stop();
+}
+
+/*
+ * Initialize the OMAP3 EHCI controller and PHY on the BeagleBoard.
+ * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37.
+ * See there for additional Copyrights.
+ */
+int ehci_hcd_init(void)
+{
+ pr_debug("Initializing OMAP3 ECHI\n");
+
[U-Boot] [PATCH 2/3] OMAP3: Add support for DPLL5 (usbhost)
Signed-off-by: Alexander Holler
---
arch/arm/cpu/armv7/omap3/clock.c | 20 ++
arch/arm/cpu/armv7/omap3/lowlevel_init.S | 22
arch/arm/include/asm/arch-omap3/clocks.h |1 +
arch/arm/include/asm/arch-omap3/clocks_omap3.h | 26
arch/arm/include/asm/arch-omap3/cpu.h | 21 ++
5 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/clock.c b/arch/arm/cpu/armv7/omap3/clock.c
index 2238c52..3d38d08 100644
--- a/arch/arm/cpu/armv7/omap3/clock.c
+++ b/arch/arm/cpu/armv7/omap3/clock.c
@@ -278,6 +278,25 @@ static void dpll4_init_34xx(u32 sil_index, u32 clk_index)
wait_on_value(ST_PERIPH_CLK, 2, &prcm_base->idlest_ckgen, LDELAY);
}
+static void dpll5_init_34xx(u32 sil_index, u32 clk_index)
+{
+ struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
+ dpll_param *ptr = (dpll_param *) get_per2_dpll_param();
+
+ /* Moving it to the right sysclk base */
+ ptr = ptr + clk_index;
+
+ /* PER2 DPLL (DPLL5) */
+ sr32(&prcm_base->clken2_pll, 0, 3, PLL_STOP);
+ wait_on_value(1, 0, &prcm_base->idlest2_ckgen, LDELAY);
+ sr32(&prcm_base->clksel5_pll, 0, 5, ptr->m2); /* set M2 (usbtll_fck) */
+ sr32(&prcm_base->clksel4_pll, 8, 11, ptr->m); /* set m (11-bit
multiplier) */
+ sr32(&prcm_base->clksel4_pll, 0, 7, ptr->n); /* set n (7-bit divider)*/
+ sr32(&prcm_base->clken_pll, 4, 4, ptr->fsel); /* FREQSEL */
+ sr32(&prcm_base->clken2_pll, 0, 3, PLL_LOCK); /* lock mode */
+ wait_on_value(1, 1, &prcm_base->idlest2_ckgen, LDELAY);
+}
+
static void mpu_init_34xx(u32 sil_index, u32 clk_index)
{
struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
@@ -587,6 +606,7 @@ void prcm_init(void)
dpll3_init_34xx(sil_index, clk_index);
dpll4_init_34xx(sil_index, clk_index);
+ dpll5_init_34xx(sil_index, clk_index);
iva_init_34xx(sil_index, clk_index);
mpu_init_34xx(sil_index, clk_index);
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index 109481e..1458072 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -360,6 +360,28 @@ get_per_dpll_param:
adr r0, per_dpll_param
mov pc, lr
+/* PER2 DPLL values */
+per2_dpll_param:
+/* 12MHz */
+.word PER2_M_12, PER2_N_12, PER2_FSEL_12, PER2_M2_12
+
+/* 13MHz */
+.word PER2_M_13, PER2_N_13, PER2_FSEL_13, PER2_M2_13
+
+/* 19.2MHz */
+.word PER2_M_19P2, PER2_N_19P2, PER2_FSEL_19P2, PER2_M2_19P2
+
+/* 26MHz */
+.word PER2_M_26, PER2_N_26, PER2_FSEL_26, PER2_M2_26
+
+/* 38.4MHz */
+.word PER2_M_38P4, PER2_N_38P4, PER2_FSEL_38P4, PER2_M2_38P4
+
+.globl get_per2_dpll_param
+get_per2_dpll_param:
+ adr r0, per2_dpll_param
+ mov pc, lr
+
/*
* Tables for 36XX/37XX devices
*
diff --git a/arch/arm/include/asm/arch-omap3/clocks.h
b/arch/arm/include/asm/arch-omap3/clocks.h
index 40f80ba..bed0002 100644
--- a/arch/arm/include/asm/arch-omap3/clocks.h
+++ b/arch/arm/include/asm/arch-omap3/clocks.h
@@ -68,6 +68,7 @@ extern dpll_param *get_mpu_dpll_param(void);
extern dpll_param *get_iva_dpll_param(void);
extern dpll_param *get_core_dpll_param(void);
extern dpll_param *get_per_dpll_param(void);
+extern dpll_param *get_per2_dpll_param(void);
extern dpll_param *get_36x_mpu_dpll_param(void);
extern dpll_param *get_36x_iva_dpll_param(void);
diff --git a/arch/arm/include/asm/arch-omap3/clocks_omap3.h
b/arch/arm/include/asm/arch-omap3/clocks_omap3.h
index 30ef690..ef600dd 100644
--- a/arch/arm/include/asm/arch-omap3/clocks_omap3.h
+++ b/arch/arm/include/asm/arch-omap3/clocks_omap3.h
@@ -282,6 +282,32 @@
#define PER_FSEL_38P4 0x07
#define PER_M2_38P40x09
+/* PER2 DPLL */
+#define PER2_M_12 0x78
+#define PER2_N_12 0x0B
+#define PER2_FSEL_12 0x03
+#define PER2_M2_12 0x01
+
+#define PER2_M_13 0x78
+#define PER2_N_13 0x0C
+#define PER2_FSEL_13 0x03
+#define PER2_M2_13 0x01
+
+#define PER2_M_19P20x2EE
+#define PER2_N_19P20x0B
+#define PER2_FSEL_19P2 0x06
+#define PER2_M2_19P2 0x0A
+
+#define PER2_M_26 0x78
+#define PER2_N_26 0x0C
+#define PER2_FSEL_26 0x03
+#define PER2_M2_26 0x01
+
+#define PER2_M_38P40x2EE
+#define PER2_N_38P40x0B
+#define PER2_FSEL_38P4 0x06
+#define PER2_M2_38P4 0x0A
+
/* 36XX PER DPLL */
#define PER_36XX_M_12 0x1B0
diff --git a/arch/arm/include/asm/arch-omap3/cpu.h
b/arch/arm/include/asm/arch-omap3/cpu.h
index 962d6d4..e944de7 100644
--- a/arch/arm/include/asm/arch-omap3/cpu.h
+++ b/arch/arm/i
[U-Boot] [PATCH 1/3] OMAP3: Change some USB related MUX settings to values used by the kernel.
Signed-off-by: Alexander Holler
---
board/ti/beagle/beagle.h | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index b22b653..abb69e7 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -273,18 +273,18 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(MCSPI1_CS1), (IDIS | PTD | EN | M0)) /*McSPI1_CS1*/\
MUX_VAL(CP(MCSPI1_CS2), (IDIS | PTD | DIS | M4)) /*GPIO_176*/\
/* USB EHCI (port 2) */\
- MUX_VAL(CP(MCSPI1_CS3), (IEN | PTU | DIS | M3))
/*HSUSB2_DATA2*/\
- MUX_VAL(CP(MCSPI2_CLK), (IEN | PTU | DIS | M3))
/*HSUSB2_DATA7*/\
- MUX_VAL(CP(MCSPI2_SIMO),(IEN | PTU | DIS | M3))
/*HSUSB2_DATA4*/\
- MUX_VAL(CP(MCSPI2_SOMI),(IEN | PTU | DIS | M3))
/*HSUSB2_DATA5*/\
- MUX_VAL(CP(MCSPI2_CS0), (IEN | PTU | DIS | M3))
/*HSUSB2_DATA6*/\
- MUX_VAL(CP(MCSPI2_CS1), (IEN | PTU | DIS | M3))
/*HSUSB2_DATA3*/\
- MUX_VAL(CP(ETK_D10_ES2),(IDIS | PTU | DIS | M3)) /*HSUSB2_CLK*/\
- MUX_VAL(CP(ETK_D11_ES2),(IDIS | PTU | DIS | M3)) /*HSUSB2_STP*/\
- MUX_VAL(CP(ETK_D12_ES2),(IEN | PTU | DIS | M3)) /*HSUSB2_DIR*/\
- MUX_VAL(CP(ETK_D13_ES2),(IEN | PTU | DIS | M3)) /*HSUSB2_NXT*/\
- MUX_VAL(CP(ETK_D14_ES2),(IEN | PTU | DIS | M3))
/*HSUSB2_DATA0*/\
- MUX_VAL(CP(ETK_D15_ES2),(IEN | PTU | DIS | M3))
/*HSUSB2_DATA1*/\
+ MUX_VAL(CP(MCSPI1_CS3), (IEN | PTD | EN | M3))
/*HSUSB2_DATA2*/\
+ MUX_VAL(CP(MCSPI2_CLK), (IEN | PTD | EN | M3))
/*HSUSB2_DATA7*/\
+ MUX_VAL(CP(MCSPI2_SIMO),(IEN | PTD | EN | M3))
/*HSUSB2_DATA4*/\
+ MUX_VAL(CP(MCSPI2_SOMI),(IEN | PTD | EN | M3))
/*HSUSB2_DATA5*/\
+ MUX_VAL(CP(MCSPI2_CS0), (IEN | PTD | EN | M3))
/*HSUSB2_DATA6*/\
+ MUX_VAL(CP(MCSPI2_CS1), (IEN | PTD | EN | M3))
/*HSUSB2_DATA3*/\
+ MUX_VAL(CP(ETK_D10_ES2),(IDIS | PTD | DIS | M3)) /*HSUSB2_CLK*/\
+ MUX_VAL(CP(ETK_D11_ES2),(IDIS | PTD | DIS | M3)) /*HSUSB2_STP*/\
+ MUX_VAL(CP(ETK_D12_ES2),(IEN | PTD | EN | M3)) /*HSUSB2_DIR*/\
+ MUX_VAL(CP(ETK_D13_ES2),(IEN | PTD | EN | M3)) /*HSUSB2_NXT*/\
+ MUX_VAL(CP(ETK_D14_ES2),(IEN | PTD | EN | M3))
/*HSUSB2_DATA0*/\
+ MUX_VAL(CP(ETK_D15_ES2),(IEN | PTD | EN | M3))
/*HSUSB2_DATA1*/\
/*Control and debug */\
MUX_VAL(CP(SYS_32K),(IEN | PTD | DIS | M0)) /*SYS_32K*/\
MUX_VAL(CP(SYS_CLKREQ), (IEN | PTD | DIS | M0)) /*SYS_CLKREQ*/\
@@ -383,7 +383,8 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(MCBSP3_CLKX),(IEN | PTD | DIS | M4)) /*GPIO_141*/\
MUX_VAL(CP(UART2_CTS), (IEN | PTU | EN | M0)) /*UART2_CTS*/\
MUX_VAL(CP(UART2_RTS), (IDIS | PTD | DIS | M0)) /*UART2_RTS*/\
- MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M0)) /*UART2_TX*/
+ MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M0)) /*UART2_TX*/\
+ MUX_VAL(CP(UART2_RX), (IDIS | PTU | EN | M4)) /*GPIO_147*/
#define MUX_BEAGLE_XM() \
MUX_VAL(CP(GPMC_NCS5), (IDIS | PTD | EN | M4)) /*GPIO_56*/\
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] USB: Remove __attribute__ ((packed)) for struct ehci_hccr and ehci_hcor.
Remove __attribute__ ((packed)) to prevent byte access to soc
registers in some gcc versions.
Having patches to enable ehci for the BeagleBoard lying around for
several month, this one was the show-stopper.
Credits have to go to Laine Walker-Avina for
finding the problem.
Signed-off-by: Alexander Holler
---
drivers/usb/host/ehci.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 945ab64..df9f055 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -55,7 +55,7 @@ struct ehci_hccr {
#define HCS_N_PORTS(p) (((p) >> 0) & 0xf)
uint32_t cr_hccparams;
uint8_t cr_hcsp_portrt[8];
-} __attribute__ ((packed));
+};
struct ehci_hcor {
uint32_t or_usbcmd;
@@ -85,7 +85,7 @@ struct ehci_hcor {
#define FLAG_CF(1 << 0)/* true: we'll support "high
speed" */
uint32_t or_portsc[CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS];
uint32_t or_systune;
-} __attribute__ ((packed));
+};
#define USBMODE0x68/* USB Device mode */
#define USBMODE_SDIS (1 << 3)/* Stream disable */
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Provide pr_debug() and pr_info().
Hello, Am 01.04.2011 19:56, schrieb Wolfgang Denk: > Dear Alexander Holler, > > In message<1301674331-7476-1-git-send-email-hol...@ahsoftware.de> you wrote: >> Those are usefull for compatibility with the kernel. >> Remove the locally defined pr_debug() in atmel_mci.c. >> >> Signed-off-by: Alexander Holler >> --- >> drivers/mmc/atmel_mci.c |6 -- >> include/common.h|4 >> 2 files changed, 4 insertions(+), 6 deletions(-) > > NAK. This is just adding redundant overhead. I don;t want to have > yet another incarnation of macros which already exist. > > Either replace the code in drivers/mmc/atmel_mci.c by a simple > > #define pr_debug(fmt, args...) debug(fmt, ##args) > > or convert the code that uses this reference. > > And pr_info() is completrely redundant and not used anywhere. > > > If you really think that pr_debug() is so much better than debug(), > then convert ALL code to use that. But I am not a friend of such a > change. Than just forget this patch and someone else should add those macros to future imports of sources from the kernel. At least I will now do so. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Provide pr_debug() and pr_info().
Those are usefull for compatibility with the kernel.
Remove the locally defined pr_debug() in atmel_mci.c.
Signed-off-by: Alexander Holler
---
drivers/mmc/atmel_mci.c |6 --
include/common.h|4
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/atmel_mci.c b/drivers/mmc/atmel_mci.c
index 3946ffe..9d798ca 100644
--- a/drivers/mmc/atmel_mci.c
+++ b/drivers/mmc/atmel_mci.c
@@ -32,12 +32,6 @@
#include "atmel_mci.h"
-#ifdef DEBUG
-#define pr_debug(fmt, args...) printf(fmt, ##args)
-#else
-#define pr_debug(...) do { } while(0)
-#endif
-
#ifndef CONFIG_SYS_MMC_CLK_OD
#define CONFIG_SYS_MMC_CLK_OD 15
#endif
diff --git a/include/common.h b/include/common.h
index 893af5c..a1fe8df 100644
--- a/include/common.h
+++ b/include/common.h
@@ -119,11 +119,15 @@ typedef volatile unsigned charvu_char;
#ifdef DEBUG
#define debug(fmt,args...) printf (fmt ,##args)
#define debugX(level,fmt,args...) if (DEBUG>=level) printf(fmt,##args);
+#define pr_debug(fmt, args...) printf(fmt, ##args)
#else
#define debug(fmt,args...)
#define debugX(level,fmt,args...)
+#define pr_debug(fmt, args...)
#endif /* DEBUG */
+#define pr_info(fmt, args...) printf (fmt, ##args)
+
#define error(fmt, args...) do { \
printf("ERROR: " fmt "\nat %s:%d/%s()\n", \
##args, __FILE__, __LINE__, __func__); \
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3_beagle: Switch default console from ttyS2 to ttyO2
Am 24.03.2011 14:01, schrieb Albert ARIBAUD: > Cc:ing Dirk as the omap3_beagle maintainer, and Wolfgang for advice. ... > Apart from Thomas' question, there seems to be no Nak for this patch -- > I've taken the liberty to Cc: the board maintainer just in case -- so we > might as well apply it. > > Wolfgang, which tree is this patch supposed to go through? Mine because > the board is ARM? yours because it is a board, not arch, patch? Or > whichever? Oh, sorry, haven't seen that Dirk is the maintainer, I've only added the TI-maintainer to cc, which might be wrong. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] beagle bootcmd not set to CONFIG_BOOTCOMMAND in version2011.03-rc1
Hello, Am 16.03.2011 19:10, schrieb Egon Boormans: > Dear Mr. Aribaud and Mr. Fleming, > > As you're the ARM and MMC specialist, do have an answer to the question > below? I've already answered that but your mail-server send my answer back and you don't seem to read this mailing list. Here it is my answer again: http://lists.denx.de/pipermail/u-boot/2011-March/088308.html Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] git merge summary
Hello all, on that topic I've just seen a message from Linus which includes some thoughts from him on that topic: https://lkml.org/lkml/2011/3/10/538 In short "Now, I admit that it's a git usability bug ...". Ok, he doesn't refer actually to a missing summary, but nevertheless I found that message/thread informational. Just to come up with that topic again. ;) Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] beagle bootcmd not set to CONFIG_BOOTCOMMAND in version 2011.03-rc1
Hello, Am 05.03.2011 14:57, schrieb Egon Boormans: > It looks like the bootcmd doesn't get set to the CONFIG_BOOTCOMMAND value in > the 'include/configs/omap3_beagle.h' file. This value makes it into the > 'include/autoconf.mk' file but not into the printenv of the u-boot. If I ... > NAND: 256 MiB > MMC: OMAP SD/MMC: 0 > In:serial > Out: serial > Err: serial > Beagle xM Rev A > No EEPROM on expansion board > Die ID #6cf600011ff0015739eb0c00600f > Hit any key to stop autoboot: 0 > mmc - MMC sub system > > Usage: Looks like you have a Beagle XM with NAND and you've saved the environment there. Try "env default -f; saveenv" to reset the environment there to the default values. You could just clean the environment in the NAND too. For further reference read instructions for the BeagleBoard (w/o XM), the NAND on some XM doesn't officially exists and therefor is not mentionend in any documentation for the XM-version. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
Am 05.03.2011 13:31, schrieb Alexander Holler: > Hello Jason, > > I've just seen a patch which makes env import optional, so you might > consider adding CONFIG_CMD_IMPORTENV to omap3_beagle.h to be prepared > when env import will get optional. Sorry for the noise, the patch which makes it optional enables it by default, so no action is necessary. Haven't seen that at first. > Regards, > > Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
Hello Jason, I've just seen a patch which makes env import optional, so you might consider adding CONFIG_CMD_IMPORTENV to omap3_beagle.h to be prepared when env import will get optional. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
Am 03.03.2011 00:48, schrieb Robert Nelson: > On Wed, Mar 2, 2011 at 5:41 PM, Alexander Holler wrote: >> Hello Jason, >> >> Am 02.03.2011 21:26, schrieb Jason Kridner: >>> >>> For backwards compatibility the use of boot.scr is still supported. >>> >> >> Sorry, but I think that line in the description should get removed too. >> > > So, just a thought.. Are you guys planning to push this same boot > method to all the other "omap" devices that just finally got boot.scr > boot support by default in u-boot? It also seems's like it'll end up > be the FAQ of the month for the beagleboard group.. ;) I would say that should be decided by every board-maintainer, just like the change from ttyS2 to ttyO2. E.g. I don't think the devkit8000-sdk will change as soon as the stuff the for the beagleboard. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [beagleboard] Re: [PATCH v3] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
Hello, Am 03.03.2011 16:04, schrieb Jason Kridner: > On Wed, Mar 2, 2011 at 6:48 PM, Robert Nelson wrote: >> On Wed, Mar 2, 2011 at 5:41 PM, Alexander Holler >> wrote: >>> Hello Jason, >>> >>> Am 02.03.2011 21:26, schrieb Jason Kridner: >>>> >>>> For backwards compatibility the use of boot.scr is still supported. >>>> >>> >>> Sorry, but I think that line in the description should get removed too. > > I'll submit a v4. > >>> >> >> So, just a thought.. Are you guys planning to push this same boot >> method to all the other "omap" devices that just finally got boot.scr >> boot support by default in u-boot? It also seems's like it'll end up >> be the FAQ of the month for the beagleboard group.. ;) > > Indeed it is likely to be FAQ of the month, especially if it lands in > the next software update that gets shipped with the board. It is a > case, however, in which I like the answer--no more need to run > mkimage. The conversion process of a boot.scr script (commands) to a > uEnv.txt file (variable setting) won't be exactly trivial, so that has > me a tiny bit concerned. Still, most cases will be solved by a *much* > simpler uEnv.txt script and an overall simpler process. Hmm, if someone will write such an FAQ-entry, be sure to mention that people shouldn't use a windows-editor. I haven't tried it, but I don't believe env import likes carriage returns. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
Hello Jason, Am 02.03.2011 21:26, schrieb Jason Kridner: > For backwards compatibility the use of boot.scr is still supported. > Sorry, but I think that line in the description should get removed too. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
Hello, just a last word. I don't have to decide which patch is used and I don't have any problem if v2 is used. I'm able to modify bootcmd like I wish and can live with any version. I've justed wanted to make clear why I haven't used a simpler approach. Anyway, if v2 will be used, please just remove my name as author, I don't want to be responsible for the possible arising confusion. Everyone can still use as much from that patch as he wishes, please just don't use my name as author for a modified patch with a changed logic. ;) Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
Hello,
Am 02.03.2011 16:44, schrieb Jason Kridner:
> On Tue, Mar 1, 2011 at 9:54 PM, Alexander Holler wrote:
>> Hello Jason,
>>
>> On 02.03.2011 00:37, Jason Kridner wrote:
>>
>>> From: Alexander Holler
>>>
>>> Using the new env import command it is possible to use plain text files
>>> instead
>>> of script-images. Plain text files are much easier to handle.
>>>
>>> E.g. If your boot.scr contains the following:
>>> ---
>>> setenv dvimode 1024x768-16@60
>>> run loaduimage
>>> run mmcboot
>>> ---
>>> you could create a file named uEnv.txt and use that instead of boot.scr:
>>> ---
>>> dvimode=1024x768-16@60
>>> uenvcmd=run loaduimage; run mmcboot
>>> ---
>>> The variable uenvcmd (if existent) will be executed (using run) after
>>> uEnv.txt
>>> was loaded. If uenvcmd doesn't exist the default boot sequence will be
>>> started,
>>> therefore you could just use
>>> ---
>>> dvimode=1024x768-16@60
>>> ---
>>> as uEnv.txt because loaduimage and mmcboot is part of the default boot
>>> sequence.
>>>
>>> For backwards compatibility the use of boot.scr is still supported.
>>> ---
>>> Changes for v2:
>>>- Eliminated else redundant clause that would be ignored if boot
>>> succeeds.
>>
>>
>> If I interpret your change correctly, your v2 would use uEnv.txt and
>> boot.scr if both are existent. I think this would only lead to confusion.
>> My target was to get rid of boot.scr and to therefor boot.scr would be
>> ignored if uEnv.txt exists. I don't see any reason why boot.scr should be
>> still used when uEnv.txt exists.
>
> if uenvcmd results in a successful boot, then boot.scr would never get
> executed.
But that requires that uenvcmd is set/used which makes uEnv.txt
unnecessarily complex and will not be possible to define/change e.g.
only the (u-boot) environment variable dvimode.
> Again, my concern is that this default logic gets overly complex. A
> policy of applying linear attempt-then-fall-through will make patches
> to this logic apply cleanly as new boot sources are added,
> specifically if we ever get the USER button support upstream.
We could just delete the logic for boot.scr. Another approach would be
to print a warning like "The usage of boot.scr is deprecated and will be
removed with the next release!" if boot.scr will be used and delete the
stuff for boot.scr with the next release.
> I understand the goal of only using uEnv.txt and not using ucmdenv
> such that the u-boot default variables can be used to perform the
> boot. I think this goal can easily be achieved by deleting boot.scr.
> If boot.scr exists, I don't follow that it would be any less confusing
> to the user if it were to *not* be executed following uEnv.txt.
Again, I think such an approach will only confuse people because stuff
from two files might be used. And what is used will depend on what
u-boot is used. There might be people with an u-boot in NAND, for which
a boot.scr on an SD-card still is required. But if you want to serve
people with an new u-boot too, you'll need an uEnv.txt too. And with
your logic that has to use an uencmd, which makes uEnv.txt more
complicate than needed.
And most people never see the bootcmd, but they see uEnv.txt and/or
boot.scr because they have to define the resolution for their monitor there.
So I still would prefer to leave bootcmd currently a bit more
complicated, with the advantage that only a simple uEnv.txt is possible
which just contains e.g. "dvimode=1024x768-16@60".
>>> Signed-off-by: Jason Kridner
>>> Cc: Alexander Holler
>>> ---
>>> include/configs/omap3_beagle.h | 26 ++
>>> 1 files changed, 18 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/include/configs/omap3_beagle.h
>>> b/include/configs/omap3_beagle.h
>>> index f151e98..b7f5480 100644
>>> --- a/include/configs/omap3_beagle.h
>>> +++ b/include/configs/omap3_beagle.h
>>> @@ -229,6 +229,9 @@
>>> "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
>>> "bootscript=echo Running bootscript from mmc ...; " \
>>> "source ${loadaddr}\0" \
>>> + "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
>>> +
Re: [U-Boot] [beagleboard] Re: [PATCH] omap3_beagle: Switch default console from ttyS2 to ttyO2
Hello, Am 02.03.2011 11:50, schrieb Thomas Weber: > Hello Alexander, > Am 02.03.2011 00:13, schrieb Jason Kridner: >> On Fri, Feb 18, 2011 at 3:37 AM, Alexander Holler >> wrote: >>> Linux kernels>= 2.6.36 are using ttyOn instead ttySn for the >>> serials on OMAPs. ... > can you please do this for all omap3 boards? > Or we have in the end 10 patches for the same problem. Sorry, no. I don't know which boards are using which kernel versions and there are many boards around with and SDK which are using older kernels. I think the time of the change should be decided by every board-maintainer. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
Hello Jason,
On 02.03.2011 00:37, Jason Kridner wrote:
> From: Alexander Holler
>
> Using the new env import command it is possible to use plain text files
> instead
> of script-images. Plain text files are much easier to handle.
>
> E.g. If your boot.scr contains the following:
> ---
> setenv dvimode 1024x768-16@60
> run loaduimage
> run mmcboot
> ---
> you could create a file named uEnv.txt and use that instead of boot.scr:
> ---
> dvimode=1024x768-16@60
> uenvcmd=run loaduimage; run mmcboot
> ---
> The variable uenvcmd (if existent) will be executed (using run) after uEnv.txt
> was loaded. If uenvcmd doesn't exist the default boot sequence will be
> started,
> therefore you could just use
> ---
> dvimode=1024x768-16@60
> ---
> as uEnv.txt because loaduimage and mmcboot is part of the default boot
> sequence.
>
> For backwards compatibility the use of boot.scr is still supported.
> ---
> Changes for v2:
>- Eliminated else redundant clause that would be ignored if boot
> succeeds.
If I interpret your change correctly, your v2 would use uEnv.txt and
boot.scr if both are existent. I think this would only lead to confusion.
My target was to get rid of boot.scr and to therefor boot.scr would be
ignored if uEnv.txt exists. I don't see any reason why boot.scr should
be still used when uEnv.txt exists.
>
> Signed-off-by: Jason Kridner
> Cc: Alexander Holler
> ---
> include/configs/omap3_beagle.h | 26 ++
> 1 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
> index f151e98..b7f5480 100644
> --- a/include/configs/omap3_beagle.h
> +++ b/include/configs/omap3_beagle.h
> @@ -229,6 +229,9 @@
> "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
> "bootscript=echo Running bootscript from mmc ...; " \
> "source ${loadaddr}\0" \
> + "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
> + "importbootenv=echo Importing environment from mmc ...; " \
> + "env import -t $loadaddr $filesize\0" \
> "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
> "mmcboot=echo Booting from mmc ...; " \
> "run mmcargs; " \
> @@ -240,15 +243,22 @@
>
> #define CONFIG_BOOTCOMMAND \
> "if mmc rescan ${mmcdev}; then " \
> + "echo SD/MMC found on device ${mmcdev};" \
> + "if run loadbootenv; then " \
> + "run importbootenv;" \
> + "fi;" \
> + "if test -n $uenvcmd; then " \
> + "echo Running uenvcmd ...;" \
> + "run uenvcmd;" \
> + "fi;" \
> "if run loadbootscript; then " \
> - "run bootscript; " \
> - "else " \
> - "if run loaduimage; then " \
> - "run mmcboot; " \
> - "else run nandboot; " \
> - "fi; " \
> - "fi; " \
> - "else run nandboot; fi"
> + "run bootscript;" \
> + "fi;" \
> + "if run loaduimage; then " \
> + "run mmcboot;" \
> + "fi;" \
> + "fi;" \
> + "run nandboot;" \
>
> #define CONFIG_AUTO_COMPLETE1
> /*
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USBNET in OMAP (beagleboard)
Am 25.02.2011 00:06, schrieb Rick Bronson: >I've searched the mailing list archives and couldn't come up with an > answer so I thought I'd try here: Anyone know of any implementations > of USBNET in u-boot for OMAP? This feature allows the OMAP, as a USB > device (gadget), to do networking over a USB connection with a USB > host. Just load a kernel to do that. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: Use optimized memcpy and memset from linux
Hello, Am 26.01.2011 11:45, schrieb Matthias Weisser: > Using optimized versions of memset and memcpy from linux brings a quite > noticeable speed (x2 or better) improvement for these two functions. Thanks, tested on armv5 and armv7, therefor Tested-by: Alexander Holler Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Add comments why -msoft-float is used.
On 20.02.2011 11:20, Wolfgang Denk wrote: > No, not at all, because the only additional information about what Thanks, at least I tried it. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Add comments why -msoft-float is used.
Am 20.02.2011 10:52, schrieb Alexander Holler: > Am 20.02.2011 10:39, schrieb Alexander Holler: > >> # -msoft-float forces the compiler to avoid any fp-related instructions >> for optimizations. >> >> Would that be better? > > Anyway, I don't care about that patch. I now know the reason. ;) > > Btw, isn't soft-float useless on ARM when armv5 is used as architecture? To answer myself: No. See http://www.arm.com/products/processors/technologies/vector-floating-point.php Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Add comments why -msoft-float is used.
Am 20.02.2011 10:39, schrieb Alexander Holler: > # -msoft-float forces the compiler to avoid any fp-related instructions > for optimizations. > > Would that be better? Anyway, I don't care about that patch. I now know the reason. ;) Btw, isn't soft-float useless on ARM when armv5 is used as architecture? Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Add comments why -msoft-float is used.
Am 20.02.2011 09:42, schrieb Wolfgang Denk: > Dear Alexander Holler, > > In message<1298171532-5296-1-git-send-email-hol...@ahsoftware.de> you wrote: >> Without -msoft-float the compiler would be allowed to use certain >> floating-point instructions (VFP/NEON) e.g. for optimizations, which >> would require additional code, for example to save contexts for >> interrupts. Add a comment which describes this in short words. > > Hm... why do you see a need to explain this for ARM, but not so for > the other architectrures, say for PowerPC? I don't know how other the compiler behaves for other architectures and if those are having the need to save fp-contexts for irqs. > > If you really want to add this, then it should probably be somewhere > in the REAME or another central place of documentation (instead of > distributed over tons of Makefiles), and to make your message I prefer comments where they are usefull. Hiding them somewhere is useless. > understood you might want to add "additional code" may mean that > additional function blocks in the respective SoC may need to be > initialized and, for example, clocked, which may for example > significantly increase the power dissipation of the system. > >> +# -msoft-float forces the compiler to not use any fp-related instructions. > > Well, now this is a commonplace that says about nothing and can be > leftout as well. # -msoft-float forces the compiler to avoid any fp-related instructions for optimizations. Would that be better? Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: Add comments why -msoft-float is used.
Without -msoft-float the compiler would be allowed to use certain floating-point instructions (VFP/NEON) e.g. for optimizations, which would require additional code, for example to save contexts for interrupts. Add a comment which describes this in short words. Signed-off-by: Alexander Holler --- arch/arm/cpu/arm1136/config.mk |2 ++ arch/arm/cpu/arm1176/config.mk |2 ++ arch/arm/cpu/arm1176/s3c64xx/config.mk |2 ++ arch/arm/cpu/arm720t/config.mk |1 + arch/arm/cpu/arm920t/config.mk |1 + arch/arm/cpu/arm925t/config.mk |1 + arch/arm/cpu/arm926ejs/config.mk |1 + arch/arm/cpu/arm926ejs/davinci/config.mk |1 + arch/arm/cpu/arm946es/config.mk |1 + arch/arm/cpu/arm_intcm/config.mk |1 + arch/arm/cpu/armv7/config.mk |2 ++ arch/arm/cpu/armv7/omap-common/config.mk |2 ++ arch/arm/cpu/ixp/config.mk |1 + arch/arm/cpu/lh7a40x/config.mk |1 + arch/arm/cpu/pxa/config.mk |1 + arch/arm/cpu/s3c44b0/config.mk |1 + arch/arm/cpu/sa1100/config.mk|1 + 17 files changed, 22 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm1136/config.mk b/arch/arm/cpu/arm1136/config.mk index 3e68535..e2c32c0 100644 --- a/arch/arm/cpu/arm1136/config.mk +++ b/arch/arm/cpu/arm1136/config.mk @@ -20,6 +20,8 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # + +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float # Make ARMv5 to allow more compilers to work, even though its v6. diff --git a/arch/arm/cpu/arm1176/config.mk b/arch/arm/cpu/arm1176/config.mk index 14346cf..a9a36b4 100644 --- a/arch/arm/cpu/arm1176/config.mk +++ b/arch/arm/cpu/arm1176/config.mk @@ -20,6 +20,8 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # + +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float # Make ARMv5 to allow more compilers to work, even though its v6. diff --git a/arch/arm/cpu/arm1176/s3c64xx/config.mk b/arch/arm/cpu/arm1176/s3c64xx/config.mk index 14346cf..a9a36b4 100644 --- a/arch/arm/cpu/arm1176/s3c64xx/config.mk +++ b/arch/arm/cpu/arm1176/s3c64xx/config.mk @@ -20,6 +20,8 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # + +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float # Make ARMv5 to allow more compilers to work, even though its v6. diff --git a/arch/arm/cpu/arm720t/config.mk b/arch/arm/cpu/arm720t/config.mk index 3844c62..1d59f60 100644 --- a/arch/arm/cpu/arm720t/config.mk +++ b/arch/arm/cpu/arm720t/config.mk @@ -22,6 +22,7 @@ # MA 02111-1307 USA # +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float PLATFORM_CPPFLAGS += -march=armv4 -mtune=arm7tdmi diff --git a/arch/arm/cpu/arm920t/config.mk b/arch/arm/cpu/arm920t/config.mk index 8f6c1a3..b595088 100644 --- a/arch/arm/cpu/arm920t/config.mk +++ b/arch/arm/cpu/arm920t/config.mk @@ -21,6 +21,7 @@ # MA 02111-1307 USA # +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float PLATFORM_CPPFLAGS += -march=armv4 diff --git a/arch/arm/cpu/arm925t/config.mk b/arch/arm/cpu/arm925t/config.mk index 8f6c1a3..b595088 100644 --- a/arch/arm/cpu/arm925t/config.mk +++ b/arch/arm/cpu/arm925t/config.mk @@ -21,6 +21,7 @@ # MA 02111-1307 USA # +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float PLATFORM_CPPFLAGS += -march=armv4 diff --git a/arch/arm/cpu/arm926ejs/config.mk b/arch/arm/cpu/arm926ejs/config.mk index f8ef90f..fb83862 100644 --- a/arch/arm/cpu/arm926ejs/config.mk +++ b/arch/arm/cpu/arm926ejs/config.mk @@ -21,6 +21,7 @@ # MA 02111-1307 USA # +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float PLATFORM_CPPFLAGS += -march=armv5te diff --git a/arch/arm/cpu/arm926ejs/davinci/config.mk b/arch/arm/cpu/arm926ejs/davinci/config.mk index 565adda..081c13d 100644 --- a/arch/arm/cpu/arm926ejs/davinci/config.mk +++ b/arch/arm/cpu/arm926ejs/davinci/config.mk @@ -21,6 +21,7 @@ # MA 02111-1307 USA # +# -msoft-float forces the compiler to not use any fp-related instructions. PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float PLATFORM_CPPFLAGS += -march=armv5te diff --git a/arch/arm/cpu/arm946es/config.mk b/arch/arm/cpu/arm946es/config.mk index e783f69..f7db925 100644 --- a/arch/arm/cpu/arm946es/config.mk +++ b/arch/arm/cpu/arm946es/config.mk @@ -21,6 +21,7 @@ # MA 02111-1307 USA
Re: [U-Boot] reasons for armv5 as default
Hello, Am 19.02.2011 18:48, schrieb Albert ARIBAUD: > You're missing the fact that floating point code is a no-no in U-Boot. > We're not talking about the best option to support floating-point code > in U-Boot, but the best option to catch the use of floating point. Please don't turn the words in my mouth. Anyway, I now know why -msoft-float is used. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
