- Jul 28, 2014
-
-
git://git.denx.de/u-boot-mpc85xxTom Rini authored
-
Masahiro Yamada authored
If Series-to tag is missing, Patman exits with a message "No recipient". This is just annoying for those who had already added sendemail.to configuration. I guess many developers have [sendemail] to = u-boot@lists.denx.de in their .git/config because the 'To: u-boot@lists.denx.de' field should always be added when sending patches. That seems more reasonable rather than adding 'Series-to: u-boot@lists.denx.de' to every patch series. Patman should exit only when both Series-to tag and sendemail.to configuration are mising. Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Simon Glass <sjg@chromium.org> Acked-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
At present buildman always builds out-of-tree, that is it uses a separate output directory from the source directory. Normally this is what you want, but it is important that in-tree builds work also. Some Makefile changes may break this. Add a -i option to tell buildman to use in-tree builds, so that it is easy to test this feature. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Normally buildman wil try to configure U-Boot for a particular board on the first commit that it builds in a series. Subsequent commits are built without reconfiguring which normally works. Where it doesn't, buildman automatically reconfigures and retries. To fully emulate the way MAKEALL works, we should have an option to disable this optimisation. Add a -C option to cause buildman to always reconfigure on each commit. Signed-off-by:
Simon Glass <sjg@chromium.org>
- Jul 25, 2014
-
-
git://git.denx.de/u-boot-shTom Rini authored
-
Dirk Eibach authored
Add the generic board infrastructure to all gdsys boards. Signed-off-by:
Dirk Eibach <dirk.eibach@gdsys.cc> Signed-off-by:
Stefan Roese <sr@denx.de>
-
Dirk Eibach authored
The generic board infrastructure assumes that gd is set by arch code. Signed-off-by:
Dirk Eibach <dirk.eibach@gdsys.cc> Signed-off-by:
Stefan Roese <sr@denx.de>
-
- Jul 24, 2014
-
-
Masahiro Yamada authored
The linker scripts of sh2/sh3/sh4 are almost the same. The difference among them is essentially only one line. They can be consolidated into a single file, arch/sh/cpu/u-boot.lds by re-writing the diffrent line as follows: KEEP(*/start.o (.text)) Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by:
Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
-
- Jul 23, 2014
-
-
Shengzhou Liu authored
Tested with NOR boot and NAND boot on T2080QDS and T2080RDB. Signed-off-by:
Shengzhou Liu <Shengzhou.Liu@freescale.com>
-
Simon Glass authored
After a build fails buildman will reconfigure and try again, if it did not reconfigure before the build. However it doesn't actually keep track of whether it did reconfigure on the previous attempt. Fix that logic to avoid a pointless rebuild. This speeds things up quite a bit for failing builds. Previously they would always be built twice. Change-Id: Ib37f21320baa7c60bed98f4042c0b7ed7c0dc85e Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Generally a build failure with a particular commit cannot be fixed except by changing that commit. Changing the commit will automatically cause buildman to retry when you run it again: buildman sees that the commit hash is different and that it has no previous build result for the new commit hash. However sometimes the build failure is due to a toolchain issue or some other environment problem. In that case, retrying failed builds may yield a different result. Add a flag to retry failed builds. This differs from the force rebuild flag (-f) in that it will not rebuild commits which are already marked as succeeded. Series-to: u-boot Change-Id: Iac4306df499d65ff0888b1c60f06fc162a6faad8
-
Simon Glass authored
Uclasses should be named, so add a name for the demo uclass. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Some boards will have devices which are not in the device tree and do not have platform data. They may be programnatically created, for example. Add a hook which boards can use to bind those devices early in boot. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add a debug message for when a device tree node has no driver. Also reword the warning when a device fails to bind, which was misleading. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Some devices (particularly bus devices) must track their children, knowing when a new child is added so that it can be set up for communication on the bus. Add a child_pre_probe() method to provide this feature, and a corresponding child_post_remove() method. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Some device types can have child devices and want to store information about them. For example a USB flash stick attached to a USB host controller would likely use this space. The controller can hold information about the USB state of each of its children. The data is stored attached to the child device in the 'parent_priv' member. It can be auto-allocated by dm when the child is probed. To do this, add a per_child_auto_alloc_size value to the parent driver. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Devices can have childen that can be addressed by a simple index, the sequence number or a device tree offset. Add functions to access a child in each of these ways. The index is typically used as a fallback when the sequence number is not available. For example we may use a serial UART with sequence number 0 as the console, but if no UART has sequence number 0, then we can fall back to just using the first UART (index 0). The device tree offset function is useful for buses, where they want to locate one of their children. The device tree can be scanned to find the offset of each child, and that offset can then find the device. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
At present only root nodes in the device tree are scanned for devices. But some devices can have children. For example a SPI bus may have several children for each of its chip selects. Add a function which scans subnodes and binds devices for each one. This can be used for the root node scan also, so change it. A device can call this function in its bind() or probe() methods to bind its children. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Fix up the style of a few comments and add/clarify a few others. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This simple function returns the node offset of a named alias. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Don't allow access to uclasses before they have been initialised. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Each device that was bound from a device tree has an node that caused it to be bound. Add functions that find and return a device based on a device tree offset. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add this information to 'dm tree' and 'dm uclass' commands. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
In U-Boot it is pretty common to number devices from 0 and access them on the command line using this numbering. While it may come to pass that we will move away from this numbering, the possibility seems remote at present. Given that devices within a uclass will have an implied numbering, it makes sense to build this into driver model as a core feature. The cost is fairly small in terms of code and data space. With each uclass having numbered devices we can ask for SPI port 0 or serial port 1 and receive a single device. Devices typically request a sequence number using aliases in the device tree. These are resolved when the device is probed, to deal with conflicts. Sequence numbers need not be sequential and holes are permitted. At present there is no support for sequence numbers using static platform data. It could easily be added to 'struct driver_info' if needed, but it seems better to add features as we find a use for them, and the use of -1 to mean 'no sequence' makes the default value somewhat painful. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This command currently activates devices as it lists them. This is not desirable since it changes the system state. Fix it and avoid printing a newline if there are no devices in a uclass. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
The device display for 'dm tree' and 'dm uclass' is mostly the same, so move it into a common function. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Aliases are used to provide U-Boot's numbering of devices, such as: aliases { spi0 = "/spi@12330000"; } spi@12330000 { ... } This tells us that the SPI controller at 12330000 is considered to be the first SPI controller (SPI 0). So we have a numbering for the SPI node. Add a function that returns the numbering for a node assume that it exists in the list of aliases. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Several functions will use this same pattern, so bring it into a function. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
For sandbox we have a fallback console which is used very early in U-Boot, before serial drivers are available. Rather than try to guess when to switch to the real console, add a flag so we can be sure. This makes sure that sandbox can always output a panic() message, for example, and avoids silent failure (which is very annoying in sandbox). Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
If the console is not present, we try to reduce overhead by stopping any output in vprintf(), before it gets to putc(). This is of dubious merit in general, but in the case of sandbox it is incorrect since we have a fallback console which reports errors very early in U-Boot. If this is defeated U-Boot can hang or exit with no indication of what is wrong. Remove the optimisation for sandbox. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
The current functions for adding and removing devices require a device name. This is not convenient for driver model, which wants to store a pointer to the relevant device. Add new functions which provide this feature and adjust the old ones to call these. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Initialise devices marked 'pre-reloc' and make them available prior to relocation. Note that this requires pre-reloc malloc() to be available. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Driver model currently only operates after relocation is complete. In this state U-Boot typically has a small amount of memory available. In adding support for driver model prior to relocation we must try to use as little memory as possible. In addition, on some machines the memory has not be inited and/or the CPU is not running at full speed or the data cache is off. These can reduce execution performance, so the less initialisation that is done before relocation the better. An immediately-obvious improvement is to only initialise drivers which are actually going to be used before relocation. On many boards the only such driver is a serial UART, so this provides a very large potential benefit. Allow drivers to mark themselves as 'pre-reloc' which means that they will be initialised prior to relocation. This can be done either with a driver flag or with a 'dm,pre-reloc' device tree property. To support this, the various dm scanning function now take a 'pre_reloc_only' parameter which indicates that only drivers marked pre-reloc should be bound. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Drivers are supposed to be able to close down cleanly. To set a good example, make sandbox shut down its driver model drivers and remove them before exit. It may be desirable to do the same more generally once driver model is more widely-used. This could be done during bootm, before U-Boot jumps to the OS. It seems far too early to make this change. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add a new method which removes and unbinds all drivers. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Marek Vasut <marex@denx.de>
-
Simon Glass authored
The root device should be probed just like any other device. The effect of this is to mark the device as activated, so that it can be removed (along with its children) if required. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Marek Vasut <marex@denx.de>
-
Simon Glass authored
At present stdio device functions do not get any clue as to which stdio device is being acted on. Some implementations go to great lengths to work around this, such as defining a whole separate set of functions for each possible device. For driver model we need to associate a stdio_dev with a device. It doesn't seem possible to continue with this work-around approach. Instead, add a stdio_dev pointer to each of the stdio member functions. Note: The serial drivers have the same problem, but it is not strictly necessary to fix that to get driver model running. Also, if we convert serial over to driver model the problem will go away. Code size increases by 244 bytes for Thumb2 and 428 for PowerPC. 22: stdio: Pass device pointer to stdio methods arm: (for 2/2 boards) all +244.0 bss -4.0 text +248.0 powerpc: (for 1/1 boards) all +428.0 text +428.0 Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Marek Vasut <marex@denx.de>
-
Simon Glass authored
There is no point in setting a structure's memory to NULL when it has already been zeroed with memset(). Also, there is no need to create a stub function for stdio to call - if the function is NULL it will not be called. This is a clean-up, with no change in functionality. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Marek Vasut <marex@denx.de>
-
Simon Glass authored
Rather than reusing the 'reg' property, use an explicit property for the expected ping value used in testing. Signed-off-by:
Simon Glass <sjg@chromium.org>
-