> The GLOBAL_BOOT_MODE_ADDR for i.MX28 is taken from an U-Boot patch for the
> MX28EVK:
> http://repository.timesys.com/buildsources/u/u-boot/u-boot-2009.08/u-boot-2009.08-mx28-201012211513.patch
It could be 0x0001a7f0 too:
/* The global boot mode will be detected by ROM code and
* a boot mode v
Hi,
Currently, the mxsboot tool checks all parsed options for being an even number,
including
the partition sector for SD/MMC devices. I don't believe such a restriction
exists; I've been
(unintentionally) using an odd sectored part ion for some time now.
Shall I change it? If yes; any objectio
Hi Marek,
I'm currently working on U-Boot support for the Freescale i.mx28evk board. It
started out as
an update of the old Freescale supplied U-Boot 2009.08, but it ended up in
reconfiguring
your work on the Denx m28evk module. Today I stumbled upon a problem with
Ethernet.
It turned out that
>> I'm currently working on U-Boot support for the Freescale i.mx28evk board.
>
> This is already supported mainline.
Hm; my workspace is quite up-to-date, but I didn't find it. What configuration
should I use for the Freescale i.mx28evk board? m28evk_config boots the
board, but not much more. Th
> make mx28evk_config? board/freescale/mx28evk
Are you sure you checked it in? I checked, but I couldn't find it.
(http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=tree;f=include/configs;h=fe894c3b95e3d154264c2f8731b668c410131f01;hb=HEAD)
> Yes, it can go both ways.
For the SoC I understand.
> Please use Stefano's imx git tree, which has support for mx28evk already.
Thanks for the heads-up. It's a bit confusing and unexpected to have a mainline
spread across different git trees; Will Stefano's mainline be integrated into
the main-mainline sometime?
> m28evk and mx28evk differ in th
> Not really ... that's how it all works. When Stefano sends pull RQ, it'll go
> mainline.
Aha, so it's not mainline yet after all ;-) But I get it; It's available in
Fabio's
repo and will be in Denx mainline soon.
> I see no problems with the board DRAM detection on our board, no. I tested
>
Hi Matthias,
I have a fully functional U-Boot for the mx28evk board:
- Both Ethernet ports work
- Both MMC slots work
- NAND works (if configure in, one MMC slot will be configured out, due to
shared pins)
- USB works
- I2C works
- Currently working on SPI
It's basically an integration of u-boot
Hi Stefano,
Can I post a patch for your u-boot-imx tree with my integration of extra
subsystems for the mx28evk board, or should I wait until your work on
mx28evk_config is in the mainline?
By the way, I have the stranges issue with both your mx28evk_config,
Marek's m28evk_config and my combined
Hi Stephan,
> Of course you can post patches ! Any fix is always high appreciated !
I figured patches on a different repo were a bit 'unusual', but I'll clean up
my work and
submit my patch soon.
> Exactly which kernel version ? Do you tried with mainline kernel ? The
> board is officially supp
Hi Matthias,
> I a patch would be welcome. I only need USB and SPI flash for my
> application. And USB was easy to setup. Currently I am also jiggling
> around the SPI / SPI flash support.
For USB, all you need to do is to configure it in and to copy Marek's clock
setup in board_early_init_f for
> Looks like CPUfreq+usb is doing something eerie ... Fabio, can you look into
> it?
I've Kernel 3.2.1 and it works. So I've made a clean-built of my 3.1.6 and works
too. No idea why it failed before, but I'm going to disregard that for now. I
think
it's safe to conclude that the problem is an i
>> I've Kernel 3.2.1 and it works. So I've made a clean-built of my 3.1.6 and
>> works
>> too. No idea why it failed before, but I'm going to disregard that for now.
>> I think
>> it's safe to conclude that the problem is an incompatibility between the
>> FreeScale supplied 2.6.35.3-571 Kernel an
> About the 2.6.35 cpufreq bug you see: I remember to see a patch for
> it. Let me locate it and I will point it to you.
If there's anything you can remember, please throw it at me: Anything
is useful.
> Or simply try to disable cpufreq if you need a quick workaround for 2.6.35.
I'll try that ne
Hi Fabio,
> Could you please post a patch with your proposed change so that we can test
> it?
I was hoping for a suggestion from you, as you know this SoC far better than me.
Currently I am trying different solutions. Even though they prevent the system
from
hanging up, they still don't enable
> From your previous email, it looked like that was proper solution. You can
> still
> send a patch so we can test and proceed further in sync.
I will send it in, as soon as I have a solution that enables instruction
stepping through
this code.
> What do you mean?
If my 'solution' doesn't enab
> Robert ... do you really want to cooperate and help fix stuff mainline or do
> you
> want to keep everyone in blind, make them guess/help you and when you fix
> something, never come back and have the fix only for yourself?
Well, given my very verbose thread start, including oscillographs, it i
>> My 'fix' as it is now, doesn't fix any real problem. It's not finished yet.
>> As it looks now, it makes the JTAG connection unreliable. Data is getting
>> corrupted when it's read or written. However, the system no longer hangs
>> up itself.
>
> That IS a progress.
Progress is made, but no co
>> When I swap power_init and mem_init though, the board boots fine, othervise
>> it
>> hangs.
>
> Ok, so looks like this is not compiler related issue then.
I will try this too. I've noticed that mem_init also touched PLL bypass, etc.
I'm starting to wonder if we need to touch PLL bypass in po
Hi Fabio,
>>> Could you please post a patch with your proposed change so that we can test
>>> it?
Still working on it. Got delayed by an incompatibility between the SoC and an
SD-Card
controller. I'm the only software developer currently on this project, so I
swich
back-and-forth all the time.
LL configuration.
Cheers,
Robert.
From: Fabio Estevam [feste...@gmail.com]
Sent: 31 January 2012 13:26
To: Marek Vasut
Cc: u-boot@lists.denx.de; Wolfgang Denk; Detlev Zundel; Stefano Babic; Robert
Deliën; Matthias Fuchs
Subject: Re: [PATCH] i.MX28: Fix VDDIO a
> Right, because RAM size is 0. I see, so DRAM init fails somewhere.
That's exactly where and why it hangs, in my case.
> I think
> though it doesn't hang in the POWER init code anymore.
In my case, I don't think it hung in power_init before your patch. I'm pretty
sure it
hung at the same place
> Ok, what happens if you replace mx28_dram_init() with:
>
> while (!readl(0x8001c280))
> mx28_mem_init();
I'm sorry for my late response; I was attending an FPGA workshop today. I will
test this first thing in the morning, when I'm at the office.
___
Hi Marek,
> Ok, what happens if you replace mx28_dram_init() with:
>
> while (!readl(0x8001c280))
>mx28_mem_init();
It's not entirely clear what you'd like me to try: mx28_dram_init
is called in U-Boot, while mx28_mem_init is SPL code.
I have tried to link SPL objects along, but I'm gett
> > 2. Please grep the locations where hw_clkctrl_frac0 is assigned as
> > 32-bit and change those as well.
>
> Please do the same for hw_clkctrl_frac1 as well. There is one location
> in clock.c where it is read as 32-bit.
I will check all hw_clkctrl_frac* register access, but tomorrow because
t
Hi Fabio,
> Very good, Robert! I tested your patch and it fixes the reboot issue
> on my mx28evk.
You're most welcome! I'm glad to hear it fixes your problem too.
> Also checked in the MX28 Reference Manual about the fact that
> hw_clkctrl_frac0 can only be accessed as bytes.
It's easy to overl
> You can write:
> writeb(19 , &clkctrl_regs->hw_clkctrl_frac0);
Yes, for the first byte I can (and do), but the three higher bytes
would get ugly with this method:
writeb(bitset >> 8, (unit8_t*)&clkctrl_regs->hw_clkctrl_frac0 + 1);
___
U-Boot mailing li
Hi,
> you're only writing data to the register, not clearing them. So maybe some
> bits
> remain set?
The assignment will work here. There're only 8 bits, of which 6 are the
fractional
divider, one is de read-only stable indicator (unaffected by writes) and the
last
one is the gating bit.
The
Hi,
> this is how the imx-bootlets does it though. It's likely that FSL wants the
> PLL0
> to run from XTAL when doing power configuration?
I was using the FLS bootlets as a reference too, but I have noticed a number of
'mistakes' in that code. For example:
- Busy-indicators aren't considered wh
Hi,
> I was thinking of this and we might need to introduce either special accessor
> for this particular register or rework include/regs-common.h and introduce
> mx28_reg_8 (which I don't think is a good idea).
I tend to agree with you about introducing mx28_reg_8. It doesn't 'feel right'
becaus
> Awesome. So after reading your replies, let's just rename mx28_reg to
> mx28_reg_32 and introduce mx28_reg_8 for this particular problem.
You were probably already foreseeing this when you made your
suggestion to use accessors, but now I'm working it I see introducing
mx28_reg_8 may get too mess
> Make it an array?
If that works for you, it works for me. Thanks!
#define __mx28_reg_8(name) \
uint8_t name##[4]; \
uint8_t name##[4]_set; \
uint8_t name##[4]_clr; \
uint8_t name##[4]_tog;
__
Hi Marek,
> - if (io == MXC_IOCLK0) {
> - writel(CLKCTRL_FRAC0_CLKGATEIO0,
> - &clkctrl_regs->hw_clkctrl_frac0_set);
> - clrsetbits_le32(&clkctrl_regs->hw_clkctrl_frac0,
> - CLKCTRL_FRAC0_IO0FRAC_MASK,
> -
> btw 2/2 is missing?
Not missing, just not sent again; It hasn't been changed.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi,
> That's why I put the ternary operator there ?
Ah; without anything behind it, it really just looked like a question mark.
But using a ternary caters only for a set of two. So enumeration would
be better ideed.
> It's impossible to review like this though and much more prone to pull in
> b
> btw. a quick hint:
>
> git reset HEAD^
> git add -p
>
> Add only the reg32 changes, commit, add the rest, commit. Send ;-)
Well, I made it a little more work than that. But who would have
thought? GIT is actually growing on me!
I've got my changes in my repository now, in 4 separate commits.
> > + uint32_thw_digctl_writeonce;/* 0x060 */
> > + uint32_treserved_writeonce[3];
>
> Just mark all this crap as "reserved" and be done with it.
If that's good enought, that will save me some work next time.
> > + uint32_thw_digctl_dbg;
> Bit definitions for these registers are missing. I have a crappy script that
> converts original FSL files into u-boot variant (though it needs some handjob
> still).
Bring it on, and I'll see if I can do it. No, this is not implying I'm good at
hand-
jobs.
But please accept my patch in the mea
> Robert, I tested first three patches on my board and it refuses to boot. Why?
I'm trying to reproduce, but my workspace no longer builds after a pull... The
set
obviously works in my own workspace, so I'm trying to figure out the problem.
___
U-Boot m
> Robert, I tested first three patches on my board and it refuses to boot. Why?
I can reproduce now. It all goes south after patch 3. I'm working on it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
> Did you even test before submitting? Also, I think if I remove patch 3, it all
> works fine.
Naturally, I did. Yet on my own SVN controlled workspace, because my
GIT workspace of the mainline didn't build yesterday.
I'm looking at the differences now, and there aren't any concerning i.mx28.
But
> "The switch of CPU clock is to make our EVK board can boot up the
> uboot and kernel with less than 100mA power consumption to meet the
> USB specification
That's actually a very good point. For that scenario we may even consider
to use the SoC's internal 24MHz ring oscillator instead of the cry
> And by running off XTAL, the consumption grows so dramatically?
No, switching on the PLL does.
And the PLL can use either the external XTAL or the internal ring-
oscillator as a reference. The external XTAL is very accurate, but
uses power. The ring-oscillator is not very accurate, but very
ene
> That is because not only CPU running @ PLL, HBUS also source from P_CLK, we
> switch
> CPU clock to XTAL, the HBUS clock also slow down.
You're right, but I'm not switching back to XTAL. I'm just postponing the
switch to PLL. Not
in the last reason because the first switch to PLL is incorrect
> Ok, but you switch it back to PLL after the power supply was configured. And
> then the consumption grows back.
Yes, power_init switches to PLL (yet incorrectly). And memory_init switches back
to XTAL when configuring hbus for a brief moment, to switch to PLL after hbus
is configured. My proposa
> 1. Switch P_CLK to XTAL;
> 2. Check power source, if there is battery available, we switch back to PLL
> and make CPU running @ full
> speed, and power is sourced from battery;
> 3. If battery is not available, and the power supply is from USB host, then
> we let CPU running @ XTAL
> until boo
> Do you plan to post a patch to enable NAND on the EVK as well?
Yes, I do. It's all tested and working in my workspace. But the first
samples of our own board have arrived a couple of days ago and I'm
currently in the process of bringing it up and that has priority over
everything else, hence the
> So I can lean back ...
I can even send you a patch of what I have, if that helps you out...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
> Robert, I tested first three patches on my board and it refuses to boot. Why?
The problem is in here:
io_reg = MXC_IOCLK1 - io; /* Register order is reversed */
I will rework and resubmit the patches 'soon'. I'm a bit numb of reworking and
resubmitting and I just received a board to bringup la
Hi Marek,
> git rebase -i HEAD~3
> (if you have the patch you want to rework 3 patches deep)
> Change "pick" to the left of the patch to "edit"
> Do the change in the file.
> git add
> git rebase --continue
>
May be tonight, at my hotel room.
> Lowering the clock to what ?
Down to 137MHz work
Is this patch approved?
From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on behalf of
Robert Deliën [rob...@delien.nl]
Sent: 07 February 2012 10:15
To: Marek Vasut
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] Elimintated magic
> Why did you repost?
I reposted with your ack in 1 to 3. Still they don't seem to show up in
the mailing list.
> Fix that "domain.unknown"
I can't. It's Agilent's smpt server's way to tell it's not happy with
relaying messages from my email address.
_
> Sure you can ...
>
> $ cat .gitconfig
> [user]
> name = Us Er
> email = u...@ma.il
>
> Done
Thanks of the hint, but I configured that some time ago already (in
~/.gitconfig).
Git even confirms:
$ git config -l
user.name=Rxbert Dxlien
user.email=rxb...@dxlien.nl
color.diff=auto
> Never do this. ACKs and such are tracked in patchwork.
It's a hard to satsify everybody. I added the ack and and test
per Marek's request, and reposted.
> And _if_ you repost, then play by the rules and add a changelog.
>Then use a better relay. Please fix it, it is a PITA not being able
> t
> This is labeled as patch v5 - but I cannot see any log of what has
> been changed compared to previous versions, i. e. which review
> comments have been applied and which ignored.
I did the curtesy of re-forming patch set v5 from a freshly pulled
repository, because they no longer applied withou
> Do you plan to post a patch to enable NAND on the EVK as well?
No, I'm afraid not anymore.
> That shouldn't be a big deal.
The patch isn't, but getting it accepted is.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo
This patch fixes a small off-by-one bug in the GPIO driver for the mxs platform
that allowed the selection gpio pins of one bank more than the SoC actually has.
Signed-off-by: Robert Deliën
diff --git a/drivers/gpio/mxs_gpio.c b/drivers/gpio/mxs_gpio.c
index b7e9591..539738b 100644
--- a
This patch fixes a small bug that allowed unintended manipulation of
non-existing GPIO pins within a pin bank, clobbering reserved bits.
Signed-off-by: Robert Deliën
diff --git a/arch/arm/include/asm/arch-mx28/iomux.h
b/arch/arm/include/asm/arch-mx28/iomux.h
index 7abdf58..829d9a8 100644
--- a
convention to address pin
number 5 in bank 3 is b3p5. But names like B0003p005 are interpreted
correctly too.
Signed-off-by: Robert Deliën
diff --git a/arch/arm/include/asm/arch-mx28/gpio.h
b/arch/arm/include/asm/arch-mx28/gpio.h
index be1c944..5ae66e6 100644
--- a/arch/arm/include/asm
> To make things simple for users, there's standard layout. It's actually at
> sector 2048 btw.
Got that.
> That's what happens internally, it's just that some pieces (like sector
> offset
> of the partition!) need to be filled into the bootstream header by the
> mxsboot
> utility -- see mxs
> No, move this to mxs_gpio.c and simply make the function not static.
I too find the construction a little strange, but I copied it from the Blackfin
implementation.
But after taking a second look at it, it made sense: It makes the file pulling
including it, define it statically locally. The m
> Careful here !!
>
> The driver _should_ work for MX233 too! What I'd like to see is you
> introducing
> a function like:
>
> int mxs_gpio_is_valid(gpio)
> {
> char mxs_banks[PINCTRL_BANKS] = PINCTRL_BANK_COUNTS;
>
> if (PAD_PIN(gpio) > mxs_bank[PAD_BANK(gpio)])
> return -EINVAL;
>
> r
> I don't think I follow ... don't you only have to define the function and
> that's
> it?
No, it's a bit more complicated than that. It wouldn't be my choice either, but
now I'm familiar with it, I find it quite charming. Let me see if I can explain:
Check out common/cmd_gpio.c.
The first par
> static const int all_bank_pins[] = {
> MXS_BANK0_PINS,
> MXS_BANK1_PINS,
> MXS_BANK2_PINS,
> MXS_BANK3_PINS,
> MXS_BANK4_PINS,
> };
> bank_pins = all_bank_pins[PAD_PANK(gp)];
Good one!
But how about the changes Marek suggested about name_to_gpio_number?
Robert.
__
+ if (name[0] >= '0' && name[0] <= '9') {
+ pin_nr = simple_strtoul(name, (char **)&name, 10);
+ if (name[0])
+ return -EINVAL;
Why do we need this check ? We have already copied / converted the
number in pin_nr, we do not need to check in th
> Man, this is really ... urgh. But fine, it's better than it was anyway.
I'm getting the impression that the "better than it was"-standard isn't applied
consistently.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-
> Careful here !!
>
> The driver _should_ work for MX233 too! What I'd like to see is you
> introducing
> a function like:
>
> int mxs_gpio_is_valid(gpio)
> {
> char mxs_banks[PINCTRL_BANKS] = PINCTRL_BANK_COUNTS;
>
> if (PAD_PIN(gpio) > mxs_bank[PAD_BANK(gpio)])
> return -EINVAL;
>
> return
And are you sure the amound of pins in bank 0, 1, 2 is the same on mx233 and
mx28 ?
Yes, I'm sure they're not ;-). I went through the manual and changed it into
this:
static const int mxs_bank_pins[] = {
#ifdefined(CONFIG_MX23)
MX23_BANK0_PINS,
MX23_BANK1_PINS,
MX23_BANK2_PINS
#elifdefine
check in gpio_request was incomplete anyway.
2. MX233 is not supported yet. Until it is, macros defining the number of pins
for each bank reside in arch/arm/include/asm/arch-mx28/iomux.h
Signed-off-by: Robert Deliën
diff --git a/arch/arm/include/asm/arch-mx28/gpio.h
b/arch/arm/include/asm/arch
translated name doesn't
automatically produce a valid pin. It only means the bank/pin numbers fit the
designated bitfields. After successful translation, validity needs to be
checked separately.
Signed-off-by: Robert Deliën
diff --git a/arch/arm/include/asm/arch-mx28/gpio.h
b/arch/arm/includ
check in gpio_request was incomplete anyway.
2. MX233 is not supported yet. Until it is, macros defining the number of pins
for each bank reside in arch/arm/include/asm/arch-mx28/iomux.h
Signed-off-by: Robert Deliën http://delien.nl/>>
diff --git a/arch/arm/include/asm/arch-mx28/gpio.h
> On Wednesday 23 November 2011 10:08:58 Robert Deliën wrote:
>> 1. gpio_request no longer checks validity. Pin validity must be checked
>> explicitly use gpio_invalid prior to request and hence use.
>
> NAK. the u-boot gpio API follows the Linux API which means gpio_request
>> +
>> +if (name[0])
>> +return (-EINVAL);
>
> Why the parenthesis ?
Because you asked for them… But OK, I'll remove them again...
>> +
>> +return ( ((bank << MXS_PAD_BANK_SHIFT) & MXS_PAD_BANK_MASK) |
>> + ((pin << MXS_PAD_PIN_SHIFT ) & MXS_PAD_PIN_MASK ) );
>>
check in gpio_request was incomplete anyway.
2. MX233 is not supported yet. Until it is, macros defining the number of pins
for each bank reside in arch/arm/include/asm/arch-mx28/iomux.h
Signed-off-by: Robert Deliën http://delien.nl/>>
diff --git a/arch/arm/include/asm/arch-mx28/gpio.h
name doesn't
automatically produce a valid pin. It only means the bank/pin numbers fit the
designated bitfields. After successful translation, validity needs to be
checked separately.
Signed-off-by: Robert Deliën
diff --git a/arch/arm/include/asm/arch-mx28/gpio.h
b/arch/arm/include/asm
> I asked you to add braces around the else part of the branch!
> if { ... } else { ... } ... this stuff. Sorry for the confusion!
Ah; That makes sense now. No worries.
> I think I didn't see the pin validity patch then.
Hm, perhaps I neglected to CC you...
__
>> +#define MX28_BANK0_PINS 29
>> +#define MX28_BANK1_PINS 32
>> +#define MX28_BANK2_PINS 28
>> +#define MX28_BANK3_PINS 31
>> +#define MX28_BANK4_PINS 21
>> +
>> +#define MX23_BANK0_PINS 32
>> +#define MX23_BANK1_PINS
;> bank reside in arch/arm/include/asm/arch-mx28/iomux.h
>>
>> Signed-off-by: Robert Deliën http://delien.nl/>>
>
> AARGH! Please add the following lines to the commit message:
>
> Cc: Marek Vasut
> Cc: Stefano Babic
>
>
>
> That way, you won'
> sorry if my messages have been a bit harsh with gpio freedback. the
> unwrapped
> lines and broken patch formats make me see red.
I understand; There are rules to adhere to.
But please also understand what I'm working with here. Making a single patch
takes me - I kid you not - one hour. And
Hi Wolfgang,
How nice of you to drop a message, I really appreciate it.
> Part of this problem might be the result from an attitude of "I don't
> have the time to learn doing thisngs right, but I always have time to
> repeat them wrongly again and again".
In the end, doing things right always pa
Hi Wolfgang,
> What do you mean? Which message do you claim I have omitted? And
> where?
Oh, no, I'm sorry; That's not how I meant it. I didn't mean 'drop' as in 'omit',
but as in 'passing'.
> 3 hours? Hm... I think it should be possible to read enough git
> documents and tutorials in one hou
81 matches
Mail list logo
