barebox community/forum
Hello, I would like to know where is the best place for me to post my technical questions related to barebox or which is the best way to proceed? I could not find any forum or barebox community. Thanks. Best regards, Mihaita Ivascu ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
imx7d enable second core
Hi all, I'm currently working with the imx7d sabre board from NXP. I have now a running barebox bootloader and a booting kernel. My problem is now that, apparently, only one core is active: ... commandline: console=ttymxc0,115200n8 ip=11.0.0.4::11.0.0.2:255.0.0.0::eth0: root=/dev/mmcblk0p2 rootdelay=1 Starting kernel in secure mode [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.17.7 (giorgio@BV_blfs) (gcc version 8.1.0 (OSELAS.Toolchain-2018.02.0)) #1 SMP Wed Jul 18 07:44:41 CEST 2018 [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Freescale i.MX7 SabreSD Board [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 64 MiB at 0xba00 [0.00] percpu: Embedded 14 pages/cpu @(ptrval) s36392 r0 d20952 u57344 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 260608 [0.00] Kernel command line: console=ttymxc0,115200n8 ip=11.0.0.4::11.0.0.2:255.0.0.0::eth0: root=/dev/mmcblk0p2 rootdelay=1 [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 950804K/1048576K available (10240K kernel code, 450K rwdata, 2188K rodata, 1024K init, 7788K bss, 32236K reserved, 65536K cma-reserved, 196196K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] .text : 0x(ptrval) - 0x(ptrval) (11232 kB) [0.00] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [0.00] .data : 0x(ptrval) - 0x(ptrval) ( 451 kB) [0.00].bss : 0x(ptrval) - 0x(ptrval) (7789 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [0.00] Running RCU self tests [0.00] Hierarchical RCU implementation. [0.00] RCU event tracing is enabled. [0.00] RCU lockdep checking is enabled. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] Offload RCU callbacks from CPUs: (none). [0.00] arch_timer: cp15 timer(s) running at 8.00MHz (virt). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns [0.09] sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2199023255500ns [0.33] Switching to timer-based delay loop, resolution 125ns [0.000545] Switching to timer-based delay loop, resolution 41ns [0.000574] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns [0.000601] clocksource: mxc_timer1: mask: 0x max_cycles: 0x, max_idle_ns: 79635851949 ns [0.001981] Console: colour dummy device 80x30 [0.002013] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.002032] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.002050] ... MAX_LOCK_DEPTH: 48 [0.002068] ... MAX_LOCKDEP_KEYS:8191 [0.002086] ... CLASSHASH_SIZE: 4096 [0.002104] ... MAX_LOCKDEP_ENTRIES: 32768 [0.002122] ... MAX_LOCKDEP_CHAINS: 65536 [0.002140] ... CHAINHASH_SIZE: 32768 [0.002158] memory used by lock dependency info: 4655 kB [0.002176] per task-struct memory footprint: 1536 bytes [0.002230] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=24) [0.002264] pid_max: default: 32768 minimum: 301 [0.002590] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.002622] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.004407] CPU: Testing write buffer coherency: ok [0.005308] CPU0: update cpu_capacity 1024 [0.005335] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.006792] Setting up static identity map for 0x8010 - 0x80100060 [0.007218] Hierarchical SRCU implementation. [0.008853] smp: Bringing up secondary CPUs ... [0.010740] smp: Brought up 1 node, 1 CPU [0.010766] SMP: Total of 1 processors activated (48.00 BogoMIPS). [0.010786] CPU: All CPU(s) started in SVC mode. [0.012748] devtmpfs: initialized ... I was expecting both cores to be enabled at least by the kernel. Does anyone had the same problem ? giorgio ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
MFGTools support in barebox
Hello, I would like to flash a barebox image on NAND for a Phytec imx6ul evk board using MFGTools. I have added support for UTP protocol in kernel image so commands could be "pushed" using MFGtools app from Windows. But obviously I cannot push barebox_update command to Linux. So I think I have two options: 1) porting barebox_update command to Linux which I do not find it so easy. I am already working on it 2) adding UTP support in barebox so I could just load the barebox image in RAM using MFGtools, there a utp device node would be created and then I could push barebox specific commands directly from MFGtools. I have added UTP support in linux USB gadget code but I see barebox USB gadget code is quite different and not all functionality are in place so I also struggle a bit of porint gUTP patches from Linux to barebox. Does anybody have any experience with this topic or coud advise me on how to procee? Thanks, Mihaita ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: barebox community/forum
Hi Mihaita, Am 18.07.2018 um 09:24 schrieb Mihaita Ivascu: > Hello, > > I would like to know where is the best place for me to post my > technical questions related to barebox or which is the best way to > proceed? > I could not find any forum or barebox community. Thanks. You are already on the right place. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: imx7d enable second core
Am 18.07.2018 um 09:27 schrieb Giorgio Dal Molin: > Hi all, > > I'm currently working with the imx7d sabre board from NXP. > > I have now a running barebox bootloader and a booting kernel. > > My problem is now that, apparently, only one core is active: > > ... > commandline: console=ttymxc0,115200n8 ip=11.0.0.4::11.0.0.2:255.0.0.0::eth0: > root=/dev/mmcblk0p2 rootdelay=1 > Starting kernel in secure mode > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 4.17.7 (giorgio@BV_blfs) (gcc version 8.1.0 > (OSELAS.Toolchain-2018.02.0)) #1 SMP Wed Jul 18 07:44:41 CEST 2018 > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d > [0.00] CPU: div instructions available: patching division code > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > [0.00] OF: fdt: Machine model: Freescale i.MX7 SabreSD Board > [0.00] Memory policy: Data cache writealloc > [0.00] cma: Reserved 64 MiB at 0xba00 > [0.00] percpu: Embedded 14 pages/cpu @(ptrval) s36392 r0 d20952 u57344 > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 260608 > [0.00] Kernel command line: console=ttymxc0,115200n8 > ip=11.0.0.4::11.0.0.2:255.0.0.0::eth0: root=/dev/mmcblk0p2 rootdelay=1 > [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 > bytes) > [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > [0.00] Memory: 950804K/1048576K available (10240K kernel code, 450K > rwdata, 2188K rodata, 1024K init, 7788K bss, 32236K reserved, 65536K > cma-reserved, 196196K highmem) > [0.00] Virtual kernel memory layout: > [0.00] vector : 0x - 0x1000 ( 4 kB) > [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) > [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) > [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) > [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) > [0.00] .text : 0x(ptrval) - 0x(ptrval) (11232 kB) > [0.00] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) > [0.00] .data : 0x(ptrval) - 0x(ptrval) ( 451 kB) > [0.00].bss : 0x(ptrval) - 0x(ptrval) (7789 kB) > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > [0.00] Running RCU self tests > [0.00] Hierarchical RCU implementation. > [0.00] RCU event tracing is enabled. > [0.00] RCU lockdep checking is enabled. > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 > [0.00] Offload RCU callbacks from CPUs: (none). > [0.00] arch_timer: cp15 timer(s) running at 8.00MHz (virt). > [0.00] clocksource: arch_sys_counter: mask: 0xff > max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns > [0.09] sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every > 2199023255500ns > [0.33] Switching to timer-based delay loop, resolution 125ns > [0.000545] Switching to timer-based delay loop, resolution 41ns > [0.000574] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every > 89478484971ns > [0.000601] clocksource: mxc_timer1: mask: 0x max_cycles: > 0x, max_idle_ns: 79635851949 ns > [0.001981] Console: colour dummy device 80x30 > [0.002013] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., > Ingo Molnar > [0.002032] ... MAX_LOCKDEP_SUBCLASSES: 8 > [0.002050] ... MAX_LOCK_DEPTH: 48 > [0.002068] ... MAX_LOCKDEP_KEYS:8191 > [0.002086] ... CLASSHASH_SIZE: 4096 > [0.002104] ... MAX_LOCKDEP_ENTRIES: 32768 > [0.002122] ... MAX_LOCKDEP_CHAINS: 65536 > [0.002140] ... CHAINHASH_SIZE: 32768 > [0.002158] memory used by lock dependency info: 4655 kB > [0.002176] per task-struct memory footprint: 1536 bytes > [0.002230] Calibrating delay loop (skipped), value calculated using timer > frequency.. 48.00 BogoMIPS (lpj=24) > [0.002264] pid_max: default: 32768 minimum: 301 > [0.002590] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) > [0.002622] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 > bytes) > [0.004407] CPU: Testing write buffer coherency: ok > [0.005308] CPU0: update cpu_capacity 1024 > [0.005335] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 > [0.006792] Setting up static identity map for 0x8010 - 0x80100060 > [0.007218] Hierarchical SRCU implementation. > [0.008853] smp: Bringing up secondary CPUs ... > [0.010740] smp: Brought up 1 node, 1 CPU > [0.010766] SMP: Total of 1 processors activated (48.00 BogoMIPS). > [0.010786] CPU: All CPU(s) started in SVC mode. > [0.012748] devtmpfs: initialized > ... > > I was expecting both cores to be enabled at least by the kernel. > > Does anyone had the same pro
Re: barebox community/forum
Hi Oleksij, Ok, thanks. I have already sent a message to barebox@lists.infradead.org Best regards, Mihaita On Wed, Jul 18, 2018 at 9:48 AM Oleksij Rempel wrote: > > Hi Mihaita, > > Am 18.07.2018 um 09:24 schrieb Mihaita Ivascu: > > Hello, > > > > I would like to know where is the best place for me to post my > > technical questions related to barebox or which is the best way to > > proceed? > > I could not find any forum or barebox community. Thanks. > > You are already on the right place. > > -- > Regards, > Oleksij > ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
MFGtools support in barebox
Hi , I would like to flash a barebox image on NAND for a Phytec imx6ul evk board using MFGTools. I have added support for UTP protocol in kernel image so commands could be "pushed" using MFGtools app from Windows. But obviously I cannot push barebox_update command to Linux. So I think I have two options: 1) porting barebox_update command to Linux which I do not find it so easy. I am already working on it 2) adding UTP support in barebox so I could just load the barebox image in RAM using MFGtools, there a utp device node would be created and then I could push barebox specific commands directly from MFGtools. I have added UTP support in linux USB gadget code but I see barebox USB gadget code is quite different and not all functionality are in place so I also struggle a bit of porint gUTP patches from Linux to barebox. Does anybody have any experience with this topic or coud advise me on how to proceed? Thanks, Mihaita ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: barebox community/forum
Hi , I would like to flash a barebox image on NAND for a Phytec imx6ul evk board using MFGTools. I have added support for UTP protocol in kernel image so commands could be "pushed" using MFGtools app from Windows. But obviously I cannot push barebox_update command to Linux. So I think I have two options: 1) porting barebox_update command to Linux which I do not find it so easy. I am already working on it 2) adding UTP support in barebox so I could just load the barebox image in RAM using MFGtools, there a utp device node would be created and then I could push barebox specific commands directly from MFGtools. I have added UTP support in linux USB gadget code but I see barebox USB gadget code is quite different and not all functionality are in place so I also struggle a bit of porint gUTP patches from Linux to barebox. Does anybody have any experience with this topic or coud advise me on how to proceed? Thanks, Mihaita On Wed, Jul 18, 2018 at 9:24 AM Mihaita Ivascu wrote: > > Hello, > > I would like to know where is the best place for me to post my > technical questions related to barebox or which is the best way to > proceed? > I could not find any forum or barebox community. Thanks. > > Best regards, > Mihaita Ivascu ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: MFGtools support in barebox
Hi, you email is in the list. (well, different version of it are already in the list). Please wait if some one can respond here. I'm not an expert, but probably what you need is https://github.com/rauc Am 18.07.2018 um 14:05 schrieb Mihaita Ivascu: > Hi , > > > > I would like to flash a barebox image on NAND for a Phytec imx6ul > evk board using MFGTools. > I have added support for UTP protocol in kernel image so commands > could be "pushed" using MFGtools app from Windows. > But obviously I cannot push barebox_update command to Linux. > So I think I have two options: > > 1) porting barebox_update command to Linux which I do not find it so > easy. I am already working on it > 2) adding UTP support in barebox so I could just load the barebox > image in RAM using MFGtools, there a utp device node would be created > and then I could push barebox specific commands directly from > MFGtools. > I have added UTP support in linux USB gadget code but I see > barebox USB gadget code is quite different and not all functionality > are in place so I also struggle a bit of porint gUTP patches from > Linux to barebox. > Does anybody have any experience with this topic or coud advise > me on how to proceed? > > Thanks, > Mihaita > > ___ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox > -- Regards, Oleksij signature.asc Description: OpenPGP digital signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
qemu and barebox
Hi all, i'm trying to run barebox using qemu because I need to develop and emulate a spacial boot configuration of the CERN White Rabbit switch (http://white-rabbit.web.cern.ch/). I used the ARCH=arm and CROSS_COMPILE=aarch64-linux-gnu- Selected the qemu virt board in menuconfig. Compilation seems ok but when trying qemu-system-aarch64 -m 2048M -cpu cortex-a57 -machine virt -display none -serial stdio -kernel barebox The system does not give me any output eve if is running using 100% of one core on my 4 core machine. The final goal would be to setup barebox to boot from network and then arrange a bootp server un another virtual machine. What I'm doing wrong ? is the CPU type cortex-a57 correct even if in menuconfig the type is market as Atemel-AT91 ? Thenks, Giuseppe Levi -- Dr. Giuseppe Levi Physics Dpt and INFN viale Berti Pichat 6/2 40127 BOLOGNA Mobile: +39 393 0086704 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: qemu and barebox
Hi Giuseppe, this was discussed recently; see https://www.mail-archive.com/barebox@lists.infradead.org/msg27074.html tldr: there are issues with QEMU and ARM64, and no solution yet. - Roland On Wed, Jul 18, 2018 at 03:02:48PM +0200, Giuseppe Levi wrote: > Hi all, > i'm trying to run barebox using qemu because I need to develop and > emulate a spacial boot configuration of the CERN White Rabbit switch > (http://white-rabbit.web.cern.ch/). > I used the ARCH=arm > and CROSS_COMPILE=aarch64-linux-gnu- > > Selected the qemu virt board in menuconfig. > > Compilation seems ok but when trying > qemu-system-aarch64 -m 2048M -cpu cortex-a57 -machine virt -display > none -serial stdio -kernel barebox > > The system does not give me any output eve if is running using 100% of > one core on my 4 core machine. > > The final goal would be to setup barebox to boot from network and then > arrange a bootp server un another virtual machine. > > What I'm doing wrong ? is the CPU type cortex-a57 correct even if in > menuconfig the type is market as Atemel-AT91 ? > > > > Thenks, Giuseppe Levi -- Roland Hieber | r.hie...@pengutronix.de | Pengutronix e.K. | https://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5086 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: MFGtools support in barebox
Hi, On 07/18/2018 03:01 PM, Oleksij Rempel wrote: you email is in the list. (well, different version of it are already in the list). Please wait if some one can respond here. I'm not an expert, but probably what you need is https://github.com/rauc Have a look here: http://rauc.readthedocs.io/en/latest/advanced.html#updating-the-bootloader Updating barebox on NAND is not yet implemented. It would certainly be a nice feature to have. Have a look in section 7.6.2 if you want to do that. Regards, Bastian -- Pengutronix e.K. Industrial Linux Solutions http://www.pengutronix.de/ Peiner Str. 6-8, 31137 Hildesheim, Germany Amtsgericht Hildesheim, HRA 2686 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: qemu and barebox
Hello. > emulate a spacial boot configuration of the CERN White Rabbit switch > (http://white-rabbit.web.cern.ch/). The White Rabbit switch is AT91SAM9G45 (I have one on my desk). Unless your own WR switch is a new design running on cortex-a57, you shoul cross-compile for arm32 and use a corresponding qemu configuration. /alessandro ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: MFGtools support in barebox
On Wed, 2018-07-18 at 15:53 +0200, Bastian Stender wrote: > Hi, > > On 07/18/2018 03:01 PM, Oleksij Rempel wrote: > > you email is in the list. (well, different version of it are already > > in the list). Please wait if some one can respond here. > > > > I'm not an expert, but probably what you need is > > https://github.com/rauc > > Have a look here: > > http://rauc.readthedocs.io/en/latest/advanced.html#updating-the-bootloader > > Updating barebox on NAND is not yet implemented. It would certainly be a > nice feature to have. Have a look in section 7.6.2 if you want to do that. Speaking with my rauc maintainer hat on... Writing barebox to NAND on an i.MX6 can't be done by generic methods, so for rauc we would want to call something like barebox-update which then handles the details. In any case, rauc is not intended for initial installation in the factory, but for updating in the field. Instead of MFGtools, we usually load barebox via imx-usb-loader. That is configured to start the fastboot gadget, which we then use to write barebox (via barebox_update) and the rootfs. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: MFGtools support in barebox
Hi, Thanks for answer. I think I need it to do it from Windows as we have some boards that need to be updated in the factory by people that do not necessary have Linux skills or Linux workstation. That is why we thought we could use MFGtools app. My problem is that the board we have have only NAND and USB as boot options. And I need to flash the NAND the first time. I have already looked at imx-usb-loader solution but it required a Linux OS which is not possible in my case I have already used barebox_update successfully but only after I had a working barebox already. I was successful into loading barebox image from MFGtools into RAM and there execute barebox_update to flash on the NAND itself. But the barebox won't load afterwards the kernel image with mfgtools support. So I have two options I think: i) porting barebox_update to Linux. Is there a way to flash the barebox on NAND from Linux itself(after the board has booted successfully) ? ii) adding support for MFGtools in barebox. I do not have toom uch knowledge about it. I know I should add UTP protocol support in usb gadget code in barebox but was not successful so far. How do you guys see a solution to this scenario? Thanks, Mihaita On Wed, Jul 18, 2018 at 4:56 PM Jan Lübbe wrote: > > On Wed, 2018-07-18 at 15:53 +0200, Bastian Stender wrote: > > Hi, > > > > On 07/18/2018 03:01 PM, Oleksij Rempel wrote: > > > you email is in the list. (well, different version of it are already > > > in the list). Please wait if some one can respond here. > > > > > > I'm not an expert, but probably what you need is > > > https://github.com/rauc > > > > Have a look here: > > > > http://rauc.readthedocs.io/en/latest/advanced.html#updating-the-bootloader > > > > Updating barebox on NAND is not yet implemented. It would certainly be a > > nice feature to have. Have a look in section 7.6.2 if you want to do that. > > Speaking with my rauc maintainer hat on... > > Writing barebox to NAND on an i.MX6 can't be done by generic methods, > so for rauc we would want to call something like barebox-update which > then handles the details. In any case, rauc is not intended for initial > installation in the factory, but for updating in the field. > > Instead of MFGtools, we usually load barebox via imx-usb-loader. That > is configured to start the fastboot gadget, which we then use to write > barebox (via barebox_update) and the rootfs. > > Regards, > Jan > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: MFGtools support in barebox
Am 18.07.2018 um 17:11 schrieb Mihaita Ivascu: > Hi, > > Thanks for answer. > I think I need it to do it from Windows as we have some boards > that need to be updated in the factory by people that do not necessary > have Linux skills or Linux workstation. > That is why we thought we could use MFGtools app. > My problem is that the board we have have only NAND and USB as > boot options. And I need to flash the NAND the first time. > I have already looked at imx-usb-loader solution but it required > a Linux OS which is not possible in my case > I have already used barebox_update successfully but only after I > had a working barebox already. > I was successful into loading barebox image from MFGtools into > RAM and there execute barebox_update to flash on the NAND itself. > But the barebox won't load afterwards the kernel image with > mfgtools support. > > So I have two options I think: > > i) porting barebox_update to Linux. Is there a way to flash the > barebox on NAND from Linux itself(after the board has booted > successfully) ? >ii) adding support for MFGtools in barebox. I do not have toom uch > knowledge about it. I know I should add UTP protocol support in usb > gadget code in barebox but was not successful so far. > > How do you guys see a solution to this scenario? If you can load barebox in to RAM with MFGtools, you can use fastboot tool flash all needed parts. fastboot is available for windows and supported by barebox. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: imx7d enable second core
On Wed, Jul 18, 2018 at 12:28 AM Giorgio Dal Molin wrote: > > Hi all, > > I'm currently working with the imx7d sabre board from NXP. > > I have now a running barebox bootloader and a booting kernel. > > My problem is now that, apparently, only one core is active: > > ... > commandline: console=ttymxc0,115200n8 ip=11.0.0.4::11.0.0.2:255.0.0.0::eth0: > root=/dev/mmcblk0p2 rootdelay=1 > Starting kernel in secure mode AFAIK, this means that you are booting in secure mode and secure monitor code, which also implements PSCI needed for SMP to work, will _not_ be installed by Barebox. One way to fix this would be to set: global.bootm.secure_state=nonsecure before booting Linux. Doing that I get: # lscpu -e CPU SOCKET CORE ONLINE MAXMHZ MINMHZ 0 0 0yes996. 792. 1 0 1yes996. 792. # on my SabreSD board. Thanks, Andrey Smirnov ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: MFGtools support in barebox
Ok, thanks. I will take a look. I think for that scenario I do not need fastboot. Once I have barebox in RAM I can do barebox_update to flash it in NAND, reboot and then run a script from USB that created partitions in NAND and copies FIT image(which contains kernel+rootfs) on NAND Fastboot would be helpful if I could flash the NAND without running anything in target's RAM initially( no barebox nor Linux). My goal is to have a target with nothing on NAND and be able to flash anything is needed(barebox, kernel, etc) by just using one tool(MFGtools, fastboot, etc). Not 2 steps approach: to copy the NAND first and then to do anything else by running commands/scripts commands. This is how I do it now. I know that using MFGtools from NXP is possible. But with uboot booatloader. NXP says they don't support barebox. Aside from this issue, are you aware of any method of flashing the barebox on NAND from Linux(after the kernel was loaded successfully on the target) ? barebox_update does not exist in Linux obviously and porting it is not so trivial, on top of that I don't think I am able to access the nand device from Linux, but only MTD partitions . I have tried nandwrite and kobs-ng commands but I was not successful. Thanks, Mihaita On Wed, Jul 18, 2018 at 6:35 PM Oleksij Rempel wrote: > > Am 18.07.2018 um 17:11 schrieb Mihaita Ivascu: > > Hi, > > > > Thanks for answer. > > I think I need it to do it from Windows as we have some boards > > that need to be updated in the factory by people that do not necessary > > have Linux skills or Linux workstation. > > That is why we thought we could use MFGtools app. > > My problem is that the board we have have only NAND and USB as > > boot options. And I need to flash the NAND the first time. > > I have already looked at imx-usb-loader solution but it required > > a Linux OS which is not possible in my case > > I have already used barebox_update successfully but only after I > > had a working barebox already. > > I was successful into loading barebox image from MFGtools into > > RAM and there execute barebox_update to flash on the NAND itself. > > But the barebox won't load afterwards the kernel image with > > mfgtools support. > > > > So I have two options I think: > > > > i) porting barebox_update to Linux. Is there a way to flash the > > barebox on NAND from Linux itself(after the board has booted > > successfully) ? > >ii) adding support for MFGtools in barebox. I do not have toom uch > > knowledge about it. I know I should add UTP protocol support in usb > > gadget code in barebox but was not successful so far. > > > > How do you guys see a solution to this scenario? > > If you can load barebox in to RAM with MFGtools, you can use fastboot > tool flash all needed parts. fastboot is available for windows and > supported by barebox. > -- > Regards, > Oleksij > ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: qemu and barebox
Ok tried with CROSS_COMPILE=arm-linux-gnueabi- this should be 32bit arm then: qemu-system-arm -m 256M -machine virt -display none -serial stdio -kernel barebox hangs. any idea ? Should I use a different machine ? It would be very complex to create a White Rabbit virtual machine ? (HW description is open) 2018-07-18 16:03 GMT+02:00 Alessandro Rubini : > Hello. > >> emulate a spacial boot configuration of the CERN White Rabbit switch >> (http://white-rabbit.web.cern.ch/). > > The White Rabbit switch is AT91SAM9G45 (I have one on my desk). > Unless your own WR switch is a new design running on cortex-a57, you > shoul cross-compile for arm32 and use a corresponding qemu > configuration. > > /alessandro -- Dr. Giuseppe Levi Physics Dpt and INFN viale Berti Pichat 6/2 40127 BOLOGNA Mobile: +39 393 0086704 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: qemu and barebox
On Wed, Jul 18, 2018 at 11:51 AM Giuseppe Levi wrote: > > Ok tried with CROSS_COMPILE=arm-linux-gnueabi- this should be 32bit arm > then: qemu-system-arm -m 256M -machine virt -display none -serial > stdio -kernel barebox > > hangs. any idea ? Should I use a different machine ? > NOTE: All of the below pertains to upstream QEMU You are running QEMU emulating "mach-virt", which is a special generic ARM machine in QEMU against a Barebox built for AT91. Last time I checked former can only be configured to have Cortex-A15 (ARMv7), A53 or A57(ARMv8) as a CPU, whereas the latter is ARM9 (ARMv5), not to mention that memory map layout for all of the peripherals _and_ type of IP blocks used is very different. Unless I am getting something very wrong, I'd be very much surprised if it actually worked for you. As for using a different machine, I don't think that would help. AFAIK, what you are trying to do is not currently supported. > It would be very complex to create a White Rabbit virtual machine ? > (HW description is open) Not sure if I'd say it would be "complex", but time consuming for sure. It took me a couple of weeks of work to add enough i.MX7 support to QEMU for it would be able to boot stock Linux and I had a headstart because QEMU already supported i.MX6 when I started. I haven't looked at QEMU tree for probably 4 months, so my knowledge is a bit outdated, but AFAIK, while ARM9 CPU emulation is availible, there's no AT91 SoC specific IP blocks emulation that it supports. So, at a bare minimum, just to see some serial in QEMU, you are looking at implementing your AT91 machine with its memory map, UART IP block emulation plus any peripherals that have to be emulated to "fool" Barebox into booting. Thanks, Andrey Smirnov ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: qemu and barebox
> Not sure if I'd say it would be "complex", but time consuming for > sure. Yes. > but AFAIK, while ARM9 CPU emulation is availible, there's no AT91 SoC > specific IP blocks emulation that it supports. I think the fastest way to work out this setup is building barebox for versatile and using "qemu -M versatilepb". The WR kernel includes drivers for the special ethernet device, but the WR port of barebox has no serious hardware dependencies (it's just uart, flash and i2c eeprom). So IMHO there's no need for AT91 SOC emulation to test different boot procedures. /alessandro ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: MFGtools support in barebox
On 18.07.2018 19:56, Mihaita Ivascu wrote: > Ok, thanks. I will take a look. I think for that scenario I > do not need fastboot. Once I have barebox in RAM I can do > barebox_update to flash it in NAND, reboot and then run a script from > USB > that created partitions in NAND and copies FIT image(which contains > kernel+rootfs) on NAND > Fastboot would be helpful if I could flash the NAND without > running anything in target's RAM initially( no barebox nor Linux). > My goal is to have a target with nothing on NAND and be able > to flash anything is needed(barebox, kernel, etc) by just using one > tool(MFGtools, fastboot, etc). Not 2 steps approach: to copy the NAND > first and then to do anything else by running commands/scripts > commands. This is how I do it now. > I know that using MFGtools from NXP is possible. But with > uboot booatloader. NXP says they don't support barebox. This confusion appears only from end user perspective. one tool is not equal one step. With MFGtool it works this way: - iMX SoC will start do some checks and based on $decisions start USB HID interface. - MFGtool will upload firmware image over this interface and request execution of this image. This firmware should contain NAND and USB drivers. - Old ROM USB interface will be disabled and new firmware USB interface with more futures will be created - Over this new interface MFGtool is able to send commands and images so the firmware can write it down. The same we usually do by combining imx-usb-loader with fastboot: - upload barebox with imx-usb-loader over ROM USB interface and start it - barebox will disable ROM USB interface and create own with fastboot support. - use fastboot to send commands and images over fastboot-barebox USB interface. Or upload barebox and linux over usb so you can do the same over linux. If all this steps are hidden behind one script or application, it looks for end user as single step. > Aside from this issue, are you aware of any method of > flashing the barebox on NAND from Linux(after the kernel was loaded > successfully on the target) ? > barebox_update does not exist in Linux obviously and porting it is not > so trivial, on top of that I don't think I am able to access the nand > device from Linux, but only MTD partitions . > I have tried nandwrite and kobs-ng commands but I was not successful. barebox_update is a wrapper to: take a image and write it to predefined project or board specific location. If you have access to this location from linux, you can do it from linux as well. > Thanks, >Mihaita > > On Wed, Jul 18, 2018 at 6:35 PM Oleksij Rempel wrote: >> >> Am 18.07.2018 um 17:11 schrieb Mihaita Ivascu: >>> Hi, >>> >>> Thanks for answer. >>> I think I need it to do it from Windows as we have some boards >>> that need to be updated in the factory by people that do not necessary >>> have Linux skills or Linux workstation. >>> That is why we thought we could use MFGtools app. >>> My problem is that the board we have have only NAND and USB as >>> boot options. And I need to flash the NAND the first time. >>> I have already looked at imx-usb-loader solution but it required >>> a Linux OS which is not possible in my case >>> I have already used barebox_update successfully but only after I >>> had a working barebox already. >>> I was successful into loading barebox image from MFGtools into >>> RAM and there execute barebox_update to flash on the NAND itself. >>> But the barebox won't load afterwards the kernel image with >>> mfgtools support. >>> >>> So I have two options I think: >>> >>> i) porting barebox_update to Linux. Is there a way to flash the >>> barebox on NAND from Linux itself(after the board has booted >>> successfully) ? >>>ii) adding support for MFGtools in barebox. I do not have toom uch >>> knowledge about it. I know I should add UTP protocol support in usb >>> gadget code in barebox but was not successful so far. >>> >>> How do you guys see a solution to this scenario? >> >> If you can load barebox in to RAM with MFGtools, you can use fastboot >> tool flash all needed parts. fastboot is available for windows and >> supported by barebox. >> -- >> Regards, >> Oleksij >> > > ___ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox > signature.asc Description: OpenPGP digital signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
