Re: [PATCH] drivers: xen: events: fix build issues with disabled Xen HVC
On 02.08.22 22:11, Tom Rini wrote: > On Tue, Aug 02, 2022 at 06:49:49PM +0000, Dmytro Firsov wrote: > >> It received reviewed-by from code maintainer. Does anything else needed >> to take it to u-boot/master? > Ah. I'll probably pick it up soon. > Thanks!
Re: [PATCH] drivers: xen: events: fix build issues with disabled Xen HVC
It received reviewed-by from code maintainer. Does anything else needed
to take it to u-boot/master?
On 02.08.22 13:57, Tom Rini wrote:
> On Tue, Aug 02, 2022 at 08:48:51AM +0000, Dmytro Firsov wrote:
>
>> Can moderators, please, take a look on this patch?
> What about it?
>
> https://patchwork.ozlabs.org/project/uboot/patch/20220704120533.42168-1-dmytro_fir...@epam.com/
>> On 20.07.22 23:43, Nastya Vicodin wrote:
>> Reviewed-by: Anastasiia Lukianenko
>> mailto:vicooo...@gmail.com>>
>>
>> On Mon, Jul 4, 2022 at 3:05 PM Dmytro Firsov
>> mailto:dmytro_fir...@epam.com>> wrote:
>> Some setups do not use Xen hypervisor console for logging, e.g. they
>> use emulated PL011 hardware or shared peripherals (real UART). In such
>> cases Xen HVC will be disabled on a build time and will cause issues in
>> current driver implementation.
>>
>> This commit fixes build issues in Xen event channel driver, caused
>> by absense of console event channel, that is not available when console
>> config is disabled. Now console related code will be removed when
>> Xen HVC is turned off.
>>
>> Signed-off-by: Dmytro Firsov
>> mailto:dmytro_fir...@epam.com>>
>> ---
>> drivers/xen/events.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
>> index 5e90a65846..532216fece 100644
>> --- a/drivers/xen/events.c
>> +++ b/drivers/xen/events.c
>> @@ -23,7 +23,9 @@
>> #include
>> #include
>>
>> +#if CONFIG_IS_ENABLED(XEN_SERIAL)
>> extern u32 console_evtchn;
>> +#endif /* CONFIG_IS_ENABLED(XEN_SERIAL) */
>>
>> #define NR_EVS 1024
>>
>> @@ -51,8 +53,11 @@ void unbind_all_ports(void)
>> struct vcpu_info *vcpu_info = >vcpu_info[cpu];
>>
>> for (i = 0; i < NR_EVS; i++) {
>> +#if CONFIG_IS_ENABLED(XEN_SERIAL)
>> if (i == console_evtchn)
>> continue;
>> +#endif /* CONFIG_IS_ENABLED(XEN_SERIAL) */
>> +
>> if (test_and_clear_bit(i, bound_ports)) {
>> printf("port %d still bound!\n", i);
>> unbind_evtchn(i);
>> --
>> 2.25.1
Re: [PATCH v2] drivers: xen: unmap Enlighten page before jumping to Linux
On 21.07.22 18:11, Oleksandr wrote: > > On 19.07.22 17:55, Dmytro Firsov wrote: > > Hello Dmytro > > > First of all, thanks for fixing this issue. > > Patch looks good, just a nit below. > Hello Oleksandr, >> + reservation.domid = DOMID_SELF; >> + reservation.extent_order = 0; >> + reservation.address_bits = 0; > > I think the explicit field's zeroing could be dropped now. > > Per my understanding, both of this zeros matters, so I decided to set them explicitly (even with struct zeroing): - for `extent_order` - zero means "no additional shift for PFN_SHIFT", so we are using 4K pages; - for `address_bits` - zero means "the user has no addressing restriction". Best regards, Dmytro.
[PATCH v2] drivers: xen: unmap Enlighten page before jumping to Linux
This commit fixes issue with usage of Xen hypervisor shared info page.
Previously U-boot did not unmap it at the end of OS boot process. Xen
did not prevent guest from this. So, it worked, but caused wierd
issues - one memory page, that was returned by memalign in U-boot
for Enlighten mapping was not unmaped by Xen (shared_info values was
not removed from there) and returned to allocator. During the Linux
boot, it uses shared_info page as regular RAM page, which leads to
hypervisor shared info corruption.
So, to fix this issue, as discussed on the xen-devel mailing list, the
code should:
1) Unmap the page
2) Populate the area with memory using XENMEM_populate_physmap
This patch adds page unmapping via XENMEM_remove_from_physmap, fills
hole in address space where page was mapped via XENMEM_populate_physmap
and return this address to memory allocator for freeing.
Signed-off-by: Dmytro Firsov
---
Changes in v2:
- Reword commit message to be more clear with purpose of the patch
- Change BUG() helper to panic() and add error messages
- Add struct zeroing during initialization
- Fix typo in comment
---
drivers/xen/hypervisor.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/xen/hypervisor.c b/drivers/xen/hypervisor.c
index 2560894832..16c7c96c94 100644
--- a/drivers/xen/hypervisor.c
+++ b/drivers/xen/hypervisor.c
@@ -144,6 +144,36 @@ struct shared_info *map_shared_info(void *p)
return HYPERVISOR_shared_info;
}
+void unmap_shared_info(void)
+{
+ xen_pfn_t shared_info_pfn = virt_to_pfn(HYPERVISOR_shared_info);
+ struct xen_remove_from_physmap xrfp = {0};
+ struct xen_memory_reservation reservation = {0};
+ xen_ulong_t nr_exts = 1;
+
+ xrfp.domid = DOMID_SELF;
+ xrfp.gpfn = shared_info_pfn;
+ if (HYPERVISOR_memory_op(XENMEM_remove_from_physmap, ) != 0)
+ panic("Failed to unmap HYPERVISOR_shared_info\n");
+
+ /*
+* After removing from physmap there will be a hole in address space on
+* HYPERVISOR_shared_info address, so to free memory allocated with
+* memalign and prevent exceptions during access to this page we need to
+* fill this 4KB hole with XENMEM_populate_physmap before jumping to
Linux.
+*/
+ reservation.domid = DOMID_SELF;
+ reservation.extent_order = 0;
+ reservation.address_bits = 0;
+ set_xen_guest_handle(reservation.extent_start, _info_pfn);
+ reservation.nr_extents = nr_exts;
+ if (HYPERVISOR_memory_op(XENMEM_populate_physmap, ) !=
nr_exts)
+ panic("Failed to populate memory on HYPERVISOR_shared_info
addr\n");
+
+ /* Now we can return this to memory allocator */
+ free(HYPERVISOR_shared_info);
+}
+
void do_hypervisor_callback(struct pt_regs *regs)
{
unsigned long l1, l2, l1i, l2i;
@@ -251,4 +281,5 @@ void xen_fini(void)
fini_gnttab();
fini_xenbus();
fini_events();
+ unmap_shared_info();
}
--
2.25.1
Re: [PATCH] drivers: xen: unmap Enlighten page before jumping to Linux
On 19.07.22 14:04, Julien Grall wrote: > Hi, > > On 19/07/2022 11:45, Dmytro Firsov wrote: >> >> On 19.07.22 12:50, Julien Grall wrote: >>> Hi Dmytro, >>> >>> On 19/07/2022 09:52, Dmytro Firsov wrote: >>>> This commit fixes issue with usage of Xen hypervisor shared info page. >>>> Previously U-boot did not unmap it at the end of OS boot process. It >>>> leads to repeated mapping during Enlighten initialization in Linux. >>>> Xen did not prevent guest from this, so it works but causes weird >>>> wierd issues - one memory page, that was returned by memalign in >>>> U-boot >>>> for Enlighten mapping was not returned to allocator and contained >>>> shared info values during Linux run. >>> >>> I can't quite parse this. Do you mean the page will be marked as >>> reserved for Linux and therefore it will never reach Linux's page >>> allocator? >>> >> No, U-boot memory allocator uses real RAM pages and one of them will be >> used for shared_info. Previously U-boot did not unmap it when jumped to >> Linux. So, during Linux run, one of the pages that is marked as RAM in >> device-tree will contain shared_info values. I don't know how it worked >> previously, but it definitely will cause weird issue when Linux will try >> to use it as regular RAM page. > > Ok. I would suggest to reword the commit message. > >> >> >>>> Also Linux mapped it to another >>>> place in memory again. > >>>> Now code, that restricts repeated mapping of Enlighten page, is about >>>> to be merged to Xen: >>>> https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20220716145658.4175730-2-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!2OWttkgakR7s6GUn6e60EweRQ44H-TyI-8wWzhX0vWzR33BJE_z-x_AZ0S5VBBnXwwQ73-eIQ-sNcGLf$ >>>> >>>> >>>> [lore[.]kernel[.]org] >>>> >>>> So, without unmapping in U-boot, Linux will fail to start. >>> >>> Hmmm... From a discussion with Oleksandr, I was under the impression >>> that this patch would also be necessary without the Xen patch merged. >>> This was in order to prevent a corruption of the shared page [1]. >>> >> Yes, definitely, but with new patches this problem becomes critical > > I would argue that it was more critical before because you would end > up with some random corruption of the shared page. At least, Oleksandr > patch bring up some certainty because now Linux can't boot. > >> and >> it will block Linux boot. General problem is explained in previous >> section. This patch is needed to U-boot even without new patches to Xen, >> but problem became visible only after them. > See above, I think the commit message should focus on the corruption > rather than Xen forbidding double map. So it is clear that this patch > is not to paper over a new issue in Xen (which would technically be a > regression) but fixing a *real* problem on any Xen version. Okay, I argee. I will reword commit message with focus on corruption. > >> >> >>>> As discussed >>>> on the xen-devel mailing list, to fix this issue the code should: >>>> 1) Unmap the page >>>> 2) Populate the area with memory using XENMEM_populate_physmap >>>> >>>> This patch adds page unmapping via XENMEM_remove_from_physmap, fills >>>> hole in address space where page was mapped via >>>> XENMEM_populate_physmap >>>> and return this address to memory allocator for freeing. >>> >>> Is U-boot mapping other shared page from Xen (e.g. grant-table...)? >> >> Yes, but only shared_info is mapped with XENMEM_add_to_physmap, so other >> drivers are not affected. > > H... A grep in u-boot source shows that XENMEM_add_to_physmap is > used to map grant-table frame. However, the driver seems to use the > unallocated address space provided by Xen. So you are fine there. Yes, grant-tables are mapped outside of actual RAM, so there is no such problem. > > >>> >>>> + struct xen_remove_from_physmap xrfp; >>>> + struct xen_memory_reservation reservation; >>> >>> AFAICT, there some paddings in the two structure. So I would suggest >>> to zero the structure (including paddings). >> >> I did not see any padding in these structs definition in U-boot, so all >> fields are initialized. > > There are no explicit padding but there are some implicit one. If you > use pahole, you will see: > > struct xen_remove_
Re: [PATCH] drivers: xen: unmap Enlighten page before jumping to Linux
On 19.07.22 12:50, Julien Grall wrote:
> Hi Dmytro,
>
> On 19/07/2022 09:52, Dmytro Firsov wrote:
>> This commit fixes issue with usage of Xen hypervisor shared info page.
>> Previously U-boot did not unmap it at the end of OS boot process. It
>> leads to repeated mapping during Enlighten initialization in Linux.
>> Xen did not prevent guest from this, so it works but causes weird
>> wierd issues - one memory page, that was returned by memalign in U-boot
>> for Enlighten mapping was not returned to allocator and contained
>> shared info values during Linux run.
>
> I can't quite parse this. Do you mean the page will be marked as
> reserved for Linux and therefore it will never reach Linux's page
> allocator?
>
No, U-boot memory allocator uses real RAM pages and one of them will be
used for shared_info. Previously U-boot did not unmap it when jumped to
Linux. So, during Linux run, one of the pages that is marked as RAM in
device-tree will contain shared_info values. I don't know how it worked
previously, but it definitely will cause weird issue when Linux will try
to use it as regular RAM page.
>> Also Linux mapped it to another
>> place in memory again. >
>> Now code, that restricts repeated mapping of Enlighten page, is about
>> to be merged to Xen:
>> https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20220716145658.4175730-2-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!2OWttkgakR7s6GUn6e60EweRQ44H-TyI-8wWzhX0vWzR33BJE_z-x_AZ0S5VBBnXwwQ73-eIQ-sNcGLf$
>>
>> [lore[.]kernel[.]org]
>>
>> So, without unmapping in U-boot, Linux will fail to start.
>
> Hmmm... From a discussion with Oleksandr, I was under the impression
> that this patch would also be necessary without the Xen patch merged.
> This was in order to prevent a corruption of the shared page [1].
>
Yes, definitely, but with new patches this problem becomes critical and
it will block Linux boot. General problem is explained in previous
section. This patch is needed to U-boot even without new patches to Xen,
but problem became visible only after them.
>> As discussed
>> on the xen-devel mailing list, to fix this issue the code should:
>> 1) Unmap the page
>> 2) Populate the area with memory using XENMEM_populate_physmap
>>
>> This patch adds page unmapping via XENMEM_remove_from_physmap, fills
>> hole in address space where page was mapped via XENMEM_populate_physmap
>> and return this address to memory allocator for freeing.
>
> Is U-boot mapping other shared page from Xen (e.g. grant-table...)?
Yes, but only shared_info is mapped with XENMEM_add_to_physmap, so other
drivers are not affected.
>
>>
>> Signed-off-by: Dmytro Firsov
>> ---
>> drivers/xen/hypervisor.c | 31 +++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/xen/hypervisor.c b/drivers/xen/hypervisor.c
>> index 2560894832..9ac377b618 100644
>> --- a/drivers/xen/hypervisor.c
>> +++ b/drivers/xen/hypervisor.c
>> @@ -144,6 +144,36 @@ struct shared_info *map_shared_info(void *p)
>> return HYPERVISOR_shared_info;
>> }
>> +void unmap_shared_info(void)
>> +{
>> + xen_pfn_t shared_info_pfn = virt_to_pfn(HYPERVISOR_shared_info);
>
> Somewhat unrelated to this patch. Can U-boot be compiled with 16K/64K
> page granularity?
I am using it on Armv8 and U-boot have hardcoded PAGE_SHIFT==12, and
PAGE_SIZE==(1<
>> + struct xen_remove_from_physmap xrfp;
>> + struct xen_memory_reservation reservation;
>
> AFAICT, there some paddings in the two structure. So I would suggest
> to zero the structure (including paddings).
I did not see any padding in these structs definition in U-boot, so all
fields are initialized. But I can add zeroing with memset in next
version to be sure in this if structures will change.
>
>> + xen_ulong_t nr_exts = 1;
>> +
>> + xrfp.domid = DOMID_SELF;
>> + xrfp.gpfn = shared_info_pfn;
>> + if (HYPERVISOR_memory_op(XENMEM_remove_from_physmap, ) != 0)
>> + BUG();
>
> If I am not mistaken, U-boot provide a panic() helper. So I would
> suggest to use it as this would be useful to print with the error
> returned.
Agree, will be fixed in next version.
>
>> +
>> + /*
>> + * After remove from physmap there will be a hole in address
>> space on
>
> Typo: s/remove/removing/
Agree, will be fixed in next version.
>
>> + * HYPERVISOR_shared_info address, so to free memory allocated with
>> + * memalign and prevent exceptions during access to this page we
>> need to
>> + * fill this 4KB hole with XENMEM_popul
[PATCH] drivers: xen: unmap Enlighten page before jumping to Linux
This commit fixes issue with usage of Xen hypervisor shared info page.
Previously U-boot did not unmap it at the end of OS boot process. It
leads to repeated mapping during Enlighten initialization in Linux.
Xen did not prevent guest from this, so it works but causes weird
wierd issues - one memory page, that was returned by memalign in U-boot
for Enlighten mapping was not returned to allocator and contained
shared info values during Linux run. Also Linux mapped it to another
place in memory again.
Now code, that restricts repeated mapping of Enlighten page, is about
to be merged to Xen:
https://lore.kernel.org/xen-devel/20220716145658.4175730-2-olekst...@gmail.com/
So, without unmapping in U-boot, Linux will fail to start. As discussed
on the xen-devel mailing list, to fix this issue the code should:
1) Unmap the page
2) Populate the area with memory using XENMEM_populate_physmap
This patch adds page unmapping via XENMEM_remove_from_physmap, fills
hole in address space where page was mapped via XENMEM_populate_physmap
and return this address to memory allocator for freeing.
Signed-off-by: Dmytro Firsov
---
drivers/xen/hypervisor.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/xen/hypervisor.c b/drivers/xen/hypervisor.c
index 2560894832..9ac377b618 100644
--- a/drivers/xen/hypervisor.c
+++ b/drivers/xen/hypervisor.c
@@ -144,6 +144,36 @@ struct shared_info *map_shared_info(void *p)
return HYPERVISOR_shared_info;
}
+void unmap_shared_info(void)
+{
+ xen_pfn_t shared_info_pfn = virt_to_pfn(HYPERVISOR_shared_info);
+ struct xen_remove_from_physmap xrfp;
+ struct xen_memory_reservation reservation;
+ xen_ulong_t nr_exts = 1;
+
+ xrfp.domid = DOMID_SELF;
+ xrfp.gpfn = shared_info_pfn;
+ if (HYPERVISOR_memory_op(XENMEM_remove_from_physmap, ) != 0)
+ BUG();
+
+ /*
+* After remove from physmap there will be a hole in address space on
+* HYPERVISOR_shared_info address, so to free memory allocated with
+* memalign and prevent exceptions during access to this page we need to
+* fill this 4KB hole with XENMEM_populate_physmap before jumping to
Linux.
+*/
+ reservation.domid = DOMID_SELF;
+ reservation.extent_order = 0;
+ reservation.address_bits = 0;
+ set_xen_guest_handle(reservation.extent_start, _info_pfn);
+ reservation.nr_extents = nr_exts;
+ if (HYPERVISOR_memory_op(XENMEM_populate_physmap, ) !=
nr_exts)
+ BUG();
+
+ /* Now we can return this to memory allocator */
+ free(HYPERVISOR_shared_info);
+}
+
void do_hypervisor_callback(struct pt_regs *regs)
{
unsigned long l1, l2, l1i, l2i;
@@ -251,4 +281,5 @@ void xen_fini(void)
fini_gnttab();
fini_xenbus();
fini_events();
+ unmap_shared_info();
}
--
2.25.1
[PATCH] drivers: xen: events: fix build issues with disabled Xen HVC
Some setups do not use Xen hypervisor console for logging, e.g. they
use emulated PL011 hardware or shared peripherals (real UART). In such
cases Xen HVC will be disabled on a build time and will cause issues in
current driver implementation.
This commit fixes build issues in Xen event channel driver, caused
by absense of console event channel, that is not available when console
config is disabled. Now console related code will be removed when
Xen HVC is turned off.
Signed-off-by: Dmytro Firsov
---
drivers/xen/events.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 5e90a65846..532216fece 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -23,7 +23,9 @@
#include
#include
+#if CONFIG_IS_ENABLED(XEN_SERIAL)
extern u32 console_evtchn;
+#endif /* CONFIG_IS_ENABLED(XEN_SERIAL) */
#define NR_EVS 1024
@@ -51,8 +53,11 @@ void unbind_all_ports(void)
struct vcpu_info *vcpu_info = >vcpu_info[cpu];
for (i = 0; i < NR_EVS; i++) {
+#if CONFIG_IS_ENABLED(XEN_SERIAL)
if (i == console_evtchn)
continue;
+#endif /* CONFIG_IS_ENABLED(XEN_SERIAL) */
+
if (test_and_clear_bit(i, bound_ports)) {
printf("port %d still bound!\n", i);
unbind_evtchn(i);
--
2.25.1
Re: [U-Boot] Atheros ART data crc calculation
Hello, I'm glad that all was resolved! However, the two versions provided each has some issues, but together I was able to reload the device. The first revision was able to erase the FLASH correctly, and the ethernet initialized correctly, however, there was no cp command to copy from RAM to FLASH. The second revision had the cp instruction and could write to the FLASH (at least the upper area where the bootloader was stored), however, ethernet did not function, and it could not erase the FLASH correctly. I would like to recompile a fully working RAM loadable U-Boot incase problems arise the the future, but am not sure what you changed between the two versions, so if you could share that, I would be happy, or share how to change the ethernet type, FLASH type, etc. The main changes to load from the memory implemented in this patch: http://dioptimizer.narod.ru/files/ap96/path.diff When you have a problem with uboot command flinfo, this patch may fix this problem: http://dioptimizer.narod.ru/files/ap96/path2.diff GPL Used: http://www.tp-link.com/resources/GPL/mr3420_3220v1.tar.gz You can use any other GPL (but only with the support configuration ap96). For example, I use a specific GPL, since there is no need to compile a new version of toolchain. However, you should understand that the configuration of the flash memory is set in ap96/boot/u-boot/include/configs/ap96.h. And detect the size of flash memory on SPI is nowhere realized. The commands used in uboot console set in parameter: CONFIG_COMMANDS (( When using the RAM loader - need to disable all the commands that depend on the environment variables on flash. I do not know the full configuration of your device and do not have no possibility to experiment with the settings. Concerning the second bank of flash memory: Recently asked on the OpenWRT forum about the use of two chips of flash memory on the device with the processor AR7241. https://forum.openwrt.org/viewtopic.php?id=41019 http://svn.dd-wrt.com:8000/browser/src/linux/pb42/linux-2.6.34.6/drivers/mtd/devices/wzrag300nh_flash.h?rev=15106 On the same example need to patch ap96/boot/u-boot/board/ar7100/common/ar7100_flash.h P.S. And I would like to clarify about the bootloader on Compex devices: http://wiki.openwrt.org/doc/techref/bootloader/myloader#myloram There is need to load the bootloader in the memory at address 0x81F0 On my device (AR7241) bootloader is loaded, !!!but at boot time it erased firmware workspace on flash memory!!! and by the way, it correctly determined the flash memory size. Best regards, Dmytro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Atheros ART data crc calculation
Hello again Allan, Can you on work device (with correct ART section and with no checksum error), enter the u-boot command - printenv ? Also would you please share your ART section of the same device? Idea is this, it is necessary to calculate the checksum of ART section (only not clearly what part of the calculate, with empty sectors FF or workspace) in CRC32 format, then correct this checksum in buf_crc environment variable. https://forum.openwrt.org/viewtopic.php?pid=153580#p153580 Best regards, Dmytro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot for MIPS AR7161
Greetings In general that's the last variant http://dioptimizer.narod.ru/files/ap96/u-boot.bin (160 Kb) It is advisable to flash original bootloader, and only then something is seriously flash on the router. If something does not work, see the file: ap96/boot/u-boot/include/configs/ap96.h (here the main SETUP platform) How to compile the source code: 1. Extract the archive to the rights 2. Go to the folder ./build 3. Run make BOARD_TYPE=ap96 uboot After build, compiled variants of uoot's will be in: ./ap96/boot/u-boot/ (elf, bin, srec, etc. format) and ./images/ap96/ (only bin format) http://www.mediafire.com/?5rljo2y95dypd8z (109 Mb) P.S. Notify, wakes it work flinfo for the second bank of flash memory. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot for MIPS AR7161
Hello again Here I tried to create the bootloader. http://dioptimizer.narod.ru/files/ap96/u-boot.bin http://dioptimizer.narod.ru/files/ap96/u-boot.md5 For tftp: 192.168.1.1 -router ip 192.168.1.2 -must be your ethernet ip It must be loaded into memory at address: 0xa001 Then in OpenOCD (telnet) put: resume 0xa001 By the way you can check the boot on the work device, it's faster: tftpboot 0xa001 u-boot.bin go 0xa001 2012/12/1, Drassal, Allan dra...@wsu.edu: I think I made a little more progress... Using the following commands I can get output from the UART... # set GPIO 9 10 as UART mww 0xb804 0x400 mww 0xb8040028 0x100 mww 0xb8020004 0x0 mww 0xb802000c 0x83 mww 0xb802 0x51 mww 0xb8020004 0x0 mww 0xb802000c 0x3 mww 0xb8020008 0xc1 mww 0xb802 0x54 mww 0xb802 0x45 mww 0xb802 0x53 mww 0xb802 0x54 mww 0xb802 0x0D mww 0xb802 0x0A After executing the first two commands, then running the loader program I can get UART output, but it is all garbled. It is like I have not selected the correct BAUD, but I have tried all speeds. Possibly there is a mismatch in the internal clock calibration and the way the loader is calculating UART speeds. Is this the PLL configuration that I should be looking at? From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on behalf of Drassal, Allan [dra...@wsu.edu] Sent: Friday, November 30, 2012 20:14 To: Dmytro Cc: Luka Perkov; U-Boot Mailing List Subject: Re: [U-Boot] U-Boot for MIPS AR7161 Hi Dmytro, Thanks for your detailed response. I corrected some details in the ar71xx.cfg file and am posting them below this message. With this, I am convinced that my JTAG interface is working and the DRAM controller is getting setup correctly. Now, I am just needing some code to load into the processor. I would like to port U-Boot over to this platform, but it is a little above my experience level at the moment. Perhaps it has already been done and I am not looking in the right place. This platform is technically based on AP96 I believe though. I connected up the two devices today and did these checks, these are the results... However, the response from the two devices is slightly different... You can see the results below... I needed to do a reset init before the file would load successfully... I assume the DRAM controller is initialized at this point and not if I just open up openOCD. if I just did a straight halt without a reset init, then the PC is different On the non-functioning device I am assuming it begins to execute code at 0xbfc00380, but runs into something it can't execute and either loops or freezes there. reset JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part: 0x, ver: 0x0) halt target state: halted target halted in MIPS32 mode due to debug-request, pc: 0xbfc00380 results from broken device halt target state: halted target halted in MIPS32 mode due to debug-request, pc: 0xbfc00380 mdw 0xb800 0x10 0xb800: 77bc8cd0 81d106a8 0133 0002 2000 00ff 0081 0xb820: 0081 0081 0081 mdw 0xb805 0xb805: 001040a3 mdw 0xb8050008 0xb8050008: mdw 0xb805000c 0xb805000c: results from working device ar7100 md 0xb800 0x10 b800: 77b8884e 812cd6a8 0033 w..N.,.3 b810: 44a6 00ff 0007..D. b820: 0007 0007 0007 b830: ar7100 md 0xb805 0x1 b805: c0140180 ar7100 md 0xb8050008 0x1 b8050008: ar7100 md 0xb805000c 0x1 b805000c: ar7100 results of loading a file and checking the read memory is the same reset init JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part: 0x, ver: 0x0) target state: halted target halted in MIPS32 mode due to debug-request, pc: 0xbfc0 load_image mtd0.bin 0xa001 327680 bytes written at address 0xa001 downloaded 327680 bytes in 3.917356s (81.688 KiB/s) mdw 0xa001 0x10 0xa001: 10ff 10fd 1dbb 1db9 0xa0010020: 1db7 1db5 1db3 1db1 mdw 0xa001 0x10 0xa001: 10ff 10fd 1dbb 1db9 0xa0010020: 1db7 1db5 1db3 1db1 mdw 0xa001 0x10 0xa001: 10ff 10fd 1dbb 1db9 0xa0010020: 1db7 1db5 1db3 1db1 ar71xx.cfg: # Atheros AR71xx MIPS 24Kc SoC. # tested on PB44 refererence board adapter_nsrst_delay 100 jtag_ntrst_delay 100
Re: [U-Boot] U-Boot for MIPS AR7161
Hi Allan Drassal, Frankly, I'm not in practice faced ar71xx processors in labs, but I can give details on experience with the ar724x CPUs. First we need to determine are fully is support in ar71xx.cfg file for your device. You need connect to the JTAG and switch the device in halt mode. Next read the following registers using OpenOCD: mdw 0xb800 0x10 mdw 0xb805 mdw 0xb8050008 mdw 0xb805000c On the second device with a working firmware, do the same thing, only in u-boot (it's as though after the initialization of the CPU): md 0xb800 0x10 md 0xb805 0x1 md 0xb8050008 0x1 md 0xb805000c 0x1 What is it for? Before initializing the processor - PLL records are in resetting state These values are described in the files ar71xx.cfg or ar724x.cfg in parentheses. Then based on these (reset) values are any operation with PLL. I.e. We do not just give to known command to processor - We read from the processor value and produce a binary operation on it according to the rules described in the source lowlevel_init (if you take the PLL). The same thing with the any initialization process. Need will explain how to work with ar71xx.cfg configuration file. Event reset-halt-post thegas telnet command reset halt but this command directly related to the physical nSRST. I.e. During the execution of commands reset halt - nSRTS goes to logic 1 at the same time, this processor receives commands switch to halt. In my experience on ar724x CPUs - is no longer used nSRTS and has been replaced on RST so reset halt does not work in my case and the difficulty I had was that it was necessary to make sure that the processor is switched to the correct mode, and it was settings needed register (make sure you can read the mdw 0xb805 after the event is triggered and you will once again transferred CPU in halt mode.). As a last resort you can do ar71xx.cpu invoke-event reset-halt-post (if not work reset halt as it should) for example in the instructions: http://www.google.com/translate_c?langpair=ru|enu=http://wiki.openwrt.org/ru/toh/tp-link/tl-mr3420/debrick%2525using%2525jtag The next step will be a check memory: You need to load the image in the memory at 0xa001 load_image iamge.bin 0xa001 (Address window of DRAM memory at the platform AP96, PB42, etc. - 0xa001) and most importantly, it immediately check and compare with the original in HEX mode mdw 0xa001 0x10 mdw 0xa001 0x10 (check 2 times) This is due to the fact that If the specified is not correct timings for the memory then the first read memory may even be quite normal, but when we re-reading data, the data may already be offset (and eventually, the data starts, as if to float). Usually corrects this problem by selecting values in the less side DQS0, DQS1 line. Bootloader 8Muboot_RAM_version.bin course is not suitable for your purpose, you need to compile the bootloader for your platform and your address space (0xa001). So far the only thing I can say about it - I'm trying to solve this problem and will soon let you know the results. P.S. As variants, there are plenty of opportunities to find the right boot for your processor, for example there is a recovery function for COMPEX devices: http://www.cpx.cz/dls/JTAG% 20SW_CONFIG_INSTR/How% 20to% 20JTAG% 20to% 20Compex% 20Loader.pdf (Instruction) http://www.cpx.cz/dls/JTAG% 20SW_CONFIG_INSTR/upbios.tst (needed file for flash via tftp (without UART)) https://dev.openwrt.org/attachment/ticket/8393/init-ar7130-32m.mac (config for OCD Commande - can easily be changed to OpenOCD) http://www.cpx.cz/dls/JTAG% 20SW_CONFIG_INSTR/wp543.rar (bootloader for ar7130) http://www.cpx.cz/dls/wpe72_WPE72NX_MMJ5N26E/wp72_loader_jtag.zip (as bonus this for ar724x - not tested with me) Regards, Dmytro 2012/11/29, Drassal, Allan dra...@wsu.edu: Dear Dmytro and others, Sorry, I didn't post the output in the previous post, just the commands. I am going to post the full output below, along with the details of the ar71xx.cfg file, and output from openocd also. The config file originally came from an AR724x processor as well, so it might not be correct for an AR71xx. I would appreciate assistance in identifying the mistakes and correcting them if you don't mind please. Please share with myself and others if you can. The code that I am attempting to run in the processor, again for the AR724x, is 8Muboot_RAM_version.bin It can be found easily on the internet with a google search. If you have the expertise to identify what can be changed to make this compatile with the AR71xx, please do. This code partially runs because upon execution, it turns on an LED on the board. However, it gives no UART output that I can see. I am still interested in porting U-Boot to this processor as well, and I have found bits and pieces of previous work done, but nothing that I can identify as compelte. MIPS does not seem to be in the main line for U-Boot, but I might be mistaken, correct me if I am wrong here. My
Re: [U-Boot] U-Boot for MIPS AR7161
commands used in openocd through a telnet connection to 127.0.0.1 : reset halt reset mww 0xb8060008 3 mww 0xb806000c 0x12c halt mww 0xb805 0x00090828 mww 0xb805 0x00050828 mww 0xb805 0x00040828 mww 0xb8050008 2 mww 0xb8050008 3 halt reset init load_image 8Muboot_RAM_version.bin 0x8000 resume 0x8000 First: You somehow use the initialization commands from ar724x CPU for ar71xx CPU. If you do not see the difference, you do not understand what you count. You already have a configuration file ar71xx.cfg = it enough. The fact that a ar71xx nSRST (unlike ar724x, where nSRST replaced by RST). The difference is significant for a soft reset / restart the processor. I also do not see a response from the CPU when you transfer mode processor reset or halt, probably something you have not connected properly. Or launch openocd incorrectly (not set the program configuration file for CPU). Secondly: You'll probably need your own loader platform AP96 modified so that it removed all the prerequisites for restarting the processor at boot uboot. Also in the source of any processor is a function of LOWLEVEL_INIT, it is virtually repeated initialization ar71xx.cfg, so this function must be disabled or removed to the new RAM bootloader version, as if it will stay, we just reboot the processor at boot uboot via jtag. Considering your experience and knowledge, I suggest you just unsolder flash memory and an external programmer to flash it. But if all you have decided to go to the end, or you need a JTAG fundamentally, I can put a patch for RAM_uboot AR724x (AP99 platform), so you can make the example of his version of the loader for AR71xx (AP96 platform). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mips port
Jerry, thanks for your answer. So far nobody commented my remark regarding the address of board_init_r after the relocation so I would like to raise it again. Maybe it's my fault as I forgot to attach the patch. In the patch the address is correctly computed which allows u-boot to run after relocation. thanks, -- dmytro On Tue, Oct 9, 2012 at 2:48 AM, Jerry Van Baren gvb.ub...@gmail.com wrote: On 10/06/2012 09:11 PM, Dmytro Milinevskyy wrote: Hi, I'm new to uboot mips port and first decided to try it with qemu. Welcome. :-) I've encountered some problems with UART, but I guess that's more qemu issue(lsr reg is not updated when the line is available). Another issue I faced was code execution after the relocation is done. The address of board_init_r is not computed correctly(it was relative to boot ROM address space/bfc0). Is it specific to qemu(I don't see the reference here though) or is it a generic mips port issue? Attached patch allows me to proceed with the boot in qemu. And last - why do we need relocation at all with u-boot? Performance constraints? Generally, yes. Flash is very often slower than RAM (often 8 bits width vs. 32 bits or more, generally doesn't support bursting, the processor cache may not work with it, etc.). A side benefit of running out of RAM is that it makes it much easier to write to flash... you don't have to worry about writing to the chip you are executing out of (when you erase/write flash, the chip returns a programming in progress status until it is done - that will crash your program if you are running out of that chip). Thanks, -- dmytro Best regards, gvb 0001-mips-qemu-correctly-compute-start-board_init_r-addre.patch Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mips port
Hi, I'm new to uboot mips port and first decided to try it with qemu. I've encountered some problems with UART, but I guess that's more qemu issue(lsr reg is not updated when the line is available). Another issue I faced was code execution after the relocation is done. The address of board_init_r is not computed correctly(it was relative to boot ROM address space/bfc0). Is it specific to qemu(I don't see the reference here though) or is it a generic mips port issue? Attached patch allows me to proceed with the boot in qemu. And last - why do we need relocation at all with u-boot? Performance constraints? Thanks, -- dmytro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mips port
Hi, I'm new to uboot mips port and first decided to try it with qemu. I've encountered some problems with UART, but I guess that's more qemu issue(lsr reg is not updated when the line is available). Another issue I faced was code execution after the relocation is done. The address of board_init_r is not computed correctly(it was relative to boot ROM address space/bfc0). Is it specific to qemu(I don't see the reference here though) or is it a generic mips port issue? Attached patch allows me to proceed with the boot in qemu. And last - why do we need relocation at all with u-boot? Performance constraints? Thanks, -- dmytro 0001-mips-qemu-correctly-compute-start-board_init_r-addre.patch Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mips port
Hi, I'm new to uboot mips port and first decided to try it with qemu. I've encountered some problems with UART, but I guess that's more qemu issue(lsr reg is not updated when the line is available). Another issue I faced was code execution after the relocation is done. The address of board_init_r is not computed correctly(it was relative to boot ROM address space/bfc0). Is it specific to qemu(I don't see the reference here though) or is it a generic mips port issue? Attached patch allows me to proceed with the boot in qemu. And last - why do we need relocation at all with u-boot? Performance constraints? Thanks, -- dmytro 0001-mips-qemu-correctly-compute-start-board_init_r-addre.patch Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
