Re: [U-Boot] [PATCH v3 17/21] arm: Implement the 'fake' go command
On Wed, Jun 19, 2013 at 9:15 PM, Simon Glass wrote:
>
> Implement this feature on ARM for tracing.
>
> It would be nice to have generic bootm support so that it is easily
> implemented on any arch.
>
> Signed-off-by: Simon Glass
> ---
> Changes in v3:
> - Revert to using 'images' instead of 'image' in boot_jump_linux()
>
> Changes in v2: None
>
> arch/arm/lib/bootm.c | 27 ++-
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index 1b6e0ac..b22fbc9 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -68,12 +68,19 @@ void arch_lmb_reserve(struct lmb *lmb)
> gd->bd->bi_dram[0].start + gd->bd->bi_dram[0].size - sp);
> }
>
> -static void announce_and_cleanup(void)
> +/**
> + * announce_and_cleanup() - Print message and prepare for kernel boot
> + *
> + * @fake: non-zero to do everything except actually boot
> + */
> +static void announce_and_cleanup(int fake)
> {
> - printf("\nStarting kernel ...\n\n");
> + printf("\nStarting kernel ...%s\n\n", fake ?
> + "(fake run for tracing)" : "");
> bootstage_mark_name(BOOTSTAGE_ID_BOOTM_HANDOFF, "start_kernel");
> #ifdef CONFIG_BOOTSTAGE_FDT
> - bootstage_fdt_add_report();
> + if (flag == BOOTM_STATE_OS_FAKE_GO)
> + bootstage_fdt_add_report();
> #endif
was this ever compiled with CONFIG_BOOTSTAGE_FDT defined? `flag' is
not defined here, compilation fails for me when I try enabling this
config...
--vb
> #ifdef CONFIG_BOOTSTAGE_REPORT
> bootstage_report();
> @@ -225,12 +232,13 @@ static void boot_prep_linux(bootm_headers_t *images)
> }
>
> /* Subcommand: GO */
> -static void boot_jump_linux(bootm_headers_t *images)
> +static void boot_jump_linux(bootm_headers_t *images, int flag)
> {
> unsigned long machid = gd->bd->bi_arch_number;
> char *s;
> void (*kernel_entry)(int zero, int arch, uint params);
> unsigned long r2;
> + int fake = (flag & BOOTM_STATE_OS_FAKE_GO);
>
> kernel_entry = (void (*)(int, int, uint))images->ep;
>
> @@ -243,14 +251,15 @@ static void boot_jump_linux(bootm_headers_t *images)
> debug("## Transferring control to Linux (at address %08lx)" \
> "...\n", (ulong) kernel_entry);
> bootstage_mark(BOOTSTAGE_ID_RUN_OS);
> - announce_and_cleanup();
> + announce_and_cleanup(fake);
>
> if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
> r2 = (unsigned long)images->ft_addr;
> else
> r2 = gd->bd->bi_boot_params;
>
> - kernel_entry(0, machid, r2);
> + if (!fake)
> + kernel_entry(0, machid, r2);
> }
>
> /* Main Entry point for arm bootm implementation
> @@ -270,13 +279,13 @@ int do_bootm_linux(int flag, int argc, char *argv[],
> bootm_headers_t *images)
> return 0;
> }
>
> - if (flag & BOOTM_STATE_OS_GO) {
> - boot_jump_linux(images);
> + if (flag & (BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO)) {
> + boot_jump_linux(images, flag);
> return 0;
> }
>
> boot_prep_linux(images);
> - boot_jump_linux(images);
> + boot_jump_linux(images, flag);
> return 0;
> }
>
> --
> 1.8.3
>
> ___
> 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] 460GT PCIe configuration
On Tue, Mar 10, 2009 at 2:23 PM, Leon Woestenberg wrote: > Hello Vadim, Stefan, > Hi Leon, thank you for your interest, the problem I was dealing with has been long fixed. What happened was that in the Read transaction response the FPGA was setting one of the header attributes to a value different from what the transaction originator (460GT root complex) requested. The analyzer was not even highlighting that as a potential issue (even though it was showing the discrepancy between request and response headers). It turned out that the 460GT PCIe core was much more sensitive (some would say closer to the spec and thus more correct) than some other CPUs, and was just ignoring the PCIe responses with incorrect header contents, eventually generating PCIe timeouts which caused and were reported as PLB timeouts (because this is where the CPU was waiting). Very poor error reporting mechanism, but we have to do with what we have to do :-) cheers, /vb > On Wed, Jan 14, 2009 at 5:42 PM, vb wrote: >> On Wed, Jan 14, 2009 at 7:03 AM, Stefan Roese wrote: >>> On Tuesday 13 January 2009, vb wrote: >>> >>>> I have several different targets with different PCIe components, but >>>> all using the same base CPU subsystem design, and on some of them PCIe >>>> components misbehave, namely, PCIe memory read transactions fail with >>>> a machine check after a timeout, even though the PCIe side of things >>>> is fine (when looking with a protocol analyzer). >>> >> on our own design). The one which fails is based on the very similar >> 460GT based platform, but uses an Altera FPGA with a standard Altera >> PCIe interface implementation. >> >> What happens is that config space transactions (both read and write) >> and memory writes work fine, but attempts to read Altera's memory >> mapped space causes a machine check with very vague error reporting. >> > > Vadim, I am currently designing a Altera FPGA PCIe application and > testing on the AMCC460EX as one of the targets, so I may provide some > hints on where to look. I debugged *without* protocol analyser and > also hit some emachine check exceptions when the FPGA logic was still > misbehaving. > > Let me just throw some hints and references your way, hope they might be > useful: > > Do you use a reference design? > Does the FPGA application respond to the reads? > Do you map the BARs correctly? > Do you use 32-bit read/writes, 32-bit alignment? > > In the linux-next GIT tree, my driver for the Altera PCIe Chaining DMA > design is included: > drivers/staging/altpciechdma/altpciechdma.c > > Best regards, > -- > Leon > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] troubles trying to build glacier image
I am trying to build a kernel image for the AMCC glacier board, using the latest denx linux kernel vv linux-2.6-denx 128 > git show commit 5a7b6e7d15253c01ee0f0b8846b78e2ca23ef40d Merge: 2f9f8f1... ae04d14... Author: Wolfgang Denk Date: Mon Jan 12 13:35:39 2009 +0100 Merge branch 'master' of /home/git/linux-2.6 ^^ following instructions outlined in http://www.denx.de/wiki/view/DULG/Manual?stickboard=glacier One thing which is wrong from the get go is that the make ARCH=powerpc CROSS_COMPILE=440fp-linux-gnu- glacier_defconfig command fails, complaining that arch/powerpc/configs/glacier_defconfig is nowhere to be found. And indeed it does not exist. If I specify the parent directory, as in: make ARCH=powerpc 44x/glacier_defconfig it works, which I hope is the right way to do it. A bigger problem though (which I can't find a way to get around) is that it fails to build: linux-2.6-denx 129 > make ARCH=powerpc CROSS_COMPILE=440fp-linux-gnu- uImage CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm -> include/asm-powerpc CALLscripts/checksyscalls.sh CHK include/linux/compile.h CALLarch/powerpc/kernel/systbl_chk.sh CC arch/powerpc/kernel/prom_init.o CALLarch/powerpc/kernel/prom_init_check.sh make[2]: *** No rule to make target `arch/powerpc/platforms/44x/canyonlands.o', needed by `arch/powerpc/platforms/44x/built-in.o'. Stop. make[1]: *** [arch/powerpc/platforms/44x] Error 2 make: *** [arch/powerpc/platforms] Error 2 ^^ and indeed, there is no file arch/powerpc/platforms/44x/canyonlands.c in the tree - there are different versions for different build modes (nand, sata, etc.). So, what's the way to build this target from the denx linux tree? Am I missing something in the manual, or does it need to be tweaked? TIA, vadim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 460GT PCIe configuration
On Wed, Jan 14, 2009 at 7:03 AM, Stefan Roese wrote: > On Tuesday 13 January 2009, vb wrote: > >> The CONFIG_SYS_PCIE0_XCFGBASE constant (and its counterparts for other >> PCIe ports) is defined and used in the code, and gets a TLB entry >> assigned, but I can't find a place where it is programmed into the CPU >> - how does it know where this section is?! > > Again you seem to be correct here. I can't find a place where this area is > programmed. I don't have the time to dig into this right now, so it would be > great if you could work on this a little deeper. I suggest to look at the > Linux 4xx PCI driver (arch/powerpc/sysdev/ppc4xx_pci.c) as reference. > Stefan, thank you for confirming my suspicions and for your suggestion, I will compare notes with the Linux version (should have thought about this earlier). But I also was under impression that Linux does not touch some parts of PCI configuration, as the memory map is set by u-boot and used by Linux. Or does linux use the addresses from the device tree to reprogram the PCIe subsystem? >> I have several different targets with different PCIe components, but >> all using the same base CPU subsystem design, and on some of them PCIe >> components misbehave, namely, PCIe memory read transactions fail with >> a machine check after a timeout, even though the PCIe side of things >> is fine (when looking with a protocol analyzer). > > Is this all 460EX? Or some other 4xx? What are the PCIe endpoints you are > using? Do you see the same problems on Canyonlands as well? > This is 460GT, so the eval board is glacier, not canyonlands. The PCI endpoints which work are an Intel NIC (tried it with the glacier), and some Broadcom integrated ethernet switches (those work on our own design). The one which fails is based on the very similar 460GT based platform, but uses an Altera FPGA with a standard Altera PCIe interface implementation. What happens is that config space transactions (both read and write) and memory writes work fine, but attempts to read Altera's memory mapped space causes a machine check with very vague error reporting. I will try submitting diffs for your review, but I need to get to the bottom of this first... cheers, vadim > Best regards, > Stefan > > = > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de > = > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] 460GT PCIe configuration
Stefan et al, I am trying to troubleshoot a weird PCIe problem on a PPC460GT based target, and it is getting curiouser and curiouser. There is a tlb overlap I mentioned in an earlier email; on top of that there are some things happening in cpu/ppc4xx/4xx_pcie.c which I also find hard to understand: there is a static function pcie_get_base(), which returns a value as in address = pcie_get_base(hose, devfn) there are two instances of this, in both cases `address' is never used. The CONFIG_SYS_PCIE0_XCFGBASE constant (and its counterparts for other PCIe ports) is defined and used in the code, and gets a TLB entry assigned, but I can't find a place where it is programmed into the CPU - how does it know where this section is?! I have several different targets with different PCIe components, but all using the same base CPU subsystem design, and on some of them PCIe components misbehave, namely, PCIe memory read transactions fail with a machine check after a timeout, even though the PCIe side of things is fine (when looking with a protocol analyzer). Any insight/explanations/suggestions would be highly appreciated, TIA, vadim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PPC460GT Canyonlands tlb table overlap?
The Canyonland board's init.s file (board/amcc/canyonlands/init.S) defines the contents of the TLB table for that target, it has these two records in the table among others: tlbentry(CFG_PCI_BASE, SZ_256M, 0x, 0xC, AC_R|AC_W|SA_G|SA_I) tlbentry(CFG_PCIE_BASE, SZ_16K, 0x0801, 0xC, AC_R|AC_W|SA_G|SA_I) Am I missing something, or do they indeed overlap (the first record in fact encapsulates the second one on the physical address side). TIA, vadim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Handling different ethernhet phys on the same system.
On Fri, Sep 26, 2008 at 10:03 AM, Ben Warren <[EMAIL PROTECTED]> wrote: > > This is a topic that has been brought up many times before. I actually > started porting the Linux PHY stuff, but quickly realized that my limited > CPU cycles would be better spent cleaning up the overall Ethernet driver > architecture, with the PHY stuff to come later. > > I like your ideas. In addition to the inflexibility that you've mentioned, > there's a lot of code duplication (see, for example the number of PHYs that > are listed in the TSEC driver). One of the things that's difficult to > balance, and I don't know too many other peoples opinions, is how much board > C code is acceptable, versus how much information should be specified by > CONFIG_x definitions. If everybody suddenly has to define an elaborate > array of structs in board code rather than a few CONFIGs, usability goes > down. I don't really care, since IMHO you should know what you're doing > when you port a bootloader, but maybe others feel differently. > > Another thing to keep in mind is that we don't need to strongly bind a PHY > type to an interface, really just a bus/ address (assuming we're using > MDIO), since the devices are mostly probe-able. > Ben, great to hear that we think the same :-) You are right that the PHYs can be probed, so there is no need to attach any particular driver ahead of time, the only thing required from the developer would the MDIO address defined in CONFIG_PHYSx_ADDR as it is already done today. Also, we can provide a 'catch all' driver relying on the standard PHY register definition to fall back to if probing finds a PHY for which a driver is not available. > Good conversation - let's keep it going. It would be great if you could > work on this. > Absolutely, I'll look into implementing something along these lines, it is interesting to see what others think, cheers, Vadim > regards, > Ben > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Handling different ethernhet phys on the same system.
[cc] On Fri, Sep 26, 2008 at 8:42 AM, Anton Vorontsov <[EMAIL PROTECTED]> wrote: > On Fri, Sep 26, 2008 at 08:36:28AM -0700, vb wrote: > [...] >> What do you think? > > Something like linux/drivers/net/phy/? Sounds great, but somebody > need to port it. ;-) > Yes, this is a popular scheme, I don't claim to be its inventor. :-) Obviously Linux model is not applicable as is, but the idea is very similar, you are right, cheers, /vb > -- > Anton Vorontsov > email: [EMAIL PROTECTED] > irc://irc.freenode.net/bd2 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Handling different ethernhet phys on the same system.
Hello Ben,
I am trying to port u-boot on a system which deploys two different
types of ethernet PHYs, and don't see a good way of doing it with the
current sw structure.
There are concurrent implementations for supporting different PHYs,
and it looks like quite often bringing in a new etherent controller
brings in a duplicate PHY driver code. OTOH it is always presumed that
the same kind of phy is used on all ports.
I want to modify this scheme, but I don't want to go too far on a
tangent, as we here plan to integrate our changes back into the master
repository one of those days.
Here is what I suggest doing:
we introduce a concept of 'phy bus' - an MDIO bus for instance, and
'phy interface' which is the phy driver.
For illustration purpose, the phy bus could look like this:
struct phy_bus {
int (*write)(u8 addr, u16 reg, u16 value);
int (*read)(u8 addr, u16 reg, u16 *value);
}
and the driver would provide methods like
struct phy_driver {
int (*reset)(struct phy_bus*, u8 addr))
int (*init)(struct phy_bus*, u8 addr)
...
}
the set of methods could be fine tuned at any time obviously, the
important thing is that each method would receive the pointer to the
phy bus to be used to communicate with the device.
Then, in the ethernet device structure we would add two pointers: to
the bus serving the port and to the driver serving the port.
This would allow any new ethernet controller provide its own mdio bus
implementation and then use existing phy driver the same way any other
controller uses it. This would also allow to attach different phy
devices to different ethernet ports. And of course the multiple PHY
implementations won't be needed anymore, just one instance will serve
any ethernet device.
What do you think?
TIA,
Vadim
On Thu, Sep 25, 2008 at 11:09 PM, Ben Warren <[EMAIL PROTECTED]> wrote:
> Wolfgang Denk wrote:
>> Dear Ben,
>>
>> I just ran over this piece of code in NetLoop() [see "net/net.c"]:
>>
>> 286 int
>> 287 NetLoop(proto_t protocol)
>> 288 {
>> ...
>> 322 eth_halt();
>> 323 #ifdef CONFIG_NET_MULTI
>> 324 eth_set_current();
>> 325 #endif
>> 326 if (eth_init(bd) < 0) {
>> 327 eth_halt();
>> 328 return(-1);
>> 329 }
>>
>> Am I reading this correctly that we eth_halt() and eth_init() the
>> network interface for each and every call to NetLoop?
>>
>>
> Yes, it looks that way. Ripe for gutting.
>> This looks terribly inefficient to me - is there any rationale behind
>> this?
>>
>>
> Probably, but it escapes me. It most certainly predates my involvement
> in this project.
>> Also, the eth_set_current() checking should IMHO be done just once,
>> before we start a network transfer, or when we actually switch
>> interfaces, but not for each and every call to NetLoop() ?
>>
>>
> Maybe, but eth_set_current() is pretty lightweight. NetLoop is only
> called when we start a network transfer, so this doesn't seem too
> egregious. It could definitely stand to be refactored.
>> Best regards,
>>
>> Wolfgang Denk
>>
>>
> regards,
> Ben
> ___
> 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] reinitialize peripherals
On Tue, Aug 26, 2008 at 8:06 PM, Fundu <[EMAIL PROTECTED]> wrote: > I have a PPC440GX based board. > > Do I need to reinitialize Peripheral Bank Configuration Registers > (EBC0_B0CR-EBC0_B7CR) from the kernel ? > I'm quite sure that we don't, but just want to make sure. Because the problem > that i'm seeing strongly suggest that something isn't initializing. > > Here's the problem i'm getting a kernel "kernel access of bad > area" when i erase flash region, surprisingly i can easily erase it from > u-boot. which makes me ask the earlier question. > The problem is that the kernel needs to ioremap the areas you are trying to access (this includes flash, BTW). How it gets the information about the address ranges is the tricky part: it comes from the device tree, (unless you are building your kernel from arch/ppc). There are a lot of examples in arch/powerpc/boot/dts. Also, keep in mind that on ppc460 (I am not sure if 440gx is the same, but it might be) the addresses of the peripherals driven by CSs have nonzero nibble in four MSBs of the 36 bit address, so phys_addr_t is 64 bits in size. good luck. /vb > any insights welcome. > > thanks ! > > > > ___ > 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] TFTP images larger than 16MB causing MachineCheck on 405ex
I am not sure how much this is related, but it is a known problem that older tftp servers can't serve files larger than 16Mbytes in size. hth, /vb On Fri, Aug 22, 2008 at 12:57 PM, <[EMAIL PROTECTED]> wrote: > I have been searching the web, but I have not seen any mention of this kind > of problem. > > I am using a custom 405ex board based on Kilauea, with NAND boot. (256MB > NAND and 256MB DDR DRAM.) The DRAM passes all tests, and the board boots > into Linux fine. When adding code to the initrd, we found that any image > > 16MB seemed to cause this problem after being loaded. > I also tested on Kilauea, and it happens but only with a uboot 1.3.3 image > running from NAND, the default NOR image does not fail. (1.3.2 rc2 ?) > > To reproduce, I download an initrd (uRamdisk) using tftp in uboot and then > use 'iminfo' and it causes a machine check. The strings from the > image_get_xxx() functions appear to be bogus and printf crashes. > (image_get_os, image_get_arch...) I am debugging it now, but I was hoping > someone else had seen this already. > > = FROM UBOOT CONSOLE = > > => tftp 20 uRamdisk > ... download completes ... > => iminfo > ## Checking Image at 0020 ... > Legacy image found > Image Name: Linux-2.6.25.5 > Created: 2008-08-20 22:17:07 UTC > Image Type: Machine Check Exception. > Caused by (from msr): regs 0ff0f310 Data machine check. > NIP: XER: 005F LR: 0FFCA940 REGS: 0ff0f310 TRAP: 0200 DEAR: > > MSR: EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00 > > GPR00: 0FF0F400 0FF0FF44 60C21FAD 0FF0F450 01048A68 > GPR08: 0FFA1BD8 60C21FAD 0FFD8838 0002 2FAF 0FFEAB00 0FFD83F4 > GPR16: 0FFD8418 0FFD8424 0FF0F994 0FF0F894 0FF0F7DD 0FF0F750 0FFE1468 > GPR24: 0FF0F418 0FF0F45C 60C21FAD 0FF0F5D7 0FFEC204 0FF0F450 > Call backtrace: > 0FF0F45C 0FFCAB9C 0FFBE4C8 9AE6C2BD > machine check > > == > > Any information would help. > Thank you, > Jeff > > Jeff Hemstreet > [EMAIL PROTECTED] > > > > ___ > 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
